Karabasan Glok in the Musical Forest – Postmortem

June 20, 2012 in Articles and Essays, Blog, Events, Game Jam, Guney Ozsan, Notes, Production, Video Game Production

Karabasan Glok in the Musical Forest“Karabasan Glok in the Musical Forest” is a first-person audio game without graphics. Before reading the postmortem you can play the game and get information about it here.

This is my second game jam. First one was Global Game jame 2012 Istanbul (GGJ). I went GGJ to make music but because of the heavy snow (extremely heavy) only a few people showed up. In addition to that, all of the games except one were not suitable for music placement. Because of the snow we had to spend two days in the Koc University campus. Then, with a developer that I met there, Kerem Tiryaki, we developed a mobile music game (toy) in unity 3D, based on accelerometer. I liked the idea of games without graphics very much, and since I involved with Unity 3D already, I strated experimenting on it.

When the theme of the GDT Jam announced as escape, the idea of 3 dimensional sound and escape seemed very suitable with each other. According to my initial design monsters were supposed to run after us and we will try to understan where they were coming from. The winning condition was to reach a soothing sound or music. With running our heart rate and breathing would speed up but running too fast would cause a heart attack. So I planned the create a balance between heart attack and monsters chasing, creating adrenaline with sounds aiming our subcounscious, heart beat, breathing, roaring.

Of course I couldn’t reach that conclusion in 48 hours. The resulting game was a single monster lost, and we are trying to find him. Why it ended like that?..

 
THE REASONS BEHIND MISSING THE INITIAL DESIGN:

  • Basic reason is I ran out of time to model monster behaviour, and create in game dynamics. I switched to this game model from what I have in my hand.
  • Since I am not that familiar with development process, I couldn’t get a sense of giving how much weight to which stage.
  • Since the genre I am dealing with was not widespread, there wasn’t enough examples ahaed of me to show me some light. Some very basic design decisions took so much time because it was too abstract.
  • I understood that environment design is very hard when using only sound. I feel too much difficulty in how to give an idea about the surrounding to the player. But I discovered some ways to the for later.
  • On friday night, and saturday we did a lot of chat in the IRC channel. On the other hand it was necessary and good for me to follow the other developmetn stages.
  • I wrote binaural audio as a script in Unity. Although it was working sample based the CPU was forced a lot. I took too much time for code optimization. I saw that if something big is done this way, it needs very detailed optimization.
  • I get a lot of ideas and cleared the way after the first prototype, but it came out very late (Sunday morning at six o’clock and I went to bed. Note that this was a 48 hour weekend jam). When I woke up there was only enough time left to create a game with things in hand. It is better to have something to play around with in the very early stages.

 
THE MISSING THINGS IN THE GDT JAM VERSION OF THE GAME:

  • The sense of direction is very weak. There are some advancements to be done to improve this.
  • There are some technical restrictions. My binaural script can’t move the sounds in 3D once they are triggered. Which means, if you turn around when a sound is sounding, it doesn’t change its place. So I need to create the environment with short rithmically playing sounds. Breaking the continuity resulted in breaking the sense of 3D environment.
  • The sounds of the forest are coming out of a single instrument. That resulted in a low contrast monotone effect like in a monochrome monitor. One more thing to decrease sense of locational perception.
  • The notes are randomly placed in each run of the game (Note: The notes are placed on a grid). My first idea was to create harmonic regions but i was out of time to make a plan of notes on grids.
  • Monster doesn’t interact with us except making a soothing sound when we catch it. It can run around, sometimes stop, this way it can pass by while we are looking for it…etc

 
WHERE I CAN MOVE FROM THIS POINT:

  • A radar or HUD like visual aids can be added. I don’t want to do this because I want to learn how to design blind friendly.
  • Environment can be designed with chracteristically various sounds with fixed locations.
  • After fixing the 3D sense of location technically, some introductory levels can be designed to teach and warm up for 3D sound.
  • An abstract visual location design can be fit over the musical location.
  • A running game with a single button for speeding up and down can be designed. This way the player can focus on the game mechanics rather than the sense of location.

 
NOTES AND OBSERVATIONS ON AUDIO OPTIMIZATION:

  • Keep the child-parent relationships and object structure very fit from the beginning so that you will have a flexibel and optimal design. In this project Find and GetComponent is very essential for frequent distance calculations (angle to be added in the future). I couldn’t reach a sufficient parent-child structure yet, but every improvement helps.
  • I attached the priorty of the sounds to distance with script.
  • If there is a dense sound usage, instead of trusting the sound priority of the objects, eliminating the play command with if gave better performance. I also eliminated binaural calculations this way.
  • Since binaural calculation requires high precision of time, Fixed update function is a must. One needs to be careful when using with visual elements. Any delays in calculations may result in sounds hitting your head seperately from left and right.
  • Using 16-bit instead of 24-bit increased performance more than I expected. Because there were a lot of sounds for the location design, I converted them to 16-bit.
  • Using wav from memory instead of mp3 is suggested. About file size, I used 34 wav files in 44.1 kHz mono. 12 of them are 24-bit (monster), 22 of them are 16-bit (location). 3.43 MB sounds resulted in a 3.63 MB build.
  • I noticed later that my wav files were 44.1 kHz but Unity was set to 48 kHz. Preventing this convertion will increase performance and prevent loss of audio quality.
  • The sound effects in unity consumes a lot of CPU. If possible preparing different sound files for different locations is suggested. I ti slike hardcoding the effects inside the files. Keep your quota here for essential ones.
  • I decided to try a performance hack by creating virtual objects out of the playground, and throw some of the calculations to the physics motor.

 
RESULTS:

  • I took some steps in audio game development, which I try to advance in the long run.
  • I learned more on development stage.
  • We developed our relationships withing Game Developers Turkey group (GDT).
  • I tried and learned to boradcast live my sessions. I definitely suggest it. While you are on live broadcast, you don’t distract your mind with crappy stuff from internet. This increases productivity. And, you have a recording of your development stage. If you end up with something nice, you can prepare timelapse clip out of them, for promo or as a memory.

 
DEVLOG:
Sorry, I wrote the devlogs in Turkish. But they are here:

Guney Ozsan
19 Haziran 2012

Flattr this!

Leave a Reply