Dino Interactive

More than a month has passed since the previous update, I was too busy to write an entry in the blog. I can definitely say now that writing a game is hard, but writing it without a correct methodology (and previous experience) is even harder.

I spent lot of time working on tools and frameworks when instead I should had spent more time working on a prototype; just working on a demo made me realize much better what I need to do to reach the end and what tools I need.

I also learnt not to use a physics engine. Why ? Because it's much easier to simulate physics without using a physics engine than simulating "arcadeness" using it. When your characters need an almost real behaviour, don't use a physics engine !
It's easy to decide, there's only one question you have to ask yourself if you are in doubt about using a physics engine or not. The questions is: am I building a simulation ? If your answer is yes, then you better not reinvent the wheel and choose a physics engine. There are several out there but I can comment only on ODE since it's what I used. But if your answer is not then it's probably going to be easier to roll out your own custom physics engine, specialised for your game.

Another important lesson I learned during the latest month was to write the tools using the technologies that I know the most. I'm writing a track editor that I would like to include within the game to allow users to create their own track. I still can't write anything else than basic text and lines using the GUI system offered by the 3D engine I'm using, and this restrain my freedom to explore the best interface to adopt. Although it is true that one day or another I'll have to master this API, at least now I have a working track editor written in PyQT that I have quickly written and that allows to me create track and progress with the game.

But the biggest lesson I've learned is to write prototypes, as soon as possible. For the next months I'm going to stick to a Prototype-Driven-Development methodology. A quick search on Internet didn't reveal a specific definition, but to me it means shaping the final software thanks to the continuous improvement and re-factoring of prototypes. The biggest advantage of using this approach is that it make you realise exactly what your game needs in order to work, and that allows you to shape your framework around your game, always trying to keep it as generic as possible though, if it's a framework you're probably going to reuse it for another game.

I've completed the first prototype last week and I'll complete the next two hopefully in the middle of March, then I'll finally be able to post some screenshots so keep staying tuned!

About a month has passed since I started working at my game. I had a couple of interruptions along the way, I've been in Lisbon for almost a month to work on a data visualisation software for the SMOS mission, then I went home for a week at Christmas.

Not to mention two big losses, the hard disk of my beloved 12'' Powerbook failed, and my other laptop, a Fujitsu-Siemens Amilo laptop I bought 6 years ago died. The same day.

...

But apart from these distractions I'm working hard at the world editor. There are many challenges I didn't foresee before starting, the most interesting one being the design of the application, particularly the way to decouple the various systems, input , rendering, physics, logic and more.

I've basically rewritten the editor two times and a half. The first time I concentrated on learning the Panda3D and ODE API and implementing some basic functionalities into the editor, like objects picking, camera, input detection and integrating the physic engine. As soon as I was confident enough with the libraries I've rewritten most of the application to follow the architecture described in the fantastic book Game Code Complete. After the rewrite I had more functionalities and 400 lines of code less. Unfortunately it wasn't so easy to get it right, and I struggled even more when I decided to make the application almost entirely data driven. In fact once I had almost finished to redesign I stumbled upon some articles about data-driven game systems and entity systems and I rewrote about a third of the code to follow these approaches.

I didn't build an entity system, but I designed the entities in the game basically as a collection of properties. I found several advantages with this approach, mainly:

• Very simple class hierarchy, almost flat. I found that this is the biggest advantage. Having struggled in the past with complex hierarchies I'm happy to use this approach now.
• Serialisation/deserialisation very easy. I just dump the current properties of the in-game objects using the same format I use to load them.
• Easier modification of the object properties from within the editor. No need to call a different method for each property of the object to modify (setSpeed, setPosition, setMaterial etc...) except the one to actually modify the property.

Not everything is going so well unfortunately. I still have troubles with Panda3D input management when integrating the window within a wx frame; I found the wx library much worse then GTK in terms of API, and debugging is very difficult as most of the times the application just crash without any output message. The advantage over GTK is that it is more cross-platform. As I still haven't written lot of GUI code and considering that QT has just become LGPL, I may consider switching again...

I guess that's all for the first episode, this post is becoming too long, next update in a couple of weeks !