Duck Engine

09/02/2011

In games there is often a task to create a lot of hand-made objects. I don't just mean in the visual sense but actually in the programming sense. Often you will need a large number of material objects with various properties. Or perhaps you need a large number of "item" type objects such as weapons and collectables.

All of these tend to come with a number of parameters, properties or stats and they are often related and interlinked. Even so, there hasn't ever really been specified the best way for these objects to be marked up.

Lots of games use XML, or some other engine based scripting language. An alternative is to have a GUI tool which artists or whoever can use. Often these two approaches are used in combination - to variable results.

One idea I've had floating around my head for a long time is to do this object markup in Python. There are several advantages to this which anyone who has dealt with XML will appreciate:

• Python has lightweight, familiar syntax for objects.
• Python natively supports lots of collection types - tuples, list and dictionaries. More expressive than just a tree structure.
• Syntax of marked up data can be checked easily for errors before even running the application using it.
• Having a python backend means that there are lots of powerful ways to create shorthands or even automate repeated tasks.
• A parser is already written, and allows complex ways of manipulating the data.
• I love working with python.

So I went ahead and implemented object markup in python for various programming languages. I decided to compile the python objects to binary files. This meant that loading would be faster, and also acted as an intermediate form to make writing loaders in various languages easier.

I also added the idea of a reference as best I could, because otherwise in python it is impossible to keep references to native data stuctures.

With these together I intergrated what was then called PyMark into what is now called DuckEngine.

For DuckEngine I didn't want to commit to anything too early. I wanted the engine to be a relatively fast way to throw together prototypes so, like with PyMark, I just wanted to work on things that would allow this. The next logical step for a prototype engine is a powerful scripting language, and with the fact I was already using python to mark up objects, python seemed the logical choice.

So I did this. Scripts have the ability to pass around most native data structures between the engine an themselves. Ways to pass custom classes can be defined. Scripts talk over IO using the stuff I did for PyMark to represent objects as bytestreams. This works pretty well. It isn't as nice a fit as for object markup, as scripts can't really be checked for errors until runtime, and there are a couple other nasty issues which can bite back, but it's still cool for a scripting language.

As well as these two I added a few more cool features to the engine like some flexible rendering techniques and generally an open-ended approach, but enough waffle, here is the video.