Designing the main classes in a solar system simulation game in C++

Question

If this is not the right place for this question, could you please direct me to a more suitable site/forum?

I'm a beginner in game development (and in the use of this site). I've worked with C++ only for rather small scientific simulations, so I can "code" but I've never done a full-blown design of an OO program, much less of a game. You can tell from what I'll write next :P

I've decided to write an open source educational game that simulates accurately the motion of the Sun, the planets and of one or more spacecraft controlled by the player. By "simulates accurately" I mean that I want to use a scientifically valid and precise algorithm to obtain the forces and thus the motions of the bodies.

The game will be in 3D and will use the Ogre3D engine for the graphics. Graphically it will look similar to Celestia.

The first difficulty is that I've never designed the structure and the classes of any game. By reading a few references and guides I think I have a vague idea of how the dynamics could work, but it's vague: each entity (planet or spacecraft) could store its own state information and then have an "update" function that updates the state based on some input (like user commands). There are probably many other ways to do this, I guess.

The main problem, however, comes from the particular needs of this project:

1. my objects must not only respond to user input, but also obey accurate physical laws, and the algorithm that computes them must be centralized. This is because it needs to know the positions of all the bodies at the same time to perform its computations;
2. I plan to add different kinds of spacecraft with different types of propulsion, and some of them would react to the other bodies in special ways (think antigravity).

The Question

Is there a design pattern or architecture suitable for this problem?

The best I can think of is to have a singleton Universe class containing the central algorithm for the dynamics. The various objects of the solar system then communicate with Universe. They would contain basic parameters like mass and size, and they would listen to Universe telling them where to stand.

However this doesn't sound right. Where do I put the ever-changing trajectory data of all the bodies, in Universe? What's the point of having all those objects then? Only for the graphical part of the game?

And what about the special dynamical properties of some spacecraft? I can't possibly include them all in the central algorithm from the beginning.

---

Ok, I think you can tell how confused I am about the matter much better than me. I would be grateful for any kind of input.

Answer 1

Don't conflate the physics modeling of the universe with the graphics, that way leads to madness =) For something like what you're talking about an MVC architecture might work well.

M = model. Your model is the physics simulation of the universe. While this may be a singleton you'll find many more arguments to making it a class that can stand alone but of which you could make many. Your model is responsible for number crunching the simulation, that's it. This is completely independent of Ogre and would exist as pure data.

V = view. Your view gets its parameters from the Model and decides how to render them. There can be many different views of a model; maybe you have one that shows a condensed overhead, a second view that follows a spaceship around, and a third that, well you get the idea. A view simply looks at the model and shows it to the end user, and each view is specialized so you don't have a mega-view with a million options. This is where you would extract the numbers from the model and set them into your Ogre objects to render.

C = controller. The controller is where you interact with the model, adding new physics objects or piloting spaceships. Note that there can be many different controllers, one for each spaceship that an AI or end user controls, you get the idea.

The rest of your program is now a framework to setup and run the MVC.

There are many other ways to design your idea, MVC is mainly suited towards information displays and games like Eve but it does let you neatly organize how your program works.

You'll get many more ideas from other people but no matter how you choose your final design please separate the simulation from the graphics.

Answer 2

You need to define "accurate". Even Newtonian Mechanics is not accurate enough to simulate Mercury properly. Newton is off by 43 arc seconds per tropical century. This was discovered with technics used in 1859, so its not a small deviance. In fact this was the first test case for Einstein's Relativity Theory, and he succeeded explaining mercuries perihelion precession using this theory. Most likely you don't want to use Relativity Theory for your simulation, so you probably need to relax a bit on "accurate".

Answer 3

In PseudoCode

   GBody {
       Velocity as (x,y,z)
       Name
       Mass
       Acceleration as (x,y,z)
       Position as (x,y,z)
       Diameter

       void update(){
       //do update math here
       }
   }

   GBody Mercury=new GBody( Mass=10,name=Mercury,...)

   do{
     //iterate through GBodies
      Mercury.update()
    }while (sim is running)

• gbody is gravitational body
• use a list to keep all the masses you are tracking in the n-body problem.
• the ship should probably be a camera with seperate physics. (wouldn't want to have the ship crash into the sun.
• use simple spheres with bitmaps for the planets/moons etc.
• to simplify the math sun is fixed at 0,0,0.