As we are working more and more on production-quality art the work we do on tools tends to get more pragmatic – it is mostly fixing bugs and any new features are carefully considered in terms of how much they will improve our workflows and/or visual quality. Not that we didn’t do that before, but as we are finalizing the visuals in spaces it gets easier to tell what could be an improvement and what would be cool, but ultimately unused.
One thing I wanted to touch on was our effects – we had some pretty good particle systems supported as I mentioned in the post about curves, but they were tied to specific game objects and required a good amount of setup to add and edit. This made them somewhat useful for environment animation, but not as useful for situational events – things that you want to use effects for. With that in mind, it felt like a good idea to revisit the system before we started to ramp up on effects and I’m going to briefly go over the process and goals here.
This is how the old system looked – not too bad considering the context in which the engine was built, but it had some big flaws. For starters, changing or even viewing any of the parameters meant going into a separate menu which made it difficult to get an overview over what caused the effect to behave the way it did. Even if it only took ten seconds to change a single value, when making effects that hinged on several different attributes it could take minutes to change all of them which would make iteration slower. In addition, only a select few of these values could be changed with curves so the effects would typically be very static and frequently look like variations of the same movement rather than unique effects.
Moving effects to their own class of graphic object and making the editing more immediate was straightforward enough, but deciding how far to push the system was a bit more difficult – as an engineer, starting with a system as described by bitsquid or Sucker Punch was tempting, but way more complex than we needed. Similarly, a system like in 3D modeling software is less focused on scripting solutions but still a bit too flexible for our needs – I wanted a system where the bulk of the settings could be viewable at a single time but still have enough options to experiment with varied styles. At the same time, it couldn’t take too long to implement.
Ultimately, I narrowed the effects down to three distinct parameter groups – emission, transformation and material – and picked out what I felt would be the most important parameters of each.
The emission settings are fairly light as there is not a lot of point having many different 2D shapes to emit particles from. The emitter would also keep track of its own lifetime as well as the emission rate and lifetime of the particles it emits. I wanted an option for creating particle bursts at given moments and opted for the simple solution of just defining a minimum value of particles that should be active at any given moment.
Again, not having to concern ourselves with movement in three dimensions simplified a lot for us – I essentially only provide values for scaling, rotation and movement. This being one of the areas I was not sure how far we would want to go I opted to provide movement options both in world space, parent space and local space. World space is useful for effects that rise to the sky or fall to the ground regardless of how they are emitted, parent space for when the effect is shooting out of something you do not know the direction of beforehand and local space when you want the particle’s movement to be dependent on its position relative to the emitter, for instance when you want it to burst away from the center.
While the first thing I added was simple sprite particles with options for multilayered materials, we have also long supported the creation of stroke particles that are rendered as textured strokes along predefined spline shapes. Having all the transformation options available to the stroke particles was a win in itself, but the system also made it easy to control the draw speed for the stroke in an intuitive way so it works a little bit better than before.
Even with the limited feature set there are already some options that feel like they will not get a lot of use, but luckily not a lot of time was wasted. We’ll see just how many effects we can squeeze in without it disrupting the visual style, but as with any effects system I am more concerned about performance. That will be a topic for another day though.