Dev log 23/03/2021

The Game State now holds the winning team ID. This is being used for both the clients and the server to determine who the winning team is based on a single variable replicated over the network e.g. red team is 1. Blue team is 2.

The winning team ID is set by the game mode along with the method to end the match once a winner has been declared within the rules.

Check score method

End match method

The game mode "End Match" method then calls the game state to notify the players that the game is over via a multicast call named MulticastDisplayGameOverWidgets. This loops through each player controller, both on the server and clients and triggers a user interface widget to appear on screen.

If the red team wins, players on that team display a message “You win!” and the blue team players display “You lose”.

Multicast method

The game state winner ID is checked against the player state current team number. This is because the player state is unique to each connected player and the team variable is set at the beginning of the match.

User interface widget

Screengrab of game over scenario - red team wins

This completes the criteria for a basic game loop with a winning and losing team declared at the end of play. The basic C++ project now has all of the requirements listed in the initial specification. This will be summarised below.

---

Project Summary

The basic game mode has been created with the planned requirements. It supports multiplayer with the basic mechanic of two teams collecting coins until a winning score is reached by one of them. This fulfils the project’s aim of building a simple rule based game and gives a basic insight into the server/client model.

Lessons learned about the client-server model in Unreal Engine 4

Game mode should control the game flow and handling of new players connecting and team assignments.

Game state should handle the information pertinent to that session e.g. the red and blue team score - this enables it to be stored in a network space and updated to both servers and clients.

Player state should handle player specific information e.g. the player team ID, the player’s personal score etc - player state is unique to each player on the network.

Player controller should handle the player user interface and move the pawn/character.

The player pawn/character can only carry out actions authorized by the server e.g. firing a weapon code is carried out by the server and not run on the clients local machine.

Actors must be set to replicate in order for all players to see them update/perform an action.

Lessons learned about network development

Each feature added must be tested on both the server and client to ensure it works on both - this is extremely important when developing multiplayer games.

The server is god - this runs the entire show and must control game events.

Testing with one server and one client is good enough for game mechanic testing - doesn't need to be multiple clients run on one machine as one is enough.

Unreal Engine logs are your friend for debugging - did that method fire or this thing happen on the server.

Project Demonstration video

What's next

This project has served its purpose as an initial prototype to learn Unreal Engine 4 and its network features. However, to add more complexity to the simple coin collector concept would take away what its initial purpose was meant for.

With this in mind, the project will be forked into a new version to allow more complex features to be added. The new version will include:

• Arena map - dedicated map instead of the default template.

• Dynamic spawning actors.

• Game managers.

• Game clocks/timers.

• Connection to Steam services.

The new project will have its own specification drafted listing the above.