Network Game Communication
Many different network games share one requirement: an action taken by one player must be communicated over the network to the other players.
Different Games, One Shared Problem
Picture a collection of games that all run over a network: card games, racing games, strategy games, and others. They look nothing alike on screen, yet each one has to solve the same underlying problem. When a player does something, the other players in the same game need to find out about it. An action taken on one computer has to travel across the network and reach the computers of the other players.
What do you think happens?
A racing game and a chess game look completely different. Do they still share some networking work?
Reveal answer
Yes, because in both games one player's action must reach the other players over the network.
The source points out that the game rules, graphics, and scoring may differ, but the act of passing a player's action to everyone else is the same job in each game.
This section asks a practical design question. If the capability of sending actions over the network is common to so many games, should every game build it from scratch? The rest of this article follows one action step by step, then looks at why the shared work belongs in one reusable place, and finally at how a package makes that place easy to include in many projects.
Tracing One Player's Action Across the Network
Follow one action through the system. The source describes this as an illustration of the general pattern rather than a detailed account of any specific class, so the steps below name only the roles involved. Suppose Player A does something in a game.
- 1Step 1: The game recognizes that the action happened on Player A's computer.
- 2Step 2: The action is handed to the common core, which is responsible for communicating actions over the network.
- 3Step 3: The action travels over the network and reaches Player B, who can then respond to it inside their own copy of the game.
Notice the middle step. The game recognizes the action on its own, but the hand-off to the common core and the trip over the network are the same job no matter which game produced the action. That repeated part is exactly what the common core is designed to handle once for everyone.
What Stays the Same and What Differs
To find the reusable part, start by looking at what the networked games have in common and ignore what makes them different. From the network's point of view, every one of these games has at least one shared requirement: there must be some way for actions taken by one player to be communicated over the network to the other players.
The game rules, the graphics, and the scoring may differ from one game to another. The act of passing a player's action to everyone else is the same job each time. This is the commonality that a single reusable framework can handle.
Why the Shared Part Lives in One Common Core
Because the capability is shared by many games, it makes good programming sense to make it available in a reusable common core that many different games can use. Instead of each game carrying its own copy of the network communication logic, the common core is written once and then used by every game that needs it.
The idea is the same as any other reusable building block: effort spent on the shared part pays off in every project that uses it.
Deciding Where Shared Code Belongs
A studio is building a card game and a racing game. Both need to send a player's action to the other players over the network. Should each game write its own network communication code?
- 1Identify the shared requirement
Both games must communicate one player's action to the other players over the network. This job is the same in each game.
- 2Identify what differs
The card rules and the racing rules are different, and so are the screens. Those differences belong to each game, not to the communication job.
- 3Choose a home for the shared part
Since the communication job is shared, it is placed in one reusable common core that both games use, rather than being rewritten for each game.
Each game keeps its own rules and graphics, and both use the same common core for sending actions over the network.
Packages as Groups of Related Classes
In programming, a package is a way to divide code into groups of related classes. Grouping makes code easier to manage and easier to reuse, because a set of closely related classes can be found, understood, and used together.
Packages are used in all but the simplest projects. Before deciding where the common core should live, it helps to understand the container that holds it. The shared communication classes are kept together in one place, so the code that handles sending actions does not get scattered across the project.
Including One Package in Several Projects
A reusable framework is meant to be used in a variety of projects, and a package is a unit that can be included as a whole. The source makes this point directly: it makes particularly good sense to define a reusable framework in a package that can be included as a unit in a variety of projects. That is why the two ideas fit together.
The diagram shows the benefit. A project that needs the shared communication classes includes the package, rather than copying individual classes around. The same package can serve several projects because it is one unit that can be included whole.
Tracing the Same Step in Two Games
One Action, Two Different Games
Player A in a strategy game moves a piece, and Player A in a racing game changes lanes. Both actions must reach the other players. Which step is the same in both cases?
- 1Game recognizes the action
The strategy game recognizes the piece move; the racing game recognizes the lane change. This step differs, because each game has its own rules.
- 2Action handed to the common core
In both games, the action is handed to the common core that communicates actions over the network. This step is identical.
- 3Action travels and is received
In both games, the action travels over the network and reaches Player B, who responds inside their own copy of the game.
The only step that is identical in both games is the hand-off to the common core and the network delivery, which is why one shared core can handle it for everyone.
Mistakes Beginners Make With Shared Code
Common mistake Assuming games that look different need completely different networking code
What it looks likeBelieving a racing game and a chess game must each build their own way to send actions to other players.
Why it failsThe source states that many different network games share the requirement that one player's action is communicated over the network to the other players, even when rules, graphics, and scoring differ.
Do this insteadCompare the games by the job they must do over the network, and separate that shared job from the parts that differ.
Common mistake Copying the communication logic into every game
Why it failsThe source explains that instead of each game carrying its own copy, the common core is written once and used by every game that needs it.
Do this insteadPlace the shared communication classes in one reusable common core and let each game use it.
Common mistake Thinking a package is just a folder with no purpose
Why it failsA package groups related classes so that code is easier to manage and reuse, and it is what allows a reusable framework to be included as a unit.
Do this insteadUse a package to group the closely related shared classes together, so a project can include them as one unit.
Practice: Finding the Shared Job
Consider three networked games: a card game, a racing game, and a shooter. For each game, list one thing that differs and one thing that is the same from the network's point of view. Then explain why the shared thing belongs in a common core and why the differing things stay inside each game.
Hints
- Think about what the source calls the shared requirement: passing one player's action to the other players.
- Rules, graphics, and scoring are the kinds of things the source says may differ between games.
Key Takeaways
- Many different network games share one requirement: an action taken by one player must be communicated over the network to the other players.
- The game rules, graphics, and scoring may differ between games, but the job of passing a player's action to the others is the same each time.
- That shared capability is best placed in a reusable common core that many games can use, rather than rewritten for each game.
- A package groups related classes so code is easier to manage and reuse, and a reusable framework defined in a package can be included as a unit in several projects.