C++ member variable change listeners (100+ classes)

Question

I am trying to make an architecture for a MMO game and I can't figure out how I can store as many variables as I need in GameObjects without having a lot of calls to send them on a wire at the same time I update them.

What I have now is:

Game::ChangePosition(Vector3 newPos) {
    gameobject.ChangePosition(newPos);
    SendOnWireNEWPOSITION(gameobject.id, newPos);
}

It makes the code rubbish, hard to maintain, understand, extend. So think of a Champion example:

I would have to make a lot of functions for each variable. And this is just the generalisation for this Champion, I might have have 1-2 other member variable for each Champion type/"class".

It would be perfect if I would be able to have OnPropertyChange from .NET or something similar. The architecture I am trying to guess would work nicely is if I had something similar to:

For HP: when I update it, automatically call SendFloatOnWire("HP", hp);

For Position: when I update it, automatically call SendVector3OnWire("Position", Position)

For Name: when I update it, automatically call SendSOnWire("Name", Name);

What are exactly SendFloatOnWire, SendVector3OnWire, SendSOnWire ? Functions that serialize those types in a char buffer.

OR METHOD 2 (Preffered), but might be expensive

Update Hp, Position normally and then every Network Thread tick scan all GameObject instances on the server for the changed variables and send those.

How would that be implemented on a high scale game server and what are my options? Any useful book for such cases?

Would macros turn out to be useful? I think I was explosed to some source code of something similar and I think it used macros.

Thank you in advance.

EDIT: I think I've found a solution, but I don't know how robust it actually is. I am going to have a go at it and see where I stand afterwards. https://developer.valvesoftware.com/wiki/Networking_Entities

Answer 1

On method 1:

Such an approach could be relatively "easy" to implement using a maps, that are accessed via getters/setters. The general idea would be something like:

class GameCharacter {
    map<string, int> myints; 
    // same for doubles, floats, strings
public: 
    GameCharacter() {
        myints["HP"]=100; 
        myints["FP"]=50;  
    }
    int getInt(string fld) { return myints[fld]; }; 
    void setInt(string fld, int val) { myints[fld]=val; sendIntOnWire(fld,val); }
};

Online demo

If you prefer to keep the properties in your class, you'd go for a map to pointers or member pointers instead of values. At construction you'd then initialize the map with the relevant pointers. If you decide to change the member variable you should however always go via the setter.

You could even go further and abstract your Champion by making it just a collection of properties and behaviors, that would be accessed via the map. This component architecture is exposed by Mike McShaffry in Game Coding Complete (a must read book for any game developer). There's a community site for the book with some source code to download. You may have a look at the actor.h and actor.cpp file. Nevertheless, I really recommend to read the full explanations in the book.

The advantage of componentization is that you could embed your network forwarding logic in the base class of all properties: this could simplify your code by an order of magnitude.

On method 2:

I think the base idea is perfectly suitable, except that a complete analysis (or worse, transmission) of all objects would be an overkill.

A nice alternative would be have a marker that is set when a change is done and is reset when the change is transmitted. If you transmit marked objects (and perhaps only marked properties of those), you would minimize workload of your synchronization thread, and reduce network overhead by pooling transmission of several changes affecting the same object.