N00b Q: clarifying uses of sheets

[magrotten]

Hi guys and gals,

Can anyone explain to a n00b the pros/cons of placing instruments on parameter sheets (or action sheets) as opposed to timeline?

I know it makes them exempt from temporal functions, but aside from that are there useful reasons to not use the timeline for instruments? Considering the timeline tracks still receive parameter automation from param sheets.

Thanks for clarifying,
Matt

[Alcibiade]

There’s a lot of reasons. Each time the instruments in your events aren’t related by a timing. For exemple, a one-shot sound triggered in real time could be on an action sheet only.

Typically, a complex footsteps system which superposes layers of sounds depending of parameters (type of shoe, type of surface) will have all the instruments placed directly on the parameter sheets and nothing in the timeline.

[magrotten]

Thanks Alcibiade!

I’m guessing that instruments on parameter sheets are specific to that parameter only, not shared with other parameters, and if you want them responding to other parameters it’s better to have them copied onto those other parameter sheets as well rather than trying to have them all shared from a timeline sheet, if there are no ‘time-responsive’ requirements.

Thanks again for clarifying for me, this is what happens when you read the manual before working on a project!

[magrotten]

I think I can define sheets now as follows:

Action sheets are momentary one-shot playlists (no scatterers or trigger conditions)
Timeline sheets are linear pre-set parameters (with sustain points and logic markers as controllers)
Parameter sheets are for state-dependent sounds (can automate timeline sounds or can host&seek/automate continuous sounds, can have multiple if track number is populated accordingly, creating matrix)

[Alcibiade]

@magrotten

if you want them responding to other parameters it’s better to have them copied onto those other parameter sheets as well rather than trying to have them all shared from a timeline sheet, if there are no ‘time-responsive’ requirements.

No, it doesn’t work that way! If you copy your instruments on multiple parameter sheets, those parameters will never work well together! The parameter sheet in which you should put your instrument is the one most directly related to the instrument trigger. Interaction with other parameters could be done in this sheet by having, for instance, conditional triggering behavior to these instruments, related to other parameters.

[Alcibiade]

@magrotten

I think I can define sheets now as follows:

Action sheets are for real-time one-shot events - no scatterers or trigger conditions
Timeline sheets are for time-reactive events or events that manipulate time*
Parameter sheets are for game-reactive events (could also be time-reactive but usually not)

*Cues can also be used to move timeline playback past a sustain point, as when the sustain point no linger reaches parameter/event conditions

Keep in mind events often use a combination of those! But it’s a rather good summary, to answer to your specific question: in which sheet should I put my instruments.

I also really often use event nested at several levels. For instance, in our game, for the melee attacks, I’m using several distinct events:

• the impact sound on a parameter sheet (depending of the surface of impact)
• the woosh sound on a parameter sheet (depending of the type of weapon)
• a feedback sound for hit or miss, on an action sheet
  etc…
  And all of those events are nested in a parent event called “melee attack”, which is a timeline sheet.
  I find this kind of break down workflow very effective.

[magrotten]

Ah thankyou, that’s really useful and clarifies a lot - nesting really makes sense now.

And because it’s all one event I guess it makes it a lot easier to apply as one asset in UE4 for example, pulling all the various information into a single node.

[Alcibiade]

I don’t use UE4 but probably. Yes, that way, an unique event which the right parameter values are sent to, does the job. I like doing that way because our dev uses the api and has to code everything. So, the more I control things inside my events, the less code it is for him (and the more I keep control on sub-events triggering and the
timings related).

[magrotten]

If I may ask a question on this, is it quite normal that audio middleware staff don’t need to know the game engine, or is there sometimes an expectation that they know at least basics of engine implementation?

[joseph]

@magrotten

Is it quite normal that audio middleware staff don’t need to know the game engine, or is there sometimes an expectation that they know at least basics of engine implementation?

There’s no single “normal” way of doing things. Different game projects have different requirements and resources, and so divide up their responsibilities differently: One studio might expect its developers to stick to very specific and clearly-defined roles, in order to let them focus on their unique specialties without distractions; another studio might encourage developers to talk about whatever they’re working on with others, even if they’re working on different aspects of the game, so as to promote an atmosphere of friendly collaboration and ensure everyone is working towards the same shared vision.

That being said, regardless what kind of studio you work for, it’s useful to have a rough idea of how your content will be used and triggered in-game, since knowing how your content will be used means you can design it for that purpose - and knowing your game engine’s relevant jargon makes it a lot easier to communicate with the other people working on the same game project, which is always useful.