Categories
Game Development

Third (and last?) architecture for the effects system

My first attempt at an effects system was to assign it to my graphics programmer, who decided to define effects in an XML file. The theory was that you could do something like [Effect] – [Particle “fire”] — [Play for 5 seconds] – [Particle “smoke”] — [Play for 2 seconds, delay start for 1 second] […]

My first attempt at an effects system was to assign it to my graphics programmer, who decided to define effects in an XML file. The theory was that you could do something like

[Effect]
– [Particle “fire”]
— [Play for 5 seconds]
– [Particle “smoke”]
— [Play for 2 seconds, delay start for 1 second]

This didn’t work out, in part because the implementation was mindlessly literal so didn’t solve the fundamental problem, and in part because of a lack of flexibility to begin with. As the system became more complex, more and more parameters have to be exposed and you just can’t do certain things.

The second approach, which I came up with, was to tag 3D models with triggers and effects based on locators. So you would place a locator in a file and define in the object properties an effect and a trigger. For example, on the thruster of the fighter I would have “Trigger=ForwardThrust Effect=ThrustParticle” This works, and is good for placing simple location based effects, but is not a complete solution and is hard to use and inflexible.

The fundamental problem, which I didn’t consider sooner, is that effect is such an open-ended term. It would be like if I asked you to write an effects system for a magic based RPG. No matter what system you came up with, I could come up with a reasonable counter-example as to why your system isn’t flexible enough. Effects (especially magic) do everything from lights that spin around the character, to glowing a specific part of the character, to time based events, to modifying and creating meshes, to reading specific game properties. You can’t really apply constraints to a fundamentally unconstrained system. Essentially you see stuff, and stuff happens, based on other stuff.

My third, and I think final approach, is to implement effects with scripts. So I’ll specify triggers in an XML. Each trigger references a script. And the script does all the effects, whatever that may be. If I need to tag specific points on a model, I will just lookup the locator in the .effect file. This should give me the flexibility I need, while still being easy to use and work with.

It’s one of those things that sound obvious when you hear it but wasn’t so obvious to begin with.

Leave a Reply

Your email address will not be published. Required fields are marked *