Networking with Echo (Trying it with Unreal Engine) - Part 1

Overview

One of the main features planed for Echo was the inclusion of online multiplayer, but due my lack of experience with Online gameplay (and the Jam time restrictions) was almost immediately discarded. But now after a course and learn the basis with Epic’s documentation I decided to start reworking Echo with Unreal.

Challenges?

One of the features we liked more about Echo was its movement, it feels responsive and not so linear (it’s synchronized with the bat wings animation), so I have to see if I can replicate it over the network.

The other feature its the Echolocation itself.

And since the game must work offline (single player and local multiplayer) and “online” (LAN or over the internet) the unreal framework becomes very handy :).

With this in mind, we can define the following actors and their responsibilities.

ABatPawn (Inherits from Pawn)
Player’s representation in the game.
- UCurveFloat -> Change the input scale to simulate the Bat’s wings impulse force.
- USphereCollision -> Checks for spikes or other hazzards.
- UPaperFlipbook -> Draw the Bat sprite.
- UFloatingPawnMovement -> Controls movement.
AEcholocation (Inherits from AActor)
Player’s ability to navigate the map.
- UPointLightComponent -> Light the level.
- FTimeline (Controls the Echolocation visual effects)
APlayerController
Player’s Input controller (only useful if the ChangePossesion mechanic is present, otherwise, stick to use only pawn).
AGameStateBase (To keep track of game objective’s state change).
Manages the current state of objectives of the game (in this case, if the player(s) have reach the end of the level or have been reached by the bottom of the screen).
AGameModeBase (Game rules).
Monitors the current state of the game (can be used to check if the game objetives have been completed and/or check win/lose conditions).

After defining the main actor and responsibilities, we can be tempted to implement the whole game in one go since it’s pretty simple, it maybe a better idea to keep in mind that we want to add Online capabilities to our game. From Epic’s Documents:

Plan for multiplayer early

If there is a possibility that your project might need multiplayer features at any time, you should build all of your gameplay with multiplayer in mind from the start of the project. If your team consistently implements the extra steps for creating multiplayer, the process of building gameplay will not be much more time-consuming compared with a single-player game. In the long run, your project will be easier for your team as a whole to debug and service. Meanwhile, any gameplay programmed for multiplayer in Unreal Engine will still work in single-player.

However, refactoring a codebase that you have already built without networking will require you to comb through your entire project and reprogram nearly every gameplay function. Team members will need to re-learn programming best practices that they may have taken for granted up to that point. You also will not be prepared for the technical bottlenecks that will be introduced by network speed and stability.

Introducing networking late in a project is resource-intensive and cumbersome compared with planning for it from the outset. We therefore advise that you should always program for multiplayer unless you are completely certain that your project will never need multiplayer features.

TL;DR: Think and design the game for multiplayer early, never at the end.

Taking this in mind, and after doing some research about the Unreal’s Framework and Networking, we can add this information to our diagram.

ABatCharacter (Inherits from APaperCharacter)
Player’s representation in the game.
- UCurveFloat -> Change the input scale to simulate the Bat’s wings impulse force
- UCapsuleCollision (inherit from APaperCharacter)
- UPaperFlipbook (inherit from APaperCharacter)
- UCharacterMovement (inherit from APaperCharacter)
AEcholocation (Inherits from AActor)
Player’s ability to navigate the map.
- UPointLightComponent -> Lights the level.
- FTimeline (Controls the Echolocation visual effects)
APlayerController (Client Owner/Server -> Controls the pawn possesion if multiple pawns exists)
Player’s Input controller (only useful if the ChangePossesion mechanic is present, otherwise, stick to use only pawn).
APlayerState (Clients/Server -> To keep track of player’s state to the server)
Store’s information of the player (like name, ping, score…). This can be really useful if we need to keep track of more information about the player.
AGameStateBase (Clients/Server -> To keep track of game objective’s state change)
Manages the current state of objectives of the game (in this case, if the player(s) have reach the end of the level or have been reached by the bottom of the screen).
AGameModeBase (Server Only -> Game rules)
Monitors the current state of the game (can be used to check if the game objetives have been completed and/or check win/lose conditions).

Player movement and replication

My first intention when I started to implement the Player’s character, I choose APawn as my base class but later I changed to a APaperCharacter. Why?

Most of the components required are already in APaperCharacter.
It replicates over the network out of the box. (Yes, I could do this by myself, but lets be honest. If the behavior already exist, why not use it? I can cover what I have learn in another entry).

This change allows me to only take care of UCurveFloat component and the rest just make adjustments.

Echolocation

In unity, this mechanic was solve using the 2D lighting components. Since Unreal does not have a 2D lighting system (or components), we can achieve a similar result using it’s 3D light components and control it’s size and intensity with a Timeline (via blueprints for the sake of simplisity).

With C++ we only define the methods to trigger the Echolocation behavior (Timeline animation), leaving the astetics for blueprints.

Since the Echolocation is triggered by the player (a client) and can’t be replicated directly to other clients, we need to spawn the Echolocation actor in the server and notify the clients to trigger the Echolocation behavior. For this we can use a NetMulticast RPC (reliable of course) or implement it by a RepNotify variable (this time I use the RPC, but I’m planning to see if I can resolve it using RepNotify).

Progress made so far

At the moment of writing, this project have implemented:

The bat character with movement replication.
The Echolocation mechanic.

In case someone is interested in see the project follow this link. I don’t know if I’m going to finish it like it’s unity version, but at least the network features are going to be implemented.