This is cool! In which real example game situation would you choose to use it?
@CujoSound8 ай бұрын
If you have one event that comes in, say - thunder storm and you need to have completely different logic on 4-5 different types then instead of 4-5 events, you only need one. If you use callbacks, you can tell the engine back which of the versions it was and do something with that. It's not so much that it can't be done in other ways, it's about that it's possible. Also, if you at the end of your Music track for something specific, want to randomize which music track comes next, then trigger your randomize event, randomize 4 events which sets a state, that state determines what the next music piece is. It brings in a lot of logic options that you would otherwise have to do on the engine side and still parse state, switch, rtpc or other things back into wwise. Keeping it on the wwise side can make it a lot easier to navigate for the sound designer.
@jasminacarevic8 ай бұрын
@@CujoSound Thank you! Got it. It opens up many cool stuff to try instead of coding... Do you rather choose this way or the engine side in a case when both options work?
@CujoSound8 ай бұрын
@@jasminacarevic I prefer to keep as much as possible in the engine - to avoid cluttering of Wwise as such, but there is a lot of situations where there is only one hook to a thing and no information about it really- so randomization on the wwise side is the way forward. You can randomize as much as you like in containers, but that would be a massive one time event if it was to randomly pick containers too. This could also be events that randomize states and such as I mentioned before, it doesn't have to do much. But, the question: engine side if possible.