The final part of a six-part series adapted from my master’s thesis, “Creating a First-Person Action Game in Unreal Engine”. Previously: Part 5 — Creating a Fully Destructible Networked Environment. Full series and source on GitHub.

Introduction

The goal of this chapter is to design a next-generation networked game, with a design applicable for the estimated number of players (more on this later), and to implement the basic features of the game mode so it can be tested. As mentioned at the beginning of this paper, there are two dominant types of networked games: those based on matches, and those based on permanent worlds.

Personally, I think some of the most important networked games are based on permanent worlds — originally “San Andreas: Multiplayer” through its social simulation, “DayZ” through its apocalyptic simulation. Ultimately, I think games of this type hint at the “ideal” design. But games like this are extremely difficult to design and perfect — the time required for their sufficient development is simply too much for this paper. For example, Star Citizen, currently the most advanced game of this kind, has been in development since 2011 [117] [118].

Because of this, the game will be designed around matches. The main design inspiration is a modification for “Battlefield 2” called “Project Reality” — a tactical shooter I personally consider the pinnacle of match-based networked game design with a high player count. With our design, we’ll aim to fix its consistency problems and adapt it to a higher player count.

Designing game and match functionality

As mentioned in the first chapter, interaction between players is the biggest advantage of networked games — the highest quality type of interaction is teamwork, which is very close to the basic human need for association and survival.

Creativity is another important human need in game design. It’s provided by giving players tools with which they shape the course of the game to their liking — think of it as designing a sandbox, where we create an environment in which the player expresses creativity through the use of tools within the limitations of the world, and the goal of winning. This sandbox should be designed around the available number of players — as established in previous chapters, that’s currently 200, and up to an estimated 1000 depending on fidelity. This is one of our main hooks: a large player count.

We’ll also adhere to some of the principles that make up popular games [16] — clear conditions for victory, a limited duration, an escalation of the battle, and a system of progression. Essentially, a game where two teams try to dominate the same world against each other.

The victory condition

The victory condition must be simple and clear to all players. It’s based on a points system: each team gains influence points through controlling checkpoints in the world, and the first team to collect enough points wins. How players secure those checkpoints is up to them.

Checkpoints in the world are organised into a tree, beginning at one team’s base, spreading through the world, and ending at the other team’s base. If the connection between a base and a checkpoint is broken by the enemy taking a checkpoint between them, no points are collected for that team.

Teamwork through a chain of command

To improve association, interaction, organisation and the flow of the game, we introduce the concept of a chain of command.

At the top of the chain stands the commander, whose role is primarily to orchestrate the battle by giving orders.

Below the commander are squads, commanded by squad leaders, and below them are the players. The squad leader’s role is to carry out the commander’s orders by giving their own orders, while the player’s role is to carry out the squad leader’s orders.

One commander can effectively manage 10 squad leaders, and each squad leader can manage 10 players. It should be noted that if a larger number of players were achievable, more commanders per team should be allowed in a single game.

A commander can give orders to squads (and thus a squad leader to their squad), similar to those given to AI:

• Move to the marked position
• Stop
• Defend this position
• Attack this position
• Build
• Retreat
• Recruit (respawn dead squad members)

This could be further expanded by chaining commands — for example, setting one command, holding “Shift”, and setting the next, similar to “Company of Heroes 2”.

Due to the complexity of determining tactics and orders, a voice communication system is needed, at the local/spatial level, the squad level, and the commander level.

Furthermore, to help achieve strategic objectives, teams could have AI squads that the commander manages. It follows that a squad of players could also have some AI members, to carry out various commands. In addition to squad AI, we could use the AI takeover feature from Part 3 to get back into action immediately after dying, switch roles within a squad, or switch squads entirely.

This system, coupled with checkpoints, provides a focused game with a wide range of tactical capabilities for every player in the chain. Each player decides for themselves how to execute a given order, but they all ultimately share the same goal.

Motivation through a scoring system

To keep the average player motivated to execute commands, we use a command-execution scoring system with strategic, tactical, and operational points:

• By occupying checkpoints in the world, the commander gains strategic points.
• At the end of executing an individual commander’s order, the squad leader receives tactical points.
• At the end of executing an individual squad leader’s order, the player receives operational points.

These points can be spent on game tools — vehicles, weapons, squad types, roles/classes, and so on:

• The commander selects the tools their team wants to use from the overall pool, and puts them into a strategic pool; selecting tools costs strategic points.
• The squad leader selects the tools their squad wants to use from the strategic pool, into a tactical pool; costing tactical points.
• An individual player in a squad selects the tools they want to use personally from the tactical pool, costing operational points.
• Any individual player in the chain can also select upgrades for a tool, more on this later.

