by Craig Andera and Chris Sells

I'd been thinking for a while about building a simulation engine that would model objects interacting in free space. It seemed like some interesting effects would arise if I could see them attracting each other through gravitation and bouncing off of each other when they hit.

Of course, a problem like this can consume an arbitrarily large amount of computing horsepower, since the more fine-grained the model is, the greater the number of calculations required to enumerate all the interactions. In fact, we can predict that CPU utilization will grow as the square of the number of objects, since we need to make calculations (i.e. gravitational attraction, collision detection) for each unique object-object pair. So it made sense to do the actual simulation on a large server machine with lots of CPU horsepower and memory.

Most people don't have big, multiprocessor machines. What they do have is Internet connections and video cards that are very good at rendering 3D imagery. So it made sense to write a back end that would provide the simulation data, and a client piece that would actually draw the scene. And if I leveraged XML as the mechanism to get data between the two, I'd be setting myself up to enable clients written on any platform to consume the data.

Defining the Problem

The complexity involved in doing a truly realistic simulation would have required a multi-man-year effort, so I decide to keep it simple. The system should:

1. Model objects moving in three dimensions (2D is so 1980s). Objects should attract each other gravitationally, and bounce when they hit each other.
2. Use web services to allow me to leverage farms of server machines with lots of CPU to do the simulation.
3. Render the data with a rich client to leverage the graphical horsepower of commonly available PCs.
4. Be written in C#.

I settled on a solution with three major components:

1. The simulation engine. This is where the actual computation that figures out how to move the objects takes place. This component lives on a server machine.
2. The web service. This is where the data from the simulation engine is turned into XML for consumption by the client.
3. The client. This is where the data obtained from the web service is rendered. The client also has to the have ability to send to the simulation engine, via a web service, control messages like "pause" and "resume."

This solution is quite similar to a more traditional three-tier system with browser, web server, and database components. This is often true of XML web service solutions in general, and is a Good Thing, since it means they're amenable to many of the same load-balancing and fault-tolerance mechanisms that traditional web applications enjoy.

This architecture is shown in Figure 1. The idea is to leverage XML between clients and servers to allow clients to be written using any technology, and to allow each tier to be spread across several machines, to give us access to large amounts of CPU horsepower-if we decide we're going to model a million objects interacting with each other, we're going to need it!


Figure 1 - System Architecture

We invite you to post a comment (not monitored by customer support) on this page or send a question directly to our support team.