0
\$\begingroup\$

I'm working on Unity and I use node for my serverside.

I'm starting a multiplayer project on mobile. I'm searching for a good structure for my game that how server controls the events. For example my players do some requests like upgrades and... simply my server receives those requests and after validation saves them in database and... but in some parts 2 player should start the game and get sync to play the game. in that part a copy of game for server should run to calculate ingames parts and respond to player requests like move inputs and...

The problem is should my server for every game for 2 players run a copy of game and send and receive data with socket from that copy to run the game or there is other ways to do that?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Conceptually, you need only one server. In practice, for scalability, you may want to split this "one server" in many server processes, possibly on different machines, to distribute load... but that need is far into the future and you should worry about it when you get there. Not now.

So, what you need is one server. That server, in the context of your question, will have two jobs:

  • to transmit updates to the game state to all connected clients
  • to replicate the current game state entirely to any newly-connecting clients

That means that as the server gets requests from clients and processes them, it updates the game state and tells any clients about those updates (if it matters to the client).

Similarly, when a new client connects, the server sends it information about whatever the current state of the game is, at least as far as what matters to the client. It's quite possible for one logical server to do and in fact it is somewhat easier to work with as that one server has all the state, makes all the decisions, and knows about all the clients. That means there is no server-to-server state replication to worry about, no additional layer of complexity introduced by run N copies of the game on the server for N clients, like you were suggesting in your question.

Just use one server, have it sends relevant updates to connected clients, and relevant complete state for new clients.

(I keep saying "relevant" and "what matters to the client" because you only want to tell the client about things it should know about; don't tell it about things that it can't yet see, for example, because that enables client-side "map hacks" and the like.)

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .