Last time we end our Project Blog #2, we left a question unanswered.
That is, since the limitations of Tango apply to our project, we cannot do our gameplay in a dim space, to act as substitute, we made the game itself super dim instead. However, the dim environment of the game world means that the player is very likely to miss something in the game world. As our core gameplay mechanics involves finding ghosts floating around in the room, and taking photographs of them while looking for key items, thus requiring knowledge of the game world.
Yay for conflict between gameplay and mechanics!
Of course, we need something to alert the player without letting them see.
Even though Google Tango is one awesome system, it cannot provide anything than visual and audio input. Since the visual input are out of the question, this left only with the audio input. Meaning that we can only tackle this problem soundly (pun intended).
So, we decided that for each event happening, in other words, when there are something that requires attention of the player, there should be a sound based on it.
Talking about sound, there are background sounds (BGM) and foreground sounds (SE). And that’s how they’ll work:
- A background track, consisted of drums, bass and some percussion constantly plays in the background as the game’s BGM. The track is composed in typical slow beat drum & bass fashion so the player won’t getting bored listening to something without a melody.
- However, when an event is fired by the system – A ghost appears or a key item appears – The track’s melody part, consisted of flute, piano and guitar would kick in, since this also changes the genre of the background music, it’s considered as a sudden and apparent change in atmosphere. Because of the unexpected change, the player is then realized something has happened.
- This is achieved by recording the two tracks in different files, and while the files are both playing, the melody track’s volume is at 0 unless something happens which would increase the volume. When the event ends, the volume is reset to 0.
- A series of SE is prepared and is read by the engine as sound files.
- Each SE is tied to a location within the game world.
- When something happens, the SE that’s closest to the event would play. Its volume is calculated from the player’s position to the sound source.
- Aside from BGM and SE changes, when an event occurs, there would be something displayed on the HUD to further reminding the player that actions need to be taken.
As of now, the programming of those functions are coming nicely. I had to say, Tango would not be a that good choice on horror games, due to its various limitations. It is more fitting as something that is exactly the same in real life and in the game world. For example. an library or a museum, where the Tango can be used to provide additional information based on the user’s location (e.g facing a specific piece of art, displaying on Tango the detailed information regarding said art). But regardless, our game is still coming nicely and I think we are doing the best we can on this.
So, until next time.