Considerations about a simulation game

Question

The kind of simulation game that I have in mind is the kind where you have things to build in various locations and workers/transporters that connect such locations.

Something more like the Settlers series.

Let's assume I don't want any graphics at the moment, that I think I can manage.

So my doubts are the following:

1. Should every entity be a class and each one have a thread?
2. Should entities be grouped in lists inside classes and each one have a thread?

If one takes implementation 1, it's going to be very hard to run on low spec machines and does not scale well for large numbers.

If one takes implementation 2, it's going to be better in terms of resources but then...

How should I group the entities?

1. Have a class for houses in general and have an Interface List to manage that?
2. Have a class for specific groups of houses and have an Object List to manage that?

and what about threads?

1. Should I have the simplistic main game loop?
2. Should I have a thread for each class group?
3. How do workers/transporters fit in the picture?

Answer 1

I'm fairly certain you only want to have one thread executing the game logic. Having multiple threads won't speed up anything, and will only make the code confusing. Having a main game loop is perfectly fine, though things get somewhat trickier if the game has multiplayer.

I'm a bit confused about the part of your question relating to classes. If I understand your question correctly, my suggestion would be to have a class for each type of house (pig farm, windmill, etc) deriving from a common abstract base class House. You'd then store all the houses in the game world in a list of Houses.

Answer 2

The normal approach does not use threading at all, but rather implements entities as state-machines. Then your mainloop looks like this:

 while( 1 )
{
    foreach( entity in entlist )
    {
        entity->update();
    }

    render();
}

Answer 3

I would avoid making a separate class for each entity because then you'll have situations where you're either repeating code for shared capabilities, or you'll have a funky inheritance tree.

I'd argue that what you want is a single class and objects with functionality composed onto it. I saw an article on a blog talking about this very concept in an RTS...wait, I think it was a tour of design patterns that someone was writing.

Use the Visitor pattern spawning a thread on each object's DoEvents (for lack of a better word) method to tell each object to do what it's going to do during this given loop. Sync the threads at the end of your loop because you don't want to have some objects with complex logic still doing its thing from ten loops back when in reality it was destroyed five loops ago.

Answer 4

The MMORPG Eve Online uses stackless python and the actor model to emulate a thread-per-entity system without the resource hit.

Check out this link for more information: http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/

Answer 5

Think about using Erlang. With Erlang you can spawn a lot more processes (= lightweight threads) than a normal system thread. Further its distributed, meaning if your system isnt good enough, add another node.

Another alternative would be stackless python (or the current python alternative), as it also support some kind of lightweightthread, which is very cool for game engines. Eve Online uses it for its servers. But it isn't distributed, but that can be easily achieved manually.