Caswal

I have used FMOD on and off for various small hobby projects for years, and found it straight forwards and easy to use. It is very quick and easy to initialise and integrate into your game environment. It has a few caveats. Make sure that your listener up and forwards vectors are unit lengths and perpendicular to each other, or strange results will follow. Also the 3D sound example uses DISTANCEFACTOR in both the set3DSettings function and as a multiplier to the various set3DAttributes functions. You only need to set it in set3DSettings, after that you do not have to worry about trying to scale the positional data into the listener or channels.

This weekend I took the plunge and used the FMOD Designer and used the Event System API. The event system class replaces the normal FMOD System class(which can be retrieved). Therefore you still have access to the old style of doing things.

The power of the FMOD Designer is quite immense, I was quickly and easily making sound effects that would of taken about 30 mins of writing and testing in my game in just a few minutes. Such as our dyno fan sound effect. Which is basically a looping fan sound that I pitch shift and change the volume of. In the designer both of these effects can be linked to a float parameter.

You can then load this sound effect (known as an event) start it, and change the parameter value at run time to give the desired result. Nice and easy.

My only complaint about the Designer, is not being able to configure a build output directory.

I am sure it can do a lot more than I have figured out yet, but so far I am very impressed.

This rant is more aimed at students, and people just starting games programming, but feel free to comment!

Rate of iteration is key in games development. Longer iteration times lead to longer development times, or a worse game.

What do I mean by Rate of Iteration? The time it takes to tweak a value or change a function and see or test the result. If to change how high a character jumps requires you to quit the game, change some C++ constant, recompile, start the game, navigate through menu’s, load the game, get back to the point you were testing, to only find out the value is still not right. This is too long, how many minutes did that take? To only change one small value within the game.

So how can this be improved? You can start by pushing as many values as you can into config files, like XML or just simple text files. When your game loads, the various elements on construction serialise in their various settings. You have now saved yourself recompiling the project everytime, that in large projects can get excessively long. Some may argue that it takes time to set these systems up, but with generalised systems in place it only takes a few minutes more than just writing the code you had before, and it will save you a lot of time in getting your game that last 10%.

We can of course, cut more than just recompiling out of the picture. What if we can hot load the changes while the game is playing? After all, we are just loading in values from a file, we don’t have to do it only at load time. The simplest approach is to set a hot key,e.g. F12 to get our entities and other items to reload their values, a more complex way is to watch the date modified on the file and if it changes load them in (although if you are a obsessive saver of incomplete files this could be a problem). We have now cut our long slow arduous cycle down to a quick Edit -> Save -> Hot Load.

This doesn’t help for game logic,  the system I have in place for that is all gameplay logic is run in Lua, with various directories to divide scripts by executing type (Init, Data, Functional). Init is only run on game launch for various setup, but both data and functional can be hot reloaded at any time.  If there are syntax errors they are caught, displayed in a Message Box, give me time to fix them and then attempt another hot load. Now I can update game logic and variables without having to close the game (within reason).

One last point that really irks me is when students implement intro systems (such as splash screens, movies etc), when you have tested them, disable them!!! It reduces your rate of iteration, and by knock on, makes them worse.

</rant>

Back to me writing random ramblings.

I am thinking of making this blog a bit like notch’s of minecraft fame. Talking about what I have been doing in a more technical and seperate manner to the automationgame.com main page.

I hopefully will provide code snippets, thoughts and feelings on items, as well as little side projects.