Dino Interactive

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 !