Would you believe it – I don’t even have enough free time to make a little speedgame?!? Maybe I was over ambitious but I’ll get to that.
So my entry into the Christian Developer Network’s 2011 SpeedGame was going to be a Robot-Unicorn type game but with a cat. We each had to pick a verse as a theme for our game and I chose Proverbs 15:24 – the lolcat Bible version.
Proverbs 15:24 – Smrt kittehs go up, not down to da basement.
The basic gist of the verse is wise people are on a path leading upward and they turn away from death/hell beneath. I made a game about a cat that falls asleep during a thunderstorm and dreams that it is running away from the storm, jumping from platform to platform as the storm gets closer and closer. Really simple concept – I mean you just have two controls, jump and fire. Jump to stay on the platforms and fire to deal with obstacles in your way. The obstacles would slow you down and if your cat doesn’t keep ahead of the storm approaching from the left side of the screen it gets soaked and you lose! This post is about the game dev process and the hiccups I had along the way that I’ll share my solutions for and hopefully they will be helpful for other Ogre game devs.
But first – a simple rundown of the tools and libraries I used for the game:
– Ogre 3D graphics engine (duh)
– Box2D physics
– OpenAL audio
– Gorilla GUI
– OIS for input
– Blender 3D for models
– various free model and sound websites for the developer/test content
OK, so in the roughly 20 days we were given to do actual dev work on the project I decided to build a cross platform twitch based game. That was the first hiccup. I spent roughly 2/3 days just getting basic Ogre working on Windows, OSX and iOS. What I did was download the SDK for Windows, OSX and iOS and then I set up this folder structure to house it all.
– design <– all my design files
– GameiOS <– iOS specific XCode project
– GameOSX <– OSX specific XCode project
– GameWin <– Visual Studio 2010 project
– lib <– Box2D and OpenAL libs/source
– media <– all models, sounds, graphics etc.
– src <– all the shared source code
Cross Platform Luv
Windows was cake to setup for just about all the libraries. iOS was a bit more difficult because you have to compile the libraries for the right architecture to run on the device and different ones to run in the simulator. OSX had issues with just working at all. I tried to use the XCode 4 templates to create a new project but even when I got it to compile it would crash on startup. Eventually I found that if I moved the log manager initialization to a line after Ogre::Root was initialized then the crash went away and I could proceed. So all that debugging on OSX and the extra iOS configuring took me a couple days of free time.
Oh, and OSX fullscreen mode just doesn’t seem to work — which was annoying because I had to restart my computer to regain control.
After getting the demo app working cross platform I put it all in a GIT repo (always a good idea to backup your code).
Physics Physics Physics
The next step was actually implementing the game, so I created prefab boxes in Ogre for the player model, the platforms, the bonuses and walls – everything and tried to hook up the Box2D physics. It wasn’t that hard to create a Box2D hull for all the objects because they were all square initially – however I ran into major issues getting the Box2D step() function to be framerate independant. In fact, to this day the physics speeds are different on each platform even when I confine the framerate to roughly 60 fps, and this annoys me to no end! I even got a helpful hint from azrialelf on the Ogre forums that he just created a framelistener and told Box2D to step with the evt.timeSinceLastFrame as the time delta. This does work OK, but it still doesn’t behave the same on all platforms and still seems to be affected by framerate somewhat.
One other big gotcha with physics on iOS and OSX is that the demo app run the main loop with a timer set at 60fps where as the windows run loop is not timer based and runs as fast as your gfx card can go. This really brought out the Physics step problems because my windows game would run at like 2000 fps and the physics wouldn’t work at all while the iOS version would be really slow and the OSX version would be fast — even though they used the same physics settings (they shared the same code). My plan to address this is to just tweak it so it feels OK on each platform and not kill myself trying to figure it out.
OpenAL Lacks Decent File Import Capabilities
OpenAL was surprisingly easy to set up for all platforms. The only issue I ran into was that there didn’t seem to be builtin support for reading any audio formats – so I just grabbed some code off the internet for reading .wav files without ALUT. I did find solutions that involved using iOS/OSX libraries, but I wanted something that would work across platform. Eventually, I plan on adding the ogg vorbis file libraries and using those to load compressed audio files.
Blender? I barely know her!
The next step after I got the basic physics working with some silly sounds and keyboard/mouse input, was to create some models in Blender and get them in game. My idea was simple – create a platform object that had two meshes, one as the actual mesh and one that was the physics mesh. Sounded simple but was actually pretty crazy. Turns out making an object with two submeshes is actually no big deal. You just enter into edit mode for the object and select each mesh in turn and assign them to different materials. I named one material Platform and the other Physics. Then in my Ogre code after I imported the model I looked for the submesh with the Material name “Physics” and used the vertices from that Submesh for the Box2D Chainloop physics hull – oh yah, you have to use the latest version of Box2D from the repository to get this nifty hull type. The crazy thing about this process was I had to walk the edges in the Physics mesh to form a closed loop for the Box2D hull. Fun fun.
The biggest hiccup with Blender was getting the model with the two submeshes into Ogre with all the vertex data intact. When I used the latest version of Blender and the latest version of the Ogre exporter for Blender the files that were generated used shared vertex data, and when I tried to read that shared vertex data in Ogre it didn’t exist! Crash-o-la. Solution? Use the older version of Blender and the older exporter that doesn’t use shared vertex data and it works. Boom.
Silverback
I chose to use the Gorilla GUI for Ogre because it was two files! – and I saw it in action in the Ogre forums and had to try it.
It’s super basic and you have to do everything, but it is fast and once you get a feel for what it can do it just makes sense. I also found the demo console app to be really handy.
In the End…
I just didn’t have enough time to finish. I wasn’t supposed to be working on this alone, but my other teammates had other things come up. None of the art or animations were made and I never added the background music and ambient sounds that would have really helped it. Of course, even a legit background would have helped!
I learned a lot from the experience and did have fun and plan on bringing the game to a releasable state in the future. Until then I will return to OGE, My First Planet and Spacescape dev work in my free time.