Pulling GUI and Sounds

Another developer on the team has created GUI component of the project along with a new project states management - GameStates. This makes for a better approach then old way of simply following OGRE demos code. Now, GUI and the rest of the code are tied up. And more importantly the code feels a lot better, that is cleaner and easier to maintain.

Another big component that made its way is Sound. For this, I rewrote my old code for OpenAL to work with Fmod. I had some problems with OpenAL running on my Windows, so I decided to ditch it. When comparing Fmod with OpenAL, Fmod has a slightly better interface since it uses a bit of C++ as opposed C-interface of OpenAL (I prefer OOP when dealing with large project such as Ukrainian Rumble). The problem however is that Fmod still feels like a C-library. Even though it offers "Objects", they are very rudimental. For example, error handling is done by each function returning a FMOD_RESULT objects which is a enum (yes, every function does that with a few exceptions). So after each Fmod call, you need to call some method to check for errors. This is rather annoying. Exception handling would be much better, but those guys have their reasons. Nice C++ interface is not on top of their list. One way or another I made a wrapper around Fmod to give myself something I can live with. Other than the interface, Fmod seems to be a powerful system that supports all major platforms, including upcoming next-gen consoles.

Now, writing a wrapper for Fmod is a simple task compared with making sounds feel right for the game which heavily relies on physics. This means that I am dealing with a "messy" system (physics engine) that does not provide exact same results for every run. Furthermore, physics give you a range of results. For example, let's say you want to play a sound for each collision. OK. I create and assign the right classes, etc. Run the application. Here is what I get: a sound for each collision, no matter how small or big it was. Alright, a threshhold is put in place, and now collisions are filtered out. Now, I notice that those collisions don't reflect real life, for example I might get 5 collision for an object simply sliding. Another thing is that collisions vary in magnitude (big and minor ones). So, now I need to add a filter to set a correct volume of the sound. After this, we get into situation where different collisions should sound different. Think of sliding motion or simply different surfaces. Mmm...

One note about sound. Once you add one, you need all of them. This is because with no sound you don't notice that everything is silent, but once you have a single sound effect, your mind expects to hear other sounds as well.

All in all, GUI and sounds add a lot to the project. It feels more complete now.