Multi-player Games - Would you like a talk on it?

Hi all,

After Last nights meet, I realised there is a fear of multiplayer . While I do not advocate multiplayer for a new game designer, I put together a outline for a talk on multiplayer and how to approach it, so as to allow people to better understand the scope of multiplayer, and plan the sturctures, technologies and generally how to approach a multiplayer game properly.

It explains the problems with Authoritative server architecture, posing a workable solution for this.

It also outlines the different network structures and explains a brief outline of the way data flows over the internet, detailing what approaches and technologies are suited to each of the structures as well as which games are best suited to those technologies, approaches and structures.

Would the community be interested in such a talk? I can give it at the next meet 9 March if there is an interest?


  • I'm currently trying to design and build a authoritative socket server specifically for a turn based multiplayer game. I'm looking at having the server scalable by running separate instances all tied by a central repository or master server.

    I would definitely like to hear your talk.
  • Great to hear :) Scale-ability is always a concern, and I will gladly talk through some of it with you :)

    I do have a few questions with regards to your architecture if you don't mind to help clarify what you plan to do.

    1) How many players per game instance are you expecting?
    2) how you plan to track the different unique sockets across the different servers?
    3) How are you allocating which Socket goes to which server?
    4) what do you mean by repository? Are you referring to a database repository or a identifying and distribution repository such as those used in a MapReduce Environment? (both can cause bottle necks in scaling if not planned correctly)
    5) what type of database are you wanting to use?
    6) Can i ask you to please clarify what you mean by "a authoritative socket server" by a simple process flow. this will help me understand your current and intended flow so we can build a good solution.

    Lastly when you say sockets, are you using Node and

  • I'll try answer your questions as best i can, here goes.

    1. For now just 2 per game, but later possibly up to 8.

    2. My thought is that each instance of a game server will track only its own list of connected sockets.

    3. Players joining a game will connect to the same instance of a game server (ip & port)

    4. I'm thinking of having a master server which handles the database repository, for authenticating users and also saving game states. So both players can disconnect from the game, but the game will still be active. A player will request details from the master server, which will supply the player's game with the ip:port of a running game server. When a second player joins, the master server will supply the same ip:port of the game server.

    5. mysql or mongo or both

    6. The game server must be authoritative in the sense that it will know all the game rules, and validate each of the players' moves, in order to prevent cheating.

    So basically there will be many instances of the game server. These will be quite thin. It will only validate the game rule set, and provide realtime communication between games. Any other info it needs, it will get from the master server.

    Then there will be one master server that contains all the player and game data. Each time a game server is instantiated, it will let the master server know about itself. Players will authenticate against the master server.

    I would like to build the game server in mono, and deploy on linux. But i will also have a look at node.

    I hope this explains it. I've never implemented a server solution before, so i'm possibly overcomplicating things, but i'm still early in the design phase, and open to any ideas.
  • @Ryan_Julyan Just wondering, what kind of experience do you have in multiplayer games?

    We're based in Cape Town, so it isn't that relevant. But programmers with an interest, and passion for, online multiplayer in video games seem to be in short supply. We've got online multiplayer features working in our current game ("Broforce"), but we definitely want online multiplayer in future games, and it is something of a programming bottleneck (implementing online multiplayer adds a ton of extra development and testing to any game, and I don't want to break the back of the one programmer here who currently handles the online multiplayer).
  • @petrc Thank you for this. I have read through your feedback.

    So if I am to understand your intention, your master server will do most of the work, while the slave servers will be purely for the communication of the players? Is that correct?

    I would like to get more details of this from a performance point of view there are a few choices. Depending on how much data you are intending on sending back and forth may be the limiting factor of what method you choose. Surprisingly due to the low number of players you may want to consider a peer-to-peer connection to take pressure off the server and it can be a lot cheaper for you (as you will not need as many servers). This would give you a outcome similar to what you are currently looking at achieving at less of a cost to you, as you would just be handing the DB and Signaling for the Peer-to-Peer connections and checks for cheating. I say this as if you are running those checks from a master server to a check to a database anyway, you would have the same pressure on your sever and would be your bottle neck.

    Alternatively as mentioned before, taking reference from how MapReduce works and thinking of your servers as clients of the master server, you can run a model that checks which server a user is connected to previously and reconnects them to that one, which has it's own Game Logic, while the master server worries about distribution of resources (sometimes location of user as well), instead of DB and Game Logic it just handles DB and log in. I would also keep an instance of the DB on the other 2 servers (you could limit it to the users on those servers if you really wanted to) just in case the master server goes down.

    Is this useful for you? and would you like to maybe talk more specifically about your game? Maybe we could move this conversation to talking specifically about your game and examples?

    @BlackShipsFilltheSky thanks for the interest, I would be interested in talking to you. We are currently making promotional games mostly for Vodacom (a real-time quiz game), as well as a Guitar hero clone for KFC (real-time signal processing to match the beat of the music and dynamically render the buttons, and real-time scoring for a competition). I am personally making a Mobile based, MOBA,, 3 vs 3, peer-to-peer, fantasy, anthropomorphic game (images and posts to come soon, only started the game yesterday). I am still fairly new to the gaming networking environment, however have been working with web server technologies as a primary focus which I have found has similar issues of connections and users, data as well as real-time feedback. I will look up "Broforce" and see what you guys are up to. What is it you are looking for so I can know if I can assist or maybe suggest someone else better suited for the job?
  • @Ryan_Julyan Awesome!

    Right now we're near the end of a +- 3 year project. We've got the skills to finish the project, but it's been a pretty tough gig for the one guy on the team who has taken all the responsibility for the network stuff. None of the other programmers quite understand what he does, and can't help him or work alongside him. So despite him working in a team of 7 other people, he's been kind of on his own a lot.

    That's not an ideal situation, it's not good to motivation AND it puts undesirable pressure on him, it's not a situation I want to repeat in future projects. Online multiplayer is probably going to be a part of whatever large project we tackle next, I don't want our online multiplayer to feel like a second class citizen in future projects (which it pretty much was when we launched on Early Access), so I'm keeping an eye out for developers who have a passion for it.

    I'd be very curious to see your progress in your MOBA. Good luck!

    Also I'd be interested to talk to anyone you know that has game development experience as well as an interest in networking games.
  • @Ryan_Julyan Yes, the way you explain it is what I want. One master server which only retrieves data from a DB for login & game states. The slave servers will retrieve the game state from the master, and perform all game rule validation itself. It will be up to the slave server to sync the game state with the master, either on each event, or as a list of events at certain intervals.

    I have also considered the game itself to host a local server, in order to enable Lan gaming. My only concern is that I will have less control over a local game server, in order to prevent hacking/cheating. Also I dont want to deal with issues such as NAT punch though, proxies, etc. But that is another issue.

    I'm building the game in unity so I decided to look at unity's network methods. I was totally amazed at how simple it is to implement. So now i'm thinking about building the slave servers straight in unity and use RPC between the slave servers and the game. The master server could just be a restfull web api.

    I have another programmer helping me, and we are both quite new to multiplayer networking, but its the most interesting part of the project for both of us. We now have a very crude prototype of just 2 players connecting locally and we have to start implementing the game rules. But i would like to first take a step back, and do a proper uml design and activity diagram on the entire structure.

    As for the game rules. The game will be simple (yeah right!) turn based movement of pieces on a board. Each player will have a number of pieces, and can move any number of pieces during his turn. A player will have a set number of moves, and each piece movement will subtract from the players available moves. The players turn will end if his available moves reach zero, or if he manually ends his turn.
  • I've been wondering how I can reply to this thread and be useful for a while now... I've built a number of networked games, including a stint of getting paid to do exactly that for a PSP game (that we tested on Xboxes because reasons). I was frustrated years ago when every single tutorial I read about networking always just focused on the mechanics of opening a connection and lobbing data at connected machines, I found very little information or conceptual guidelines for how you'd actually USE that connection to make your gameplay happen.

    So I made a bunch of games that didn't work. Then I made something that worked. Then I gave this talk a few times, and we had a networking DevLAN years ago with the framework that I produced to do that.

    Generally any networked game goes through three stages:
    1. You write the game to be playable on one computer, this is where you figure out what the gameplay is like, how it feels to play and what players are actually doing.
    2. You rewrite the game (yes, rewrite) so that it can connect to another machine on the same network - or even another instance of the game on the same machine. This is where your gameplay interfaces with networking.
    3. You rewrite the game's back end (yes, another rewrite) to handle whatever server/hosting/matchmaking you need to support your gameplay.

    Spending time worrying about server architecture and interconnection systems when you're still in stage 1 is a waste. You can't answer those questions now because you have no idea about your data-rate, timing windows, lag-tolerance, or anything really. You don't even know what your gameplay is like yet. Build the game first.

    Stage 2 is where you end up figuring out if your game is P2P or client-server. It's where you figure out if you only need LAN play or if you need a master server somewhere and WHAT that server even has to do. Chances are you can get away with a master server that just matches players together and handles NAT-punchthrough for user-hosted servers. Worrying about stuff like cheating and game-state validation at this stage isn't effective - that only matters if loads of people start playing your game AND are cheating.

    Stage 3 is where you support your game long-term. If your game doesn't have a huge player-base, then you never hit this stage and you don't have to worry about things like architecture scaling and load. Often random indie games shouldn't have complicated back end systems, because then they can live on if the dev stops paying for their hosting.

    I think that most of the issues that plague multiplayer games come from not being okay with rewriting things when you transition to the other stages... Those rewrites don't have to be 100% reboots, but they do tend to be further-reaching than everyone seems to suspect at first.

    You have to know your game before you can solve the problems of timing, identification and determinism, you have to solve those for your gameplay before you can talk about server backends.
  • edited
    thanks dislekcia. Very valuable advice.

    We got through stage 1 with a minimal viable product. Enough to give us a good idea what the game rules will be like. But without the multiplayer element, its not really playable at all. So we are currently in stage 2, but its my opinion that the sever architecture should be robust, and not just a proof of concept. I don't mind rewriting parts of code. But I don't want to redesign the server over and over again. My aim is to build a standalone server which can abstract the lobby and matchmaking away from the actual game and game rules validation, so that if the game project fails I can easily reuse this server on any other project.

    As for the game state validation, and cheating, I don't believe these topics should be overlooked in the design phase, as it is probably the most complex part. And leaving it out now, will only cause more problems later. Thats probably why so many alpha games these days are riddled with "hackers". Also if the server is designed with scalability in mind, then stage 3 will be an easy transition.
  • If it's "not really playable at all" without multiplayer, then can you really call what you have a minimum viable product?
  • @petrc: Wait, you're making a turn-based game and you can't play it on the same machine by having players take turns at the controls? Even a simultaneous-turn game, you can still have individual players take the controls in sequence and then play the turn resolution at the same time. Like, have players look away if you're actually playing seriously. But until you can actually play something, you're not going to know what you have to do with your networking.

    Did you go through the presentation I attached about network logic? How are you handling timing in your game? What are your identification and in-game routing needs? What information do you need to make the game deterministic?

    Unless you solve those three things (which totally don't require NAT-punchthrough or a master server anywhere) you're not going to be able to accurately write a server for your game. And if you solve your determinism stuff well, that automatically becomes state-validation later on - it's pretty trivial. Be really careful that you're not engaging with problems that you feel you can solve now instead of the hard issues that you actually need to solve first.

    P.S. Setting up your project in-case you fail is probably not a great idea. Yes, you want to learn from failures, but building systems to re-use them later (in settings that you don't understand, especially when you don't fully understand what you want those systems to do now) is a great way to ensure that you'll actually fail in the first place.
  • @dislekcia, I very much agree with the sentiment of what you have said, especially the phases. I think a lot of what you speak of is minimum viable product (Part 1 and 2) and then rebuilding properly. Not being precious about the first coding phases and focusing on getting a working, playable interaction should be first prize, and deciding from the experience how to approach will often give best results.

    I put this together really just to help people not over complicate their first look at networking and not to go into so much detail that they never get a game out, and also to allow people to think about which of the approaches will be good for the type of game they are making (once they have a single player interaction).

    I am actually really glad to hear from you @dislekcia as I respect your opinion and often reference you when talking to people about education and being able to answer Tests in school a second time etc, as well as the database infrastructure you did for one of your fathers clients in your early days. I think both of those have interesting relevance here as; the Tests in school is really about coming to the correct answer, which is the point! The same is true when coding games, you can plan as much as you like but you will learn the most by doing, and doing it again, and again, until you get it right.

    The other story about the database is about how you plan, and that planning is important, the way I remember this story is about defining generic enough rules that were extendable, and could be adapted to an environment that you did not know all the variables of (It sounded insane and I still wanna see that structure). That to me is about standards or level of coding and @petrc if you are writing code that has returning functions and takes parameters with defaults with try catch (or at least if, else) then your code can be reused anyway. So maybe focus on how you code if that is a concern, make things modular and then your work will not be in vain. This point of modularity leads me to the second point I got from @dislekcia and the database story, and that is how to prioritize work. Build a module that you will need for a project, the next project you can reuse that module, and only add as you need to - don't try able build all modules you will ever need from the start, as you will not know that up front. however, think about what functionality you can do without and will still make the game playable. Extra credits did an episode recently about this: give it a watch and maybe think about pushing that out. I think this leads to what @Elyaradine was talking about.

    Having said that. If your goal of this project is to learn networking, and not about making a game, and you are trying to make it more fun, then that is cool too, and you should maybe focus on that. Think about what you personally are trying to learn, or if you are trying to make a game that you want to put out. the sooner you can get something, Anything out there for people to test and throw stones at the better. Most people will not mind a few bugs here and there, and rather then trying to fix them all before production, make it easy for people to report them, hell you can even make a game from that :P

    I feel like I have somewhat deviated so I am going to end by saying, try use a service that already exists for your first networked game etc, don't build an engine or try reinvent networking on a large scale for your first game, use a service or a system (there are a lot out there) that can help you get where you want to, and you will learn a lot along the way. Once you have something, then try figure out how you could make it better, cheaper / faster etc.. as you will know exactly what you were aming for and what went wrong in the last project.

    PS. no one gets it right the first time, So don't let that perfectionism get in the way of putting something out there to test, and learn from the feedback :)
  • Okay, maybe I should have left out the "at all" part, jeez. "Not playable", meaning not completelly playable yet. But all the major parts (board generation and piece movement) is working fine. Enough to move on to the bigger tasks. In other words, pre-pre-alpha. :)

    @dislekcia, I have gone through your presentation, and it kind of makes sense. I take my hat off for you, for building those games from scratch, and figuring everything out yourself. You should definitely keep on working on multiplayer systems, and expanding you knowledge of it, and also sharing that knowledge. Thats why I think its a great idea of @Ryan_Julyan to have a talk on this, and perhaps you could also give a more updated presentation of your learnings?

    As for the points you bring across, its all valid. But since we started this project, we have delved deeper into unity's newtorking world and its beautifull. Things like timing and determinism is already handled by the networkview and its state syncronization. Also unity implements RPC, which can be buffered. So most of the "hard" parts are already taken care of.

    We have now built the slave server in unity. Its a standalone application, which handles player connections, and matchmaking. It can run on any platform we build it for. It can host on a local network, and we will still need to test it on a public server, but that should also work smoothly. It can handle both RPC commands, or state-syncronizatins. And its entirely agnostic from the game, so we'll be able to use it on any other projects in the future. We are considering releasing it as a unity asset package for other devs to use.

    We can now get back to working on the game, and as soon the basic player turns are working, I'll post a demo on it. We got a bit lost in the coding side of things, but if anyone is interested, I'll create some diagrams, to try explain our design better.
  • edited
    Okay, so heres an update. Unity's networking is not as 'beautiful' as it first seemed. It works great when the server hosts one game, and all connected clients are part of the same game. For our design we wanted the server to host many different games, and manage those games for the players who joined each games. But unity's current networking does not allow state synchronisation only between certain clients, and even the rpc calls only between specific clients is a pain. I have decided to give up on unity's network framework for now. Perhaps when the new UNET gets released i'll relook this project, or now that unity 5 is out, I can rebuild the server to work with plain sockets. But for now we'll focus more on the game to get it to a playable state, even if players have to play on the same machine.

    @Ryan_Julyan are you still planning on giving that talk?
  • @Ryan_Julyan Very interesting topic. Now that UNET is a bit more mature, have you made any further progress?

    I 'm also experimenting with a very basic minimal viable prototype where players can move about and throw objects/shoot bullets at each other to test the UNET multiplayer experience.

    I am interested in learning more about overcoming latency issues such as smooth lerping player rotation and movement, understanding how one would facilitate the game on a LAN or preferably the internet, lobbies and match making, port forwarding with or without tools like Hamachi, dedicated and/or master servers, using the Unity Online service etc.

    Ideally I would hope to achieve a solution which uses some form of a dedicated server (say hosted on Azure or some other server) with a global IP that players could seamlessly connect to without jumping through hoops and having to use port forwarding tools like Hamachi,/Evolve etc (which most of us did with games like Terraria a while ago).

    In my initial research regarding multiplayer, I have found these UNET related links to be useful so far.

    UNET Overview

    YouTube Tutorial: FPS Survival Zombie Multiplayer game - 22 Parts

    Gamasutra UNET tutorial

    UNET sample projects

    Master server example
  • I've been playing around with UNet recently. There's a lot to get my head around, though a lot of that feels like it comes from the way UNet is setup, rather than being inherently related to networking.

    Games with single avatars, like FPS's, seem like the easiest by far to network. I think I'm renewing my appreciation for what @Merrik did to get Broforce to work in multiplayer (as it has lots of NPC characters, environment destruct, and is pretty fast paced).

    I'm also curious to hear how @Ryan_Julyan has progressed on this. I'm personally less interested to hear about hosting, connectivity and server solutions for networking, that's just not a problem I find myself hitting my head against. Reducing the testing time cost of multiplayer really interests me, as well as how to run the logic so that everything stays in sync.
  • edited
    Sorry if I am rude, but I will like to mention books that cover multiplayer games

    Pro HTML5 Games by Aditya Ravi Shankar
    Chapter 11 and 12 uses websockets to add multiplayer support to the RTS game by using the HTML5 WebSocket API

    Multiplayer Game Development with HTML5 by Rodrigo Silveira
    The book also presents WebSocket API, covering important topics such as Reducing Network Latency, Security and Fair Play, WebRTC. The book uses snake and tic-tac-toe as casestudies.

    HTML5 Game Development by Example, 2nd Edition
    chapter 8 presents building a Multiplayer Draw-and-Guess Game with WebSockets. This tutorial is explained very well that my 15 year old brother was able to understand basic concepts.

    Pro Android Web Game Apps by Juriy Bura
    chapter 10, 11 and 12 are dedicated to networking. Most of the time is spend on theory then nicely followed by detailed example and its implimentation. Persistance is not covered in the book as the author assumes its very simple to implement on your own.

    Multiplayer game programming architecting networked by Sanjay Madhav and Josh Glazer
    I am currently reading this book via safarionline students account. I am on chapter 2 so I cant say much about the book. The reason I am reading the book is that most of the books code is using c++. So because I am using cocos2d-x as my primary engine, I don't want to mix both javascript and c++ in the same projects as it might be hard to structure the code.

Sign In or Register to comment.