I am creating my own game engine just for fun and brain development. I have chosen various free and open-source libraries to integrate and now I have come to the engine architecture.

I intend to use server-client architecture and I prefer to be more "data-driven" so I can organize my game state in MySQL database. I recently read about a component based design which plays nicely with data-driven systems. The idea is that game object components are bare properties and the behavior is implemented in so-called subsystems. Each subsystem (like Physics, Render, Animation, Sound) "knows" only about related components and also is able to tie itself to other systems if needed. Those subsystems are singletons (single instances).

I can use the observer pattern so each subsystem can subscribe to property changes which are important for the particular subsystem. The subsystems subscribe to prop change events in some particular order thus creating subscription chains. But this can create one problem: SystemA detected change in propA and needed to change some propB, but SystemX is listening to propB changes and affects propA .. and we have an infinite loop. Is this a common weakness of such systems or I have wrong implementation ideas?

The last system in the subscription chain could be the NetworkSystem, which sends out a small package on every subscribed property change ... or it is a bad idea and I should pack more changes together?.

I guess, rendering and physics will be separate threads where RenderSystem (client-side only) is polling the entities for their properties which have changed since last frame and PhysicsSystem is modyfing properties on each iteration; InputSystem (client-side only) and NetworkSystem also are modifying properties and WorldClockSystem could modify some properties on timer events.

But the major problem is when I think how to implement custom scripting in such systems. Let's say, users are allowed to upload their custom logic and animation script called Respect which has one property called goodDeeds with a rule "if a person with goodDeeds>100 passes by, I run some RespectAnimation". So I would install a global RespectSystem which subscribes to position changes of every character and checks for the Respect component and goodDeeds property and then somehow tells to Animation system to run Respect animation on this object. Is this the way it is supposed to work, isn't it dangerous that the behavior now is a global object and not a property of the entity which uses it? If I think again about the problem of neverending loops of observed/modified properties, it means that one wrong xxxSystem script could stall the entire server (but from the other hand, the admin of the server should have enough sanity to see such problems before allowing the user to upload that script).

Anyway, it would be great to find some book or article which better describes how to use component-based systems where components are properties and behavior are singletons, but somehow all articles I have read, explain only the idea itself but not how to attach it to a real game engine with scripting and networking.

  • \$\begingroup\$ -1 This question(s) sound(s) like a show off case for how many design patterns and buzz-words can be mentioned in X sentences. \$\endgroup\$ – Maik Semder Aug 20 '11 at 18:08
  • \$\begingroup\$ But all the mentioned things are related and part of almost any game engine, the problem is that I have to tie it all together. For example here: gamedev.net/topic/… is the solution which I took as a base for component system implementation. That thread also tells that observer pattern is a good idea in such a system. Is it not? \$\endgroup\$ – JustAMartin Aug 20 '11 at 18:47
  • 2
    \$\begingroup\$ You might want to break this down into individual and focused questions, the scope here could lead to an entire book. Also note that if you have trouble shoveling your game into a particular design paradigm then maybe a different paradigm is called for. \$\endgroup\$ – Patrick Hughes Aug 20 '11 at 19:04
  • \$\begingroup\$ Ok, I agree, I got carried away. Although I put bold style on 3 certain points which interest me, how other people have implemented those features in their systems. \$\endgroup\$ – JustAMartin Aug 20 '11 at 19:53
  • 1
    \$\begingroup\$ Each of those three bolded points can be a more focused question. I suggest editing it down to one of those and focus on that for this question. The networking bullet in particular is a completely separate topic. \$\endgroup\$ – Tetrad Aug 20 '11 at 20:10


It's not a weakness in the system, but a weakness in your game logic. If the value of propA depends on propB and probB depends on propA then you have cyclic dependencies. It doesn't matter what system you use, this can't work.

Of course, it could happen by accident, but it's easy to detect cyclic dependencies, so you can provide diagnostics in those cases.

Do you have a particular example of where you think this might happen, or are you just thinking ahead?


Generally, you want to pack things together as much as possible in a network situation because each packet will necessarily have some overhead.

Also, sending property changes across the network isn't going to work in the general case. There are many approaches to networking games, and each approach is designed for particular types of games, and won't work in others. For example, sending the property changes of each unit in an RTS game is simply not going to work. There are no silver bullets in game networking -- it needs to be designed on a per-game basis.


Why does it have to be a global object?

If you allow users to upload scripts then you basically need to be very careful with what you allow. If you allow arbitrary scripts then they will need to be run in a VM where you can limit their resource usage. You would probably be better off with a more restricted "scripting" system where you only have control over a very specific subset of the game behaviour (e.g. pre-define a set of triggers and behaviours, but allow the users to combine them in any way they like, but design the triggers so that nothing bad can happen).

| improve this answer | |
  • \$\begingroup\$ Thanks, now it is more clear to me that my questions are related to any game engine architecture, not just component-based, so I should study those issues separately, and if I get network/scripting implemented correctly, then component-based system will not introduce any new problems with network/scripting. \$\endgroup\$ – JustAMartin Aug 21 '11 at 14:30

Your Answer

