Mark Cooke’s G-Mixer

Working freelance on multiple projects simultaneously has caused me to think a lot about what is worth doing and what is not worth doing. My time feels shorter than ever – because it spread more thin – so focusing on the tasks of highest importance at all times is key.

Sometimes this is very hard to do. Especially if the task I am doing is useful, technically sound, and/or clever. But even if you are doing something that encompasses all of the above it still might not be worth doing… which can be a tough pill to swallow.

Here’s an example – I’m currently working on a project where graphics need to be sequenced to a music track. I created an XML definition for the sequencing so it is primarily data driven and created a little scripting language via XML tags for doing things like moving/scaling/rotating/fading/tinting sprites. It’s working great and dramatically sped up the initial sequencing.

While working with this further, I started to see lots of cut and pasted XML script to repeat the same kind of action. Just like cutting and pasting runtime code this is terrible for maintainability. I wanted to make subroutines for doing multiple combinations of moving/scaling/rotating/fading/tinting that could then be re-used in 1 line of XML to do something more complex. E.g., scale up an object, move it left 100 units over 2 seconds, tint it red, wait 2 seconds, then destroy it.

There were two clear ways to do this:

1. Add new complex commands to the runtime code – hardcode a list of simple actions into a class that does something complex – and then expose them in XML. Still data driven but more specific to the use case and multiple of these would have to be added over the course of the project.
2. Create a way to define these subroutines in the XML itself. This is more extensible and could then be quickly tweaked without recompiling the code.

Being in a “data drive everything” mood I chose the latter and went to create the ability to define a subroutine of commands in the same XML sheet the sequencing commands live in. Basically this was more or less creating a programming language with subroutine calls and passed parameters (albeit very limited in scope). You can define subroutines in XML that do a bunch of sequenced actions then call that subroutine from the XML in the sequencing block. This is far from the most difficult task I’ve completed as a programmer but it was definitely time consuming to set this up in a generic and parametrized way.

I just spent the last 8 hours working on it and I’m not sure it was worth the time. This is a small project and adding some extra subroutine types in a half-data driven half-hardcoded way may have been smarter as each individual case would have taken about 5 minutes to build (and the number of individual cases is unknown… maybe it is just a few!). If this framework was going to be re-used many times by many developers doing it the fully data drive way would have been worth it for sure. But for something that may end up being a one-off I think I should have waited before committing the time to this unless I was sure it was necessary. The agile programming method would have told me “do the simplest thing that will possibly work, refactor later if you need to” which I don’t think is correct 100% of the time but is correct the vast majority of the time.

Live and learn.

This entry was posted on Saturday, February 14th, 2009 at 6:18 am and is filed under business, game development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.