6. Designing a game mode for interaction
The goal of this chapter is to primarily design a next-generation networked game, with a design applicable for the estimated number of players (more on this later), furthermore we aim to implement the basic features of the game mode so that it can be tested. As we 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: Multi Player Role Playing” through its social simulation, “DayZ” through its apocalyptic simulation. Ultimately, I think that games of this type hide 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 the game 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 based on matches. The main design inspiration is a modification for "Battlefield 2", called "Project Reality", a tactical shooter, which I personally consider the pinnacle of networked game design based on matches with a high number of players. With out design we will aim to fix its consistency problems, and adapt it to a higher player count.
As we mentioned in the first chapter, interaction between players is the biggest advantage of networked games, the highest quality type of interaction is teamwork, it is very close to the basic human need for association and survival.
Creativity is another human need important in game design. It is provided through giving tools to the players, with which they shape the course of the game to their liking. We can think of this as designing a sandbox, so we create an environment in which the player expresses creativity through the use of tools with the limitations of the world, and the goal of winning. This sandbox should be designed around the available number of players, as we established in previous chapters, that is currently 200, and up to an estimated 1000 depending on the fidelity. This is one of our main hooks, so a large player count.
We will also adhere to some of the principles that make up popular games [16], so we want clear conditions for victory, with a limited duration, with an escalation of the battle and a system of progression. It is basically a game where two teams try to dominate the same world against each other.
The condition of victory must be simple and clear to all players. It is based on a system of points, each team through the control of points in the world gets influence points, the first team that collects enough such points wins. The way players will secure those checkpoints is up to them.
Points in the world are organized into a tree, which begins at the base of one team, spreads through the world, and ends at the base of another team. If the connection between the base and the point is broken by taking some point between them, then no points are collected for that team.
To improve the association, interaction, and organization and flow of the game, we will introduce the concept of a chain of command.
At the top of the chain stands the commander, his role is primarily the orchestration of the battle, through giving orders.
Below the commander are squads, commanded by the squad leader, while below him are the players. The role of the squad leader is to implement the commander's orders through giving his orders. While the role of the player is to carry out the orders of the squad leader.
One commander can effectively manage 10 squad leaders, and thus one squad leader can manage 10 players. It should be noted that if we could achieve a larger number of players, more commanders per team should be allowed in one game.
Figure 115 Concept for squad selection menu, own creation (RedeployMenue)
A commander may give orders to squads (and thus a squad leader to his squad), similar to that of 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 by setting one command, and pressing the "Shift" key and setting the next, similar to "Company of Heroes 2".
Due to the complexity of determining tactics and orders, a system for voice communication is needed, at the local - spatial level, at the level of squads, and at the level of commanders.
Furthermore, to facilitate the achievement of strategic objectives, they could have artificial intelligence squads, which the commander can manage. It follows that a squad of players could also have some members who are AI, to carry out various commands. In addition to AI, we could take advantage of the AI takeover feature to get back into action immediately if we die, switch roles in the squad, or switch squads altogether.
Figure 116 Concept for command menu, own creation (FullView - Commander)
This system, coupled with checkpoints, provides a concentrated game, with a wide range of tactical capabilities for all players in the chain. So each player decides for himself how to execute a given command, but they all ultimately have the same goal.
To ensure that the average player is motivated to execute commands, we will use a command execution scoring system, called strategic, tactical, and operational points:
- By occupying points in the world, the commander gains strategic points.
- At the end of the execution of an individual commander's order, the squad leader receives tactical points.
- At the end of the execution of an individual order of the squad leader, the player receives operational points.
These points can be used for game tools, they can be vehicles, weapons, types of squads, roles/classes and the like, so:
- The commander selects the tools that his team wants to use from the overall pool, and puts them in his strategic pool, tool selection costs strategic points.
- The squad leader selects the tools he wants his squad to use from the strategic pool, and puts them in his tactical pool, the choice of tools costs tactical points.
- An individual player in a squad selects the tools he wants to use personally from the tactical pool, and this costs him operational points.
- Any individual player in the chain can also select upgrades to a tool, more on this later.
The tools in the system are divided into stages of escalation:
- 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.
Figure 117 Concept for escalation system menu, self-made
This system ensures the escalation of the battle over time. The inspiration for this system is the game "Company of Heroes 2" with its escalation system, and the game "Crysis 1" and "Counter Strike: Source" with its system of buying weapons during the game.
Furthermore, this system could also be used for the purpose of a progression system, namely because we want to keep our players, we periodically reward them with improvements for their tools, for example better equipment and the like. Therefore, the total number of points earned by a player during one match is added to the progression points, and they can permanently unlock the possibility of buying an upgrade. And during the match, the points earned can be spent on unlocked options. The inspiration for this system is the game "Call Of Duty 4", where the progression first developed into a significant system.
This is our second hook, so a teamwork oriented game mode.
To ensure the course of the game, and the front line of battle, a system is needed to respawn the players who have died. This will be accomplished using forward operating bases, which the player can build. This is achieved by previously implemented buildable objects that can be built.
In order to maintain realism, their construction and use would require logistical resources, which are created only in the base of an individual team. These are physical objects that are consumed by the construction of individual objects. For easier management and ordering, it would be advantageous to fulfill logistical roles through AI. This would lead to interesting tactical situations where the logistics routes could be attacked if over extended, cutting off supplies and respawns from the front, and collapsing it, thus creating the need for the protection of the routes.
At the tactical level, squad leaders should be allowed to build rally points, where the squads players can be respawned, to maintain the front line of battle locally.
Figure 118 Commander's view, self-made - CommandingView-Commander
We have established a good hook for players - imagine playing a teamwork oriented massive player count realistic shooter, with a fully destructible environment and a plethora of tactical tools at your disposal.
All of which we have proven to be possible in the previous chapters. Furthermore we have presented solutions to the consistency problems tactical games usually face.
Due to the complexity of the described functionalities of the game and the match, only the basic features important for the course of the game will be implemented, these are the conditions of victory and checkpoints.
There are several basic classes that serve as a basis for the functionality of the game. At the top is the world, it contains all the other functionalities of the game. The world of this project is available on the "Content / TakeoverPrototype / Takeover_Medium" path. The world consists of:
- Facilities and terrain
- Game Mode
- Multi-server configurations
Objects are classes like AI creator, vehicle driver, destructible objects and all other instances of similar classes. The terrain is an object that represents the "earth" or "floor" of our world, combined with the deformation of the terrain for a better experience.
The rules of the game consist of: A character managed by the client
- UI class
- Character manager
- Game status classes
- Player status classes
- Spectator classes
- Simulated character classes
- Simulated character control classes
The game rule class itself is on the "… / BP_TakeoverGameMode" path, while the game state class is on the "… / BP_TakeoverGameState" path.
Figure 119 World settings
Checkpoints are a fundamental part of the game's functionality. Their occupation is actually a condition of victory. The current implementation is based on the control points with which the Spatial OS project comes, and only modified to work with the implemented characters, because for the needs of this project these control points are satisfactory.
They are based on the conditions:
- Neutral and neutralizes
- Busy and busy
- Reset and wait for a reset
At the beginning of their processing, a repeating function is assigned to check the occupancy of points.
Figure 120 Checking the control
When checking occupancy, the state of an individual point is actually set.
Figure 121 Setting the state of points
This logic depends on the number of players within the checkpoint and which team they belong to.
Figure 122 Logic of occupying a checkpoint
This is possible because of the team component that each player owns.
Figure 123 Team component on the figure
Winning conditions are implemented through the game state class. It actually serves to change them, so the states of the game are:
- Pre Game
- In Game Status
- Post Game
So, at the beginning of the game, the match is initialized, all checkpoints are found, and they are recorded in a variable, and a repeating function is called for their processing (status registration), and finally a repeating function is called to update the scoring.
Figure 124 Initialization of the match
When updating points, the status of all control points is checked, and this is added to the number of eliminations of the opponent.
Figure 125 Updating points
When the maximum number of points is reached, the game switches to the post-game state and ends.
Figure 126 End of the game
In order to be able to test our game in the right environment, we need to put it in the cloud. We will use a free ranking of the service, which offers us up to 200 players on one server [62].
The process begins with the server configuration, obtains the project name from the Improbable console [119], and assigns a name to the Assembly and the Deployment. Furthermore, it is possible to include simulated players, but we are limited to only 10 of them.
Figure 127 Server configuration
Once we have uploaded the game to the server, we can run it on the local computer through the aforementioned console.
Figure 128 Starting in the console
This allows anyone to download the game and install and play it.
Figure 129 Local game start