• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0

Scaleable game server system

4 posts in this topic

Hi! I am currently designing multiplayer server system for our new game. I have some experience in building client-server systems but only for small amount of players. The game will be mobile game with multiplayer where players are playing against eachothers 1vs1 in real time. Direct connect from device to device is not possible because we want that players are able to play with random people around the world (for example clash of clans and hearthstone). The system should be scaleable so if player base grows up, we can simply launch more server nodes to handle them. I would appriacte if you guys could check this out and let me know if this can work. System will be run on AMS cloud computing servers.


Here are my plans so far:


Login server:

-Clients connect to this node when they launch the game

-Handles account login and redirect player to one of front-ends (balances the load between multiple front-ends)



-Handles all network traffic between clients

-There can be multiple front-end nodes to balance network load


Lobby server:

-When player want to start multiplayer game they are placed to queue

-When another player with same matchmaking is found lobby server redirects the players to one of game server


Message server:

-Handles in-game messages from player to player

-If the players are connected to different front-ends this server will deliver the message to the right one


Global event server:

-There will be global cooldowns in game that should be updated even when player is offline

-Handle cooldown timers and for example notify players when cooldown or upgrade is finished



-Database cluster where all information is stored


Game servers:

-There are multiple game servers all connected to the front-ends

-One game server runs a networking thread and 1 to n game threads (thread count depends how many CPU cores are available)

-One game thread can handle couple of game sessions


So do you guys have some tips to make this better or are there any great bottle necks that should be fixed? Thanks!




Share this post

Link to post
Share on other sites
Only things that stands out are the items that (I think) you've defined as single servers, e.g. login . I think you're under estimating the load they can come under. For instance, when the whole US eastern seaboard gets off work at 5pm and everybody starts logging in. You want to decentralize _everything_ that you can possibly can. Also allow spinning servers up and down dynamically, handle servers crashing as gracefully as you can, etc.

Also, what's your inter-server communication format? AMPQ server? Custom protocol? Are these designed to run in a data center together? A cloud server?

Share this post

Link to post
Share on other sites
So, in general, you have three kinds of services:

1) Batch services -- login, inventory, player stats, etc

2) Matchmaking services -- lobby, finding another player to play with, etc

3) Game services -- actual real-time gameplay data exchange while playing

All services in option 1) should probably be built as a horizontally scalable webapp. Use a round-robin load balancer in front of the web servers, and spin up as many web service instances as you need. Amazon has Elastic Load Balancer as a service. Or you could spin up a single instance or two of HAProxy or similar, and call that good (but beware the lack of redundancy!) Typically, all such services talk to the same database back-end, and that back end is horizontally sharded. Using in-RAM databases (like Redis,) and/or key/value stores (like Redis or Cassandra,) and/or separate caching (like memcache) may improve scalability. Just don't use MongoDB. Friends don't let friends use MongoDB :-)

Services in option 2 and 3 may need to be in the same instance, if you're going to be doing advanced things. Or you can simply have the matchmaker spin up a new process on some of a number of "game" servers, and identify those "game" servers with IP-address-plus-port, and give eash participating player an identification token and the ip+port information. Each of the two players then connect to the same ip-address-plus-port and provides their identifying token, and the game server can know that they go together. (In fact, you can have multiple player pairs in the same process -- you shouldn't need more than one process per core, and one port number per process.)

If you want large amounts of players (over tens of thousands) chatting/matchmaking at the same time, you will need a scalable solution for that. If all you're doing is chat and matchmaking for up to 10,000 players at the same time, a single-instance will be significantly simpler and cheaper; beware of single point of failure for this matchmaker, so you may want to have a second copy already running but idle, and be prepared to swap over to that if the first one dies.

And, if you're in Amazon, you may want to replicate all customer data between two different availability zones, and have all server roles running in two different availability zones, to avoid the problems that happen when one particular zone (or data center) dies, which seems to happen about once a year.

Finally, the matchmaker service, and the game services, can end up calling your web service back-end for things like verifying game tokens, granting players special things, etc.

If you build the system like this, you can start with very small amounts of server hardware (maybe even only in a single availability zone, if you're "small and indie.") Then you can add hardware instances as needed when and if you grow.

Share this post

Link to post
Share on other sites

Having 10,000 people chatting in the same room is probably not what you want, text would be scrolling past so fast people would have chance of reading, so you can easily divide that player base into instances.


I think you are over-designing your architecture a bit. You might want to consider login, front-ends and lobby servers in to one or multiple servers runnin on the same physical machine with public ID.


Under-estminating the stress of a login service is something I seen other developers do, but then again I think it is just a matter of choosing the right tool for the job. For example my NextGen game server www.next-gen.cc handles about 10,000 logins in a few seconds, authenticating with username and password. Hint, just store the players username and password hash in a way the dataset fits into memory, so you avoid reading from disk and pick a programming language with good concurrency.


If you are taking hplus0603 advice and creates web api I do recommend this software (open source):



I recently created a web api for authentication through my game servers myself, the code very short and hopefully scaleable. I have not yet tested the scability, but others probably have if you "google" it.


Share this post

Link to post
Share on other sites
Memcached and Redis both can do hundreds of thousands of key-value reads per second from a large number of querying hosts.

If you do proper horizontal scalability of your web API servers, then the CPU efficiency of those machines don't *really* matter, as you can "just" add more of them, although having to add fewer is always better. Whether you write them in PHP, or Node, or Erlang, or C++, or J2EE, or Ruby, only adds a constant multiplier, assuming the use of the back-end systems is the same in each of the solutions.

Getting to 10,000 logins in a second is not that hard with a web-type API for batch requests, using this method. I just wish game simulation and other such real-time services followed the scalability rules of web APIs :-)

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0