# How to set up a client-server architecture for a browser based game [closed]

I'm really curious about how to set up a game so like Hayday or Clash Of Clans, especially with regards towards the server-client architecture. How does one set up such an artitecture? What are the techinical details?

Thanks a lot!

## closed as too broad by Sean Middleditch, Anko, MichaelHouse♦Aug 9 '14 at 13:57

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• What do you mean by "what's kind of server game"? are you looking what type of server they are using? Are you looking what their genre is? Are you trying to find out what makes these games good? Are you trying to find what game you could make that's like them? – Thijser Aug 9 '14 at 7:16
• Sorry about this confusing. I mean, I don't understand server architecture to make these games. Could you explain this? Thanks.! – huuloc Aug 9 '14 at 8:07
• This is an extremely broad question and hard to answer, as we don't know what Supercell use on their servers; their games are closed source. Is there something more specific and answerable that you're stuck with? – Anko Aug 9 '14 at 8:33
• It's very hard to describe with my knowledge. Example. I login to my game -> I build a house -> every hour It make 300$-> I logout -> after a hour -> I login -> I gain 300$. My question is: How to make server do this job. I'm really sorry about that if it still unclear. – huuloc Aug 9 '14 at 8:50
• Could you update your question rather then comment it? When asking a question it's important to first of all think of what you wat to learn from it and then ask it. – Thijser Aug 9 '14 at 9:07

The question is too broad, but i will start anyway,and if you are looking for specific tutorials, you need google, i know about architecture, and what all factors you might need to consider while writing down the tiptops of your game base interaction.

The main question is whether your game is going to be in real time, turn based, or long-delay based (e.g., email chess). Another question is whether or not you are going to be freezing the state for subsequent reloads.

I would highly recommend figuring out in advance whether or not all players in the same game are going to be hosted on the same server (e.g., 1000 of 5 player matches compared to 5 matches of 1000 players each). If possible, go with the first and stick everyone who is in the same game under the same server. You will have a hard enough time synchronizing multiple clients to one server, rather than having multiple servers against which players are synchronized. Otherwise, the definition of consistency is problematic.

If possible, have each client communicate with the server and then the server distributing updates to the clients. This way you have one "official state", and can do a variety of conflict resolutions, phantoms, etc. Peer to peer gives better performance in faster games (e.g., FPSs) but introduces tons of problems.

Now for implementation of this architecture, i suggest you use linux network programming, cause windows is too vague, and errors might bundle up in future:

1. Create 2 instances of server as back design, you can have more , but main design should consist of one master server, and other slave sever, or master server can fork new servers with { fork();

if(pid!=0){//child server interaction};

else(//optional block for authentication of players, you need extra child server for each user)

//parent process}

1. The less data you transfer the smaller buffers you need on server -> more clients on one machine and also a bit faster responses
2. Three Rings server ARCH For server and client side implementation , you might check out .
3. server setup details , you might require need

~Client specifics:

• Initiates requests
• Waits for and receives replies
• Typically interacts directly with end-users using a graphical user interface
• Usually connects to a small number of servers at one time

~server specifics

• Waits for requests from clients
• Upon receipt of requests, processes them and then serves replies
• Typically does not interact directly with end-users
• Usually accepts connections from a large number of clients