BIG DAY. Setup Core Multiplayer Structure

Watched lots of videos to understand my first issue - WHERE DOES EVERYTHING GO!? The premise of a simple game manager is a lot more complicated over a multiplayer game than I first expected but I’ve learned so much so quickly.

After doing tons of research, I realised I needed to visualise some things out to help me makes sense of it and plan it all. I decided to create a flow chart on LucidChart to help me figure out the processes when a player starts a game, and how the game states/ & game mode will behave.

I worked on creating a fresh Game Mode and Game State Blueprints from scratch, and immediately came to my first issue. From my research, the 'game score’ in my case, the values of Hope & Despair, should be kept and tracked in my Game State. But where should they be updated? Player State isn’t the best for this, as Hope & Despair cancel each other out, when one goes up, the other decreases. So it would need to be managed on a more global level than Player State.

Eventually I decided to have the functions that apply the paradigm changes in the Game State, when I came to my second problem. When should the scores be updated? I want to build the networking as efficient as I can, and want all my features to be as event-based as possible. Since the Game State would need to cast to the PlayerControllers to update their values Paradigm values it would be too expensive to do this in On Tick. To do this I made it so that after the values have been changed on the server, they would then multicast out the values on a per-event basis. This is just a starting implementation to get things working. As I may have some scores increment over a set time period, that might be closer to an on-tick functionality so we’ll keep an eye on this.

I created a simple widget, to show the values of Hope & Despair, and a bar that will show the progress. Even this was a challenge, because I had to understand where the values the widget would update would come from, and how often they would update as well. My Paradigm update structure currently works like this:

1. In the Game Mode, the base amount of Paradigm is set to 50. OnPostLogin, after a user joined, their values for Hope and Despair are initialised to the base Paradigm value.
   

2. On the press of a test key, this will either increment or decrement Hope in the Game State, before adjusting Despair in the opposite direction, keeping the total paradigm at 100. Once the values have been updated in the gamestate, they will then call an UpdateAllParadigms function to update the paradigms to each player controller. This function is multicast, so both users get the update.
   

3. UpdateAllParadigms will the retrieve the owning Player Controller, and update Hope and Despair on that class, so that the player's HUD widget can access them.
   

4. The player's HUD Widget will periodically cast to the PlayerController (initially set to every 0.5s instead of on tick to reduce the number of memory-intensive casts happening regularly) to retrieve the paradigm values to show on screen. As the Widget or HUD class doesn't have access to the Game State, they'll need to get them from the Player Controller instead.

Even after putting everything together I setup my client to playas a Listen Server with two player, tested it aaaaaand things still weren't working. That’s when I checked the output log, and found that my new GameState class was incompatible with the ThirdPersonGameModeBase class I had forgotten to replace, and after putting in my new Game Mode class, things started to work!

Super proud of the progress so far, and now can start to flesh out the functionalities, ensuring that what needs to replicate, does, and can test each feature in context of the game mode, as I go along.

I also learned how lots of pieces fit together to make multiplayer work. It makes transferring the game manager to C++ a little daunting, as I was initially planning on avoiding to implement the networking side of N:S via C++, but if I'm able do it at some point, I know that I’ll learn so much.