Mark Cooke’s G-Mixer

Lets finish the discussion of the XML sequencing script system I created for Prescription for Sleep. If you haven’t read part 1 one yet, please do so here.

The final component of the XML scripting system was the ability to add “custom commands” to the XML script. In the visualizers it quickly became clear that some actions would be repetitive. For example, in the “HIKARI” visualizer (can be seen in the free Lite version of the application), when a certain series of piano notes is played little twinkling stars appear, scale up, rotate, then scale down and disappear. This happens many times during the visualizer.

Instead of cutting and pasting the same XML over and over and updating the time for when to draw the little stars, which would have been a nightmare to maintain, I created a way to define series of XML commands that could be re-used. It was basically like programming a subroutine that could then be called from the main sequence XML. By using this, I could globally update the size of the twinkling stars by changing one line of XML in their subroutine instead of 50 pasted versions of the same line. Here’s what it looked like:

<Command name="starpulse" targetRefType="relative">
	<Add time="0" target="star" bitmap="star.png" zLevel="5"/>
	<MoveTo time="0" target="star" x="param0" y="param0"/>
	<RotateBy time="0" target="star" actionTime="1" angle="90"/>
	<ScaleTo time="0" target="star" actionTime="0.5" x="1.05" y="1.05"/>
	<ScaleTo time="0.5" target="star" actionTime="0.5"/>
	<Remove time="1" target="star"/>
</Command>

That defined the custom command. As you can see, there are parameterized definitions for where on screen the stars will appear. Thus this could be called from XML further down in the sequencing with the location passed in for maximum reuse. It was called like so:

<CustomCommand time="8.4" target="starpulse" param0="v_200_250"/>

The time in the <CustomCommand> block is relative to the timeline of the music but in the <Command> definition it is relative to when it is called (almost always doing something immediately at time 0). The backend code fixes up the time automatically.

The parameter passing is a bit too programmery at the moment as you have to specify the parameter type explicitly but it did support parameterizing any variable that could have been passed to a command.

I originally thought I might have put too much time into making this scripting system but now I have to admit I was wrong. It ended up paying dividends, as most data driven systems do, not only during content creation but more so in tuning and maintaining.

While this was originally created to sequence art to music it could also be used as a simple UI framework or even a cutscene system. You wouldn’t want to use this for really complicated scenes but it has a lot of applications for explicit time based sequences that are relatively simple.

This entry was posted on Monday, March 16th, 2009 at 2:16 am and is filed under 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.