The tools in the system are divided into escalation phases:

• Reconnaissance phase — light transport vehicles, reconnaissance aircraft, infantry artillery.
• Mechanized phase — light armored vehicles, fighter jets, anti-tank artillery.
• Medium-heavy armor phase — armored vehicles, close air support, heavy artillery.
• Heavy armor phase — heavy armored vehicles, bombers, and the like.

This system ensures the battle escalates over time. The inspiration comes from “Company of Heroes 2” and its escalation system, plus “Crysis 1” and “Counter-Strike: Source” and their systems of buying weapons mid-game.

Furthermore, this system could also serve as a progression system: since we want to retain players, we periodically reward them with tool improvements, like better equipment. The total points earned by a player during a match are added to their progression points, which permanently unlock the ability to buy an upgrade; points earned during a match can also be spent on already-unlocked options. The inspiration for this system is “Call of Duty 4”, where progression first developed into a significant system.

This is our second hook: a teamwork-oriented game mode.

Logistics system

To sustain the course of the game and the front line of battle, a system is needed to respawn players who have died. This is done using forward operating bases, which players can build — using the buildable objects system from Part 5.

To maintain realism, constructing and using these would require logistical resources, created only at an individual team’s base. These are physical objects consumed by constructing individual facilities. For easier management and routing, it would be advantageous to fulfil logistics roles through AI. This would create interesting tactical situations, where overextended logistics routes could be attacked, cutting off supplies and respawns from the front and causing it to collapse — creating a need to protect the routes.

At the tactical level, squad leaders should be able to build rally points, where their squad’s players can respawn, to maintain the local front line.

Conclusion

We’ve established a good hook for players: a teamwork-oriented, massive player-count realistic shooter, with a fully destructible environment and a wealth of tactical tools at your disposal.

All of this has been shown to be possible in the previous chapters. Furthermore, we’ve presented solutions to the consistency problems tactical games usually face.

Implementation of game and match functionality

Due to the complexity of the described game and match functionality, only the basic features important for the flow of the game were implemented — victory conditions and checkpoints.

There are several basic classes that serve as the foundation for the game’s functionality. At the top is the world, which contains all the other game functionality. The project’s world is available at Content/TakeoverPrototype/Takeover_Medium. The world consists of:

• Facilities and terrain
• Game mode
• Multi-server configuration

Objects are classes like the AI spawner, vehicle driver, destructible objects and all other instances of similar classes. The terrain is an object representing the “ground” or “floor” of our world, combined with terrain deformation for a better experience.

The rules of the game consist of:

• A character managed by the client
• UI class
• Character manager
• Game state classes
• Player state classes
• Spectator classes
• Simulated character classes
• Simulated character control classes

The game mode class itself is at …/BP_TakeoverGameMode, while the game state class is at …/BP_TakeoverGameState.

Checkpoints

Checkpoints are a fundamental part of the game’s functionality — occupying them is effectively the victory condition. The current implementation is based on the control points that ship with the SpatialOS project, modified only to work with our implemented characters, since the defaults are otherwise satisfactory for this project’s needs.

They’re based on the states:

• Neutral, and neutralizing
• Occupied, and being occupied
• Reset, and waiting for reset

At the start of processing, a repeating function is assigned to check checkpoint occupancy.

When checking occupancy, the state of an individual checkpoint is set.

This logic depends on the number of players within the checkpoint and which team they belong to.

This is possible because of the team component every player has.

Victory conditions

Victory conditions are implemented through the game state class, which serves to transition between the game’s states:

• Pre Game
• In Game
• Post Game

So, at the start of the game, the match is initialized, all checkpoints are found and recorded in a variable, a repeating function is called to process their state, and finally a repeating function is called to update the score.

When updating points, the state of all checkpoints is checked, and added to the opposing team’s score.

When the maximum point count is reached, the game switches to the post-game state and ends.

Server testing

In order to test our game in a proper environment, we need to put it in the cloud. We use a free tier of the service, which offers up to 200 players on one server [62].

The process starts with server configuration — obtaining the project name from the Improbable console [119], and assigning names to the assembly and the deployment. It’s also possible to include simulated players, but we’re limited to only 10 of them.

Once we’ve uploaded the game to the server, we can launch it on a local computer through the aforementioned console.

This allows anyone to download the game, install it, and play it.

That wraps up the series. Thanks for following along through all six parts — from games as a medium all the way to a playable, 200-player match mode. The full project, source code, and documentation are on GitHub, including the original thesis draft and my YouTube channel for video walkthroughs.