Documentation Showcase Screenshots Videos Acknowledgments

Engine structure overview

Particle effects

Principle to the structure of Mercury is the concept of a particle effect. This is the top level entity in any particle effect, and encapsulates one or more particle emitters (explained below). A particle effect is represented in code by the ParticleEffect class, and will usually be the main interface into Mercury from your games code. The particle effect exposes mechanisms to release new particles and to update existing particles. It does not have any responsibility or knowledge about how the particle effect will be rendered, this is handled by a renderer entity (explained below).

Particle effect - discrete entity in the game world, or a service to be consumed?
When it comes to integrating particle effects into your game, there are two common ways of achieving this. One is to make a particle effect object an entity in your game world like any other, giving it properties such as world position and rotation. Another way is to view a particle effect as a service, which your existing game objects consume when they establish a need to trigger an effect.

To illustrate this point, imagine a rocket entity flying through the sky in your game world. You would like a trail of smoke to emit from the back of this rocket. Using the first option (Particle Effect as an Entity), you would instantiate an instance of a smoke trail particle effect. You would then attach it to the back of the rocket, and update and draw it like any other entity. The rocket entity wouldn't necessarily know anything about the smoke trail being left behind it. Using the second option (Particle Effect as a Service), you might add some simple code to the Update method of the rocket, which looks up the necessary smoke effect, and instructs it to trigger at the rear of the rocket. The advantage of this approach, is that a single particle effect can be shared across many game entities, each one of which is consuming the particle effect service independently.

Mercury has been designed with the second option (PEaaS) in mind, however it is equally able to operate under both scenarios, making this largely the programmers choice.

Particle emitters

The particle emitter is the main work horse of any particle effect. The particle emitter is responsible for updating and maintaining existing particles, and for releasing new particles. It is here that the nature and properties of new particles are defined, such as what colour particles will be; in which direction they will travel when they are released; how transparent and how large they should be. The particle emitter is represented in code by the Emitter class.


While a particle emitter is responsible for applying properties such as colour to a particle when it is released, when it comes to dynamically adjusting particle properties over time, modifiers are used. Modifiers can be used to achieve a myriad of different effects, from simply fading the transparency of particles over time, to applying complex gravitational forces. Modifiers are applied at the emitter level, adding a modifier to a particle emitter automatically makes that modifier act on any particles which are released by the emitter. A modifier is represented in code by the Modifier abstract class.


The renderer object exists outside of the particle effect hierarchy. It is a standalone object which exposes mechanisms to render particle effects to the screen. It is represented in code by the Renderer abstract class.

Last edited Aug 25, 2009 at 12:17 PM by JimJams, version 1