5

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:

GameObject 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

ioan
  • 751
  • 1
  • 9
  • 26
  • Are you sure you don't want the server to be the one running the game, and the client just a dumb renderer? That way you don't have to send all these attributes over the wire (and it helps to prevent cheating because the client can't be manipulated to report dishonest values). – Cornstalks Sep 01 '16 at 14:44
  • That's exactly how it works, but I still have to notify the client of what it is he has to render. – ioan Sep 01 '16 at 14:49
  • ChangePosition() is just an example where the client decides where he wants to go. It is just a target, the server can decide if it is valid or not, etc. I gave it purely as an example. – ioan Sep 01 '16 at 14:51

2 Answers2

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • 2
    To expand on method 2, you could store a global set of objects which are stale. Whenever a property changes, add a pointer to the changed to this set, and on the network tick, only run through the objects in this set, transmit their members which have changed, and in the end clear the set. This will save you having to iterate over all objects every network tick to check if they need to be updated. – Rotem Sep 01 '16 at 17:38
  • Hi, thank you for your suggestions. Do you reckon you could add up to your answer with some real life code or pseudo code? By marking the changed properties do you mean I would have a bunch of void* pointers to every (object->propertyName) ? – ioan Sep 01 '16 at 20:17
  • @ioanb7 I've edited my answer to clarify further and illustrate. But one important point: never `void*` ! You could have a family of functions declined by type like your `SendXXXOnWire()` for the different types you support (I showed this in an edit). Or better use template getters/setters to avoid code redundancy. Alternatively you could opt for `boost::variant` or a union. – Christophe Sep 01 '16 at 21:22
  • @Christophe Thank you a lot! That's very detailed now. I looked into the source code from the author and it looks very interesting and organised. Didn't know i can use c++ in unity. Your example works, but it makes the implementation large over dozens of variables and multiple inheritence levels. I am afraid that it is also not as error prone and easy to write game logic with physics- you'd just have another layer of problems. I am going to work out a solution between your code, his and the source code from Valve and come up with a solution. I am going to open source it afterwards. Thank you – ioan Sep 01 '16 at 21:40
0

Overall conclusion I arrived at: Having another call after I update the position, is not that bad. It is a line of code longer, but it is better for different motives:

  1. It is explicit. You know exactly what's happening.
  2. You don't slow down the code by making all kinds of hacks to get it working.
  3. You don't use extra memory.

Methods I've tried:

  1. Having maps for each type, as suggest by @Christophe. The major drawback of it was that it wasn't error prone. You could've had HP and Hp declared in the same map and it could've added another layer of problems and frustrations, such as declaring maps for each type and then preceding every variable with the mapname.
  2. Using something SIMILAR to valve's engine: It created a separate class for each networking variable you wanted. Then, it used a template to wrap up the basic types you declared (int, float, bool) and also extended operators for that template. It used way too much memory and extra calls for basic functionality.
  3. Using a data mapper that added pointers for each variable in the constructor, and then sent them with an offset. I left the project prematurely when I realised the code started to be confusing and hard to maintain.
  4. Using a struct that is sent every time something changes, manually. This is easily done by using protobuf. Extending structs is also easy.
  5. Every tick, generate a new struct with the data for the classes and send it. This keeps very important stuff always up to date, but eats a lot of bandwidth.
  6. Use reflection with help from boost. It wasn't a great solution.

After all, I went with using a mix of 4, and 5. And now I am implementing it in my game. One huge advantage of protobuf is the capability of generating structs from a .proto file, while also offering serialisation for the struct for you. It is blazingly fast.

For those special named variables that appear in subclasses, I have another struct made. Alternatively, with help from protobuf I could have an array of properties that are as simple as: ENUM_KEY_BYTE VALUE. Where ENUM_KEY_BYTE is just a byte that references a enum to properties such as IS_FLYING, IS_UP, IS_POISONED, and VALUE is a string.

The most important thing I've learned from this is to have as much serialization as possible. It is better to use more CPU on both ends than to have more Input&Output.

If anyone has any questions, comment and I will do my best helping you out.

ioanb7

ioan
  • 751
  • 1
  • 9
  • 26