Singleplayer and Multiplayer
In the previous article I shared my observations and views on the direction of multiplayer development. It's time to start gradually diving deeper into the topic. In this article I want to discuss what distinguishes singleplayer from multiplayer, and where these differences are located.
Introduction
-> Singleplayer and Multiplayer
…
What is considered multiplayer
First, we need to determine what will be understood by the word “multiplayer”. Let's fix it:
Multiplayer is the interaction between multiple players who directly influence each other.
That is, some abstract leaderboard We will not consider it a multiplayer, because the players do not interact with each other and do not directly influence each other. They only measure their results, obtained separately from each other.
Likewise clans, chats, Friends and others social mechanics will not fall under the given definition of multiplayer.
Client-server interactionall sorts LiveOps And cloud mechanics they also don't make the game multiplayer – many people use this service gameswhich can be completely single-player.
Where are the differences from the singleplayer
The difference between multiplayer and singleplayer projects, if we talk about the code base, is not global. To understand what to pay attention to when determining the type of project, it is necessary to designate some components.
An average game project, including a multiplayer one, can be represented from a technical point of view as a combination of the following large blocks:
CoreGame: core gameplay, the main game mechanics that shape the target gaming experience and define the genre.
Examples: car control mechanics, racing logic, AI opponents, destructibility system, etc.MetaGame: a broader context that introduces new features and mechanics that are not directly aimed at achieving the main goal of the game within the framework CoreGameThey are usually aimed at increasing the player's level of engagement, variety of interactions, and motivation to continue playing and return to the game.
Examples: car tuning, pumping, additional tasks, in-game economy, mini-games, social mechanics, etc.Infrastructure: technical “body kits” and plug-in modules.
Examples: sound engine, physics, work with remote nodes for social interaction and data storage, monitoring and analytics systems, etc.Runtime: the overall architecture of the project, the “glue” for all blocks.
Internally, these blocks can be divided into other smaller arbitrary parts, changing from project to project.
The key difference between a multiplayer project and a single-player one usually lies in the area CoreGame.
This is where players most often get the opportunity to directly influence each other. Many multiplayer games, when they can't find enough players for a new game session, turn into single-player games at this point: the player hangs out alone or accompanied by bots in the main game loop.
Here are significant differences in the implementation for providing a multiplayer mode. If it is necessary to turn a single-player project into a multiplayer one (and vice versa), then it will be necessary to edit mainly CoreGame.
Other blocks may also be affected. For example, in MetaGame may require lobbying, searching for players or selecting a server. And in Infrastructure There may be more services, systems, and remote computing nodes that will require coordination. But more on that later.
Multiplayer Classifications
To further reveal the distinctive features of multiplayer and for general visibility, I propose to consider the most frequently encountered classifications of multiplayer projects.
By interaction:
Competitive / PvP / Players versus Players: players compete against each other, in teams or individually.
Co-op / PvE / Players versus Environment: Players join forces to fight computer-controlled enemies.
On balance:
Symmetrical: all participants have approximately equal opportunities and goals.
Asymmetrical: different opportunities and goals are offered to different parties.
By the time of life of the world:
Massively Multiplayer Online Games / MMO / Massively Multiplayer Online Games: thousands of players interact simultaneously in one permanent virtual world.
Sessional: A small number of players interact in a single match or session, which starts over each time.
By process:
Synchronous / Realtime: all players are simultaneously involved in a single game process and interact with each other in the same virtual world.
Asynchronous: players interact with each other not in real time, but in turns.
Regarding technical implementation:
Local.
Network.
Local and network multiplayer
The gist local multiplayer in that players play on the same device, locally.
IN asynchronous games mode is used hotseatwhen the game transfers all control to a specific player on his turn.
IN synchronous games all players are given control at once, and players watch their gameplay on General screen or through Splitscreenwhen each player has their own piece of the screen.
In this mode, there are no differences from singleplayer technically there is practically none. There are several input sources: they are either processed simultaneously or in turn. Similarly, there are several output modes. Roughly speaking, local multiplayer makes only minor adjustments to the application's presentation layer.
Of greatest interest and complexity is network multiplayer. Here, each player uses their own separate device, and the players are united in one game by using a network connection. Most often, this is the Internet. In order for all players to play the same game, it is necessary to ensure the same game state on all devices at all times.
If in local version there was a single common game state, and it was necessary to transfer information within the same fast RAM, then in network implementation each device has its own copy of the game state, and it is necessary to constantly exchange data between devices that are located at a huge distance from each other in order to synchronize.
Such conditions a priori introduce more fragility and significantly greater time delays into the data update process. The situation is further complicated by the fact that all players are in different conditions: some have a faster connection, some are weaker. With such input, it is difficult to ensure the same game state on all devices and coordinate the actions of players among themselves.
Solving such problems requires the use of certain approaches when designing a game application. Transferring practices from single-player development will be successful in rare cases: perhaps only in projects with very slow or completely asynchronous gameplay. The faster the gameplay, the more “bells and whistles” and complications need to be introduced into the program code to take into account and compensate for the delays that arise.
Exactly network multiplayer and we will consider it further and examine in more detail what needs to be taken into account and done to implement it.
In the following articles, we will examine in more detail the problem of data synchronization, methods for implementing interaction, options for organizing a project, and discuss which projects are easier to start multiplayer development with.
Articles are also available on the following platforms: VK, Zen, Dtf.
Content
Half a year of mobile PvP development: Habr
Multiplayer resource roundup: Unity
Unity Multiplayer in 3 minutes: YouTube
How the multiplayer works: YouTube.Cyberstars
