2
\$\begingroup\$

I am working on a match-based (5v5) multiplayer steam game that is similar to TF2, LoL, Dota 2, etc.

I am planning a data-driven approach where character/abilities/items/etc are defined in data (JSON). This will allow for easy patching to constantly balance the game.

So I have something like the following. (obviously simplified)

{
    "Troll": {
        "name" : "Troll",
        "health" : "100",
        "abilities" : [
            {
                "name" : "ClubSwing",
                "damage" : "50"
            },
            {
                "name" : "FootSmash"
                "damage" : "100"
            }
        ]
    },
    "Orc": {
        "name" : "Orc",
        "health" : "50",
        "abilities" : [
            {
                "name" : "SwordSwing",
                "damage" : "10"
            },
            {
                "name" : "ArrowShoot",
                "damage" : "25"
            }
        ]
    }
}

I am wondering what the best practice way is for storing this data. I obviously can't store it client-side or the player will be able to cheat. Is it normally stored in the database? I haven't setup any backend for my game yet. Should I setup a nodejs server with a nosql database like mongodb to be the master of this data? And then build a REST API on top of that for reading this data?

I also need to write some things to a database. Such as the users rank, items, game stats, etc.

Would it be better to have two separate databases? One for reading gameplay data like I have above and another reading/writing user information (stats, rank, items, etc.)

Or would it be wiser to use a single database? Would you recommend nosql or sql based?

Note: The game engine I'm using is unreal engine 4. Currently I am using a listen server (peer-to-peer), but think it may be necessary to eventually use the dedicated server instead.

\$\endgroup\$
  • 1
    \$\begingroup\$ Using JSON for 'easy patching' is not a good reason to use JSON. Even if you 'can read' data easily, it may not be the appropriate tool. One MMO that I looked into their data setup used binary files organized like SQL table to store data on the client side, and an MSSQL table that had the same data on the server. The data on the client is used for 1) prediction during gameplay, 2) first pass at preventing cheating and 3) informing the player. Otherwise, if you want to reduce cheating, you'll have to do everything on the server. \$\endgroup\$ – Vaillancourt Apr 4 '16 at 21:12
  • \$\begingroup\$ Most people from what I could find are using xml/json for data-driven coding like this. It's just the data format. I was really more focused on the overall architecture. \$\endgroup\$ – erebel55 Apr 4 '16 at 21:25
  • 1
    \$\begingroup\$ I feel your whole question is really too broad, unfortunately. \$\endgroup\$ – Vaillancourt Apr 4 '16 at 21:26
  • 1
    \$\begingroup\$ Not to suggest premature optimization but storing your game's data is going to turn into a slow nightmare if you build anything of significant mass, even if this is only for the client game data, the human readable solution is a nightmare to parse for the machine in comparison to building your own binary format or using something similar to a standard like Alexandre suggested. Regarding using a REST API in node.js for your backend, it's not worth the headache, it's barely fast enough to run the backend for apps on your phone and it's trivially easy to hack all your game data to cheat. \$\endgroup\$ – user5665 Apr 5 '16 at 9:06
  • 1
    \$\begingroup\$ The source code for games/engines like Quake, HL2, Penumbra Overture, and Unreal Engine 3 are all freely publicly available and have been extremely helpful to me personally on how to handle the storage and evolution of client side and server side game data, you don't need to make anything remotely as complex as their solutions, but it's important to build a game with technology that isn't going to make your life a living hell a couple months from now due if your game blows up and you have to deal with the cost of running inefficient services and listening to complaints from your players. \$\endgroup\$ – user5665 Apr 5 '16 at 12:39
4
\$\begingroup\$

You probably do want to communicate to this information to the client so that they are able to view it. You can treat the client as a dummy terminal though with sparkly representation and have a "neutral" server as the authority.

Lets consider League of Legends in this context.

At the beginning of the game, each client connects to Riots servers. Every time a player moves or attacks, the client plays the animation and sends the action to the server. The server calculates the outcome and sends it to the relevant clients. If you broadcast all information to all clients then you are leaking in the sense that a client can know what is occurring in the fog of war and they should not be able to. The information transmitted affects the game state.

It is worth doing some calculations client-side though such as collision detection to prevent walking through walls or minions. This offloads some non-critical calculations and decreases latency. This does mean a client could allow itself to walk through walls, however because movement affects game state the server would still be aware of it so you could detect this kind of "attack".

In summary, the server is the final authority of the game state so it would be best to store data on the server. NoSQL vs a relational database is up to you, but odds are you can use a relational database will preform satisfactorily.

Tou most likely want to implement a binary network protocol as opposed to a textual one. This allows you to decrease the amount of data sent to convey the same information. Consider the following example, player A attacks player B. Please note this is contrived and does not include any method of ensuring message integrity.

Text Protocol Message [size=10B]: A attack B

Binary Protocol Message [size=3B]: 0x1 0x1 0x2 -

This link discusses the LoL protocol a bit, https://nelsonslog.wordpress.com/2014/08/07/league-of-legends-game-protocol/ .

\$\endgroup\$
2
\$\begingroup\$

I wouldn't store them on clients, or even ship that information with game. If security is your main concern, fetch all informations required at the beginning of the game (from a database), store them temporarily, and delete them after the game session ends.

You can also cross-check local data with database during gameplay if you want an extra layer of security.

\$\endgroup\$
  • \$\begingroup\$ Fetch the data from where? A file on the server? Or from the database? I'm wondering what the best tech is to use to promote scalability. \$\endgroup\$ – erebel55 Apr 5 '16 at 13:40
  • 2
    \$\begingroup\$ @erebel55 For storing "shared data" always prefer databases. \$\endgroup\$ – S. Tarık Çetin Apr 5 '16 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.