0

I'm trying to find a way to design a game server architecture for a real time mobile game. The design should be cost effective but still to some extend scaleable (later on at least with minimal effort).

Mobile client flow:

Connects to a distributor server which was given by DNS LB and gets grouped with x players. If y players are reached, the distributor server needs to contact a control server, which starts or uses a already running game server. The control server sends back the ip and port to the distributor server which then sends it to the grouped players. The players then connect to the given game server. After the game the players will be send together to a new or same distributor server.

I wonder how the real server (VMs) for the game servers can be managed in a dynamic matter. I have looked at AWS EC2 instances, but if we have 500 players with 6 players per group that play 6 hours per day, we would need ~84 EC2 t3.small (2 vCPU, 2GiB RAM) instances running. This will cost ~1,160.00 USD monthly. With this price it would be favorable to have real VMs and not dynamic cloud instances I guess?

I also looked at AWS ECS which might be a good catch, but I am uncertain how the game servers in the containers could be managed for auto scaling.

Link to image is here. Sorry, images can only be posted with at least 10 rep.

Explanation of the components

Distributor:

Mobile clients will connect to these to get grouped with other players. It's like a lobby where players will sit until X players are reached or eg. a countdown ran out.

Control Server:

Need to take care of started server (VMs) and handle game server start requests from the distributors.

Game Server:

Is an authoritive like server client with physics etc. One game server (software) for X players in a group. Players will connect to these from the distributor after the lobby "phase".

Question:

How can this be dynamic scaleable/cost effective and is this a useable architecture? I see one problem with the control server because it must take care of N game server vms and N distributors. But if we scale the control server, then every control server needs to know the same as every other.

(If anything is missing or can be improved, please let me know. English is not my native language so it's a bit challenging to express my goal in such a complicated topic like this)

  • 1
    A VM sounds like a good option for you. It's certainly scalable and can offer good redundancy if needed, both physical and logical. – Overmind Jun 24 '19 at 11:18
  • With VM you mean something like AWS EC2 or ECS? – Left Over Jun 24 '19 at 17:03
  • Something ESXi-based. – Overmind Jun 25 '19 at 5:24
  • So like proxmox on a root server for the beginning? – Left Over Jun 25 '19 at 16:55
0

This can be usable architecture. Pay attention on data storage. Where is data stored? If in SQL DB, how will you scale that?

To scale game:

  1. Use multiple software components, players partitioned into nodes (you have that)
  2. Make sure that data storage is not single point bottleneck. Eg. single SQL DB. Game servers should have dedicated storage back end.
  3. Make Control server redundant. Two instances behind LB, some form of data replication between them.

If Control server only does command & control it shouldn't be bottleneck.

OS part, VM instances:

  • AWS can be pricey if servers actually do something
  • 2+ dedicated servers with Proxmox or Docker, probably cheaper than AWS in mid/long run
  • or 2+ dedicated servers, just start processes on different ports, automate later

As long as every component can scale independently from others you are ok.

First get user base. By then you'll have better idea where are pressure points and what needs to be optimized.

| improve this answer | |
  • Thanks for your answer. The data storage will probably be one of the AWS (or other cloud provider) databases, because I think scaling databases alone and correctly can be very hard. But I will have to compare prices etc. between the providers and choose the best from it. Do you mean "controller" with "control server"? If so, why would you make them redundant? – Left Over Jul 7 '19 at 12:11
  • Controller=control server. Redundancy to lower downtime in case of bug or server failure, nondisruptive ugrades. It depends how much damage will downtime make: lost users, lost income. At certain point redundancy is must, you can start without it. Even when you have backup it takes time to recover and time is money. – dario Jul 7 '19 at 14:42
  • Hm yes, but a contoller is on every VM / bare metal server. Does it really makes sense to have two on one maschine? Theoretically they should not fail. – Left Over Jul 10 '19 at 20:41

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.