Some Notes on Architecture

Some commonsense ways of coding particle systems have evolved through the years. Basically, two "patterns" exist, which are suitable in different scenarios. On one end of the spectrum, some teams code particle systems as a class hierarchy, so we have an abstract "particlesystem" class, from which specific particle system classes would be derived via inheritance. Particlesystem would declare virtual members such as recalc and render, which would be provided by each individual system or even by the particle class itself. Here is an example built using this technique:

class particlesystem
   {
   public:
   point position;
   particle *data;
   int numparticles;

   // methods executed from the base class particlesystem
      void create(int,point);   // creates a system of N particles
      void recalc();   // recalcs all particles

      // methods to be defined by the specific classes
      virtual void paint();   // paints the N particles.
      virtual void respawn(int);   // re-generates particle i
      virtual void affect(int);   // calculates the interaction of particle i with the 
environment
   };

class rainfall: public particlesystem
   {
   public:
      // specific params
      point throwv;
      point pos;
      float initvel;
      int texid;
      double maxttl;
      double minttl;
      double maxvel;
      double minvel;
      double xrand;
      double yrand;
      double zrand;
      double movx;
      double movz;
      color ocol;
      color fcol;
      point wind;
      double density;

      rainfall() : particlesystem(){}
      // rewritten methods
      virtual void loadparams(char*,point);
      virtual void respawn(int);
      virtual void affect(int);
      virtual void paint();
   };

Using this approach allows us to arrange all systems in the game world in an array and access them linearly using a common interface. Each system can still be different, from the parameters to the physics simulator. But all those details are hidden from the programmer, who can access them using a homogeneous interface. Take a look at Figure 19.4 for a diagram of the data structure.

Another philosophy is to create a deep, complex particle system class, where individual systems are nothing but data-driven objects that parameterize the class in many ways. In this case, we would have parameters that would define almost anything, because all particle systems in our game would be implemented in the same class. We would need Boolean values to turn on or off specific forces, texture coordinates, and so on.

The advantage of this second method is simplicity. After all, many particle systems can be implemented from a central piece of code, possibly using some switch constructs along the way to select parameters like the type of emitter or velocity, and so on. Another advantage is that you can create a graphical editing tool that allows you to parameterize the particle system object, and thus easily test new particle system ideas from an artist/content developer perspective.

In the end, the difference lies not so much in raw speed, because both methods have advantages and disadvantages in this respect. It is more a problem of what you want. That is, do you want many systems that are very different from each other and share almost no code at all, or systems where we can recycle most of the source, and thus can be implemented in a single file that can be heavily parameterized?