Creating an Online Adventure Prototype

In this chapter, we will explore the fascinating world of an online space adventure game that has the potential to evolve into a massive multiplayer online role-playing game (MMORPG). Throughout this journey, we will lay the foundations for an immersive gaming experience, allowing players to join a persistent world and seamlessly synchronize their game state with the current state of the game world.

Here’s a snapshot of what the final spaceshooter adventure prototype will look like:

Figure 9.1 – Two players accomplishing the Destroy 10 Asteroids quest together

Our primary focus will be building a robust networking system that facilitates real-time interaction among players by using the powerful Godot Engine Network API. Through this system, players will connect to a central server, ensuring that everyone shares the same game world and can witness each other’s actions, promoting collaboration...

Technical requirements

To access the resources for this chapter, go to our online project’s repository found at https://github.com/PacktPublishing/The-Essential-Guide-to-Creating-Multiplayer-Games-with-Godot-4.0.

With the repository in your computer, open the res://09.prototyping-space-adventure folder in the Godot Engine editor. You will find all the necessary files for this chapter there.

Now, let us begin the onboarding process. In the next section, we will introduce the project, explore its main classes, and identify where we need to implement networking features.

Introducing the prototype

In this section, we will gain a comprehensive understanding of the core systems driving our prototype. As the network engineers of our fictional studio, our role is core in transforming our local game prototype into an exciting online multiplayer game prototype. To accomplish this, we must familiarize ourselves with the major classes and files that make up our project.

Let’s not overlook the significance of the onboarding process when we join a project. As network engineers, applying our knowledge and insights is essential for seamless integration into the development process. By understanding the core systems and concepts, we create a collaborative and productive environment, empowering the team to collectively bring our vision to life.

So, let’s dive into the heart of our prototype and unlock the potential of online multiplayer gaming. By the end of this section, you will be equipped with the necessary systems you can tweak to shape an...

Logging the player in to the server

In this section, we will implement a different type of logging system. This time, the players don’t have a lobby screen where they wait for other players to join a game and start a match. No, here the world is always active; it doesn’t start only when the players ask the server to start the match or the game. And this type of connection requires a different approach.

The major problem is that since the game world is always active and running, the players who join this world need to sync their game instance to the server’s game instance. This includes the position of objects, new objects that usually are not part of the world, for instance, other players and the number of objects (in our case, how many asteroids are currently available), and many other factors necessary to build a shared world.

It all starts with the player authentication, because now the server and the client are in different parts of the game life cycle...

Separating server and client responsibilities

Now that we have players sharing the same world, we need to establish which actions they are responsible for and which actions are part of the server’s responsibility. For instance, if a player shoots on their game instance and their bullet damages an asteroid but this asteroid was already destroyed by another player, what should happen? For this kind of situation, the server is the perfect mediator to prevent instance conflicts.

With all this context in place, players tell all peers, including the server, to update their Player instance according to their actions, but only the server should have the authority to manage the actual impact of these actions in the game world, such as if the player managed to destroy an asteroid or not. In the next section, we are going to understand how players can sync their actions, not only their objects’ properties, across all network-connected peers.

Shooting bullets on all instances...

Storing and retrieving data on the server

It’s time to handle a sensitive topic when it comes to online adventure games: databases. Note that in this book, we are not focusing on the best and most secure way to handle and protect a database. Instead, we are practicing and understanding what the Godot Engine Network API allows us to achieve and exploring its possibilities.

That said, in this section, we are going to implement the necessary steps to establish a communication channel where the client can retrieve its quests data from the server and send their progress updates to the server.

To do that, we are going to work with the two main classes in our quest system, QuestSingleton node and the QuestDatabase node. But before we set these classes up for this new challenge, we need to change how the database is structured. Since now the QuestDatabase node will work by delivering and handling multiple players’ data, the PlayerProgress.json file needs to have its data...

Summary

In this chapter, we learned how to allow players to join in the middle of a game run; how to synchronize their game instances; how to load, retrieve, send, and store information on a remote database; how to create a quest system; and overall, how to structure the very basics of an online multiplayer adventure game. In the next chapter, we are going to learn how to debug and profile the network so we can find bottlenecks and potential areas of improvement and optimization for our games. See you there!