Some practical issues with component-based game object systems

Question

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.

Answer 1

Is this a common weakness of such systems or I have wrong implementation ideas?

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?

... or it is a bad idea and I should pack more changes together?.

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.

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?

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).