{"id":6160,"date":"2021-06-21T15:16:07","date_gmt":"2021-06-21T15:16:07","guid":{"rendered":"http:\/\/desres20.netornot.at\/?p=6160"},"modified":"2021-06-21T15:16:07","modified_gmt":"2021-06-21T15:16:07","slug":"wwise-implementierung-in-unity-teil-3-akstate-akswitch","status":"publish","type":"post","link":"http:\/\/desres20.netornot.at\/?p=6160","title":{"rendered":"Wwise Implementierung in Unity (Teil 3: AkState, AkSwitch)"},"content":{"rendered":"\n

Bei meinem letzten Blogeintrag habe ich die Wwise-Implementierungsskripte AkInitializer<\/em> und AkBank<\/em>, die eine grundlegende Voraussetzung f\u00fcr die Nutzung der Wwise Audio-Engine bilden und das Laden von Soundbanks erm\u00f6glichen, beschrieben.<\/p>\n\n\n\n

Ein Grundbaustein eines adaptiven Sounddesigns ist das adaptive Verhalten von Sounds, das auf unterschiedliche Gegebenheiten im Spiel reagiert. Daf\u00fcr gibt es Switches und States, die quasi Zust\u00e4nde repr\u00e4sentieren und wie Schalter aktiviert werden k\u00f6nnen. Der Hauptunterschied zwischen Switches und States ist, dass ein Switch jeweils einem einzigen GameObject<\/em> zugeordnet wird, w\u00e4hrend States von unterschiedlichen GameObjects<\/em> aktiviert werden k\u00f6nnen. Die Nutzung und Konfiguration beider Parameter ist hingegen identisch.<\/p>\n\n\n\n

F\u00fcr das Ver\u00e4ndern eines Switches oder eines States gibt es extra daf\u00fcr vorgefertigte Skripte namens AkSwitch<\/em> und AkState<\/em>. In Wwise m\u00fcssen daf\u00fcr bereits die unterschiedlichen States bzw. Switches und die State bzw. Switch-Container mit den Audiofiles vorhanden sein, damit man sie in Unity implementieren kann. Ist das gegeben legt man ein AkSwitch- bzw. AkState-Skript auf ein GameObject<\/em>. In diesen kann man nun \u00fcber den Unity-Inspector den Switch bzw. State w\u00e4hlen, der aktiviert werden soll. <\/p>\n\n\n\n

\"\"
Auswahl des States im Unity Inspector<\/em><\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Des Weiteren muss noch bestimmt werden, was den Switch bzw. State triggert. Klassischerweise ist es das Betreten oder Verlassen eines Colliders.<\/p>\n\n\n\n

\"\"
Der State wird hier beim Verlassen des Triggers ver\u00e4ndert<\/em><\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Hierbei sollte noch ein AkTriggerEnter<\/em>– bzw. AkTriggerExit<\/em>-Skript hinzugef\u00fcgt werden, der spezifiziert, welches GameObject<\/em> den Trigger ausl\u00f6st, ansonsten l\u00f6st jede Kollision mit irgendeinem anderen GameObject<\/em> den Trigger aus, was in den meisten F\u00e4llen nicht gew\u00fcnscht ist.<\/p>\n\n\n\n

\"\"
AkTriggerExit-Skript mit dem Player als ausl\u00f6sendes GameObject<\/em><\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Quellen:<\/p>\n\n\n\n

[1] https:\/\/www.audiokinetic.com\/library\/edge\/?source=SDK&id=soundengine_switch.html<\/p>\n\n\n\n

[2] https:\/\/www.audiokinetic.com\/courses\/wwise301\/?source=wwise301&id=Setting_States_using_the_AkState_Component<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Bei meinem letzten Blogeintrag habe ich die Wwise-Implementierungsskripte AkInitializer und AkBank, die eine grundlegende Voraussetzung f\u00fcr die Nutzung der Wwise Audio-Engine bilden und das Laden von Soundbanks erm\u00f6glichen, beschrieben. Ein Grundbaustein eines adaptiven Sounddesigns ist das adaptive Verhalten von Sounds, das auf unterschiedliche Gegebenheiten im Spiel reagiert. Daf\u00fcr gibt es Switches und States, die quasi<\/p>\n