A General Solution to Multiplayer Online Non-streaming Games

Now we are at the 1st stop from the roadmap. I’ll talk about the architecture and general construct of this solution.

Architecture

One diagram should be enough.

That is something you’d expect to see for multiplayer games, except it is not “server” but “system”. And that’s all the difference.
A system is a logic module that pushes the game forward in a step by step manner. Here “step” is an abstraction. It could be a phase in flowchart, a triggered event or certain time frame.
A client is a process that displays the game and runs sessions, which will be explained in a minute.

If you put the system on a remote server and each client is a user device (smartphone, desktop …), you get the commonly used construct.
But things can be different under this architecture. For example like this.

This is a two-player rock-scissor-paper game that comes from Wold_Gate beginner tutorials.
Client1 and client2 are both running on your local device, and system is embedded into client1.
It can be a perfect testing environment. You only need one machine to do multiplayer testing.

What is Session

Session an environment that helps players reach a decision, and send it back to system. One important observation is that making a decision doesn’t change the scene. What do I mean by that? Let’s take chess as an example.
Suppose you are playing chess with your friend. You play as white and it’s your move. You think for some time and got the brilliant knight D5 move. Then you pick up the piece and move there. That’s the common way.

But the general solution doesn’t behave like this. There’s a game master sitting beside you. After you got the move, you just declare knight D5. It’s the game master’s job to move the piece to D5.
You and your friend are the client. The game master is the system. When you are thinking about which move to make, you are doing a session.

Putting it Together

Let’s model chess under this architecture and see how things work in action.
We can use a flowchart to model the system. For example you can draw something like this in World_Creator, the IDE for World_Gate.

Straightforward.
When the game runs, the first step is “Start”. We setup the board and set white as current player.
Then we move to next step. During the “CurrentPlayerPlay” step, system notifies client1 to start a session, and waits for the feedback.
Client1 comes up with a move, and returns the decision, say “D2 D4” as string.
System got the feedback, and move pawn from D2 to D4. This step ends and moves to next…

Benefit

The separation of making a decision and results due to that decision is very important. (Replace decision with user input if that makes sense)
Although there’s no direct benefit from this, all other following benefits are based on this architecture. Just name a few.

  • Makes synchronization a lot easier
  • Dynamically switch between player and AI.
  • Allows asynchronous operations
  • Robust to network exception

I won’t bother explain here. As you follow this series you’ll get the idea.