An 2-player action game. Each player controls half of the robot and cooperate to fight with a monster in a city. To control their robot to move, they have to lean their body synchronously. If they don’t, the robot will break into 2 parts and they have to connect their arms (through Makey Makey) to reconnect the robot. They can also release powerful special attack or restore by getting supply and make specific poses.
This round I paid high attention on coding the sound manager. Since it was the last round of Building Virtual Worlds, I hope to arrange my script of the Sound Manager, making it reusable. I wrote the sound manager last 4 rounds, but they were lack of re-usability for their weak cohesion and, sometimes, high coupling. In the past, as time limits, I used to write independent functions for every sound effect, and they turned out to be messy for other programmers to call eventually. They had to ask me which function should they call every time.
Therefore, I redesigned the Sound Manager by integrating background music, dialog and sound effects into 3 functions separately. Each specific sound track could be called by an input parameter of a enumeration, which helps other programmers to understand how many and which sound track should be used. For example, to play a robot-punch sound effect, all you have to do is to call the funciont sfxPlay(SFXType.ROBOT_PUNCH) with the input parameter SFXType.ROBOT_PUNCH which is an enumeration. Furthermore, I designed a class called SoundParam. It could be instantiated to objects that contains the volume, pitch and other features of a sound. All objects of SoundParam could be instantiated when the game start in the Initialize() function. It helps sound designers to unify their assets’ features.
As for the game, besides common functions I had already written such as creating sounds, raising or dropping their pitch, fading in and out, the chief programmer asked me for a “slow motion” function, which means that all sounds in the game would slow down when entered the “slow motion” state. At the beginning I thought it was just a piece of cake – all I had to do is lower the feature of pitch of every audio. But soon I realized I was wrong. Since the function of playing a sound effect would destroy the object (as a carrier of the Audio Source) when it completed, it might cause a cannot-find-the-object error when entering the slow motion calling the PitchChange() function. I had tried different ways of checking the status of the objects before starting the co-routine function of changing pitch, but they didn’t help. Hence, I changed the way. When the audio completed playing, instead of destroying them immediately, I let the program store the object into a list. There is an independent function to destroy all objects in the list every 2 seconds in batches. During the “slow motion” status, the destroying function will suspend, avoiding destroying the object of an audio when it calling a co-routine function to change its pitch. I learned this long time ago from the tutorial of the Unity official website.