Names in project : FDGameInstance (C++), BP_FDGameInstance
Handling the Menu’s – Show Main Menu
Writing and Reading Json files from disk (server) – SavePlayerInfoToDisk – Init : read and fill username and password from disk – Write Logbook Json – Write Chat Json – Write Json Base Files – Receive Login Name : Check of LoginName exists as UserName, if yes : sent FDPLayerInfo to client
The different flows of information in the project.
Information will be stored on the server, by using Json.
Login and User strategy. PlayerInfo will be in a Jsonfile on the server. The prototype will not have an add usersystem in Unreal. This will all be done in the JsonFile. Username will be unique identifier of each user.
PlayerInfo Stored and retrieved from server (GameInstance). Json Files When a player connects with the server, PlayerInfo is copied to the PlayerState. For example : Username (unique), Password (not copied to PlayerState), Full Name, University / company, email, class / group, avatar settings, previous avatar settings?, Timestamp?, last visit, time online.
Achievements player or group of players Stored and retrieved from server (GameInstance). Is copied to PlayerState and with groups to the GameState. Assignments made by students and group of students.
Storytelling / gamification This is probably going to be most important part in the future. In the prototype this is going to be most important part in the future. In the prototype this is going to be very simpel. Scavenger hunt Still a lot of research needs to be done
Chat Text From Client to PlayerController to all clients.
Voice chat Is out of the box available in UE?
Online Calculator Input Calculator should be visible for the other avatars looking at the calculator Information goes through GameState
Data FD_Watersurface, FD_Sewer, FD_Sea, FD_Rain These have to do with the watersystem on the island, most of these Blueprints / C++ . Most of them make complex calculations (velocity, waterlevels, discharge, waves, energyline, pressureline, …) Basic idea is that all calculations are made on the server.
Note : The hole watersystem on the island is connected, often some change can have effect on the hole system . But sometime this is not the case, so maybe a set of rules can be made (GameMode) to determine of a change leads to a recalculation of the complete system of only a part.
Movement of the players / avatars Is multiplayer out of the box.
Shape of the avatars Configuration of each avatar will be stored on the server.
We are going to create a chatbox on all clients. All steps are also explained in a video at the end. Note : When building you sometime have to go back and forth.
Step 1: Create widget FD_ChatWindow and FD_ChatText
Step 2 Add FD_ChatWindow and chatbutton in MainMenu.
Step 3 : Blueprints FD_Chatwindow You first have to make some events at the playercontroller
Step 4 : Add mainmenu in playercontroller, delete from gameinstance!
Step 5 : Gamemode
step 6 : Playercontroller
ProjectSettings > Input > add binding chat enter
Video demonstration chatbox
Extra : Adding the mainmenu through the gameinstance.
I did not like my solution, where I added the mainmenu widget in the playercontroller instead of from teh gaminstance. Ofcourse both solutions are correct, but I want to keep the menu widgets on the gameinstance. So I made the next corrections.
If you run, you will get the same result. In my opinion the second solution is more consistent with the idea to keep the menu’s on the gameinstance
So what did I learn? With focus on the dedicated server.
Replication to clients only works when it is set on the server.
Often you read the word clients, this is misleading. With characters and playercontrollers for example there is 1 server and 1 client!!. So you can not get access to all clients with a playercontroller or character.
My biggest misconception was that if you use for example the switch Has Authority , with authority you can’t get acces to the remote / client by using an custom event or the other way around. Example of how it really works
So the branch is set to client, but by using the event SetNameOnServerGI (runs on server) one gets access to the server anyway!!. Although the branch is set on client!!
Same when you set branch or switch to server, you can get access to the client by using an event which is “Runs on owning client”
A widget (menu) lives only on the client, a gamemode lives only on the server. So you need a for example a playercontroller (lives on server and client) to get a widget (menu) to communicate with a gamemode.
Probably I use reliable to often.
A menu widget can get acces to the gamestate client, but not to the gamestate server. You need to use the playercontroller (event run on server) to get something done on the server side of the gamestate from a menu widget.
If a variable is replicated and changed on the server side of the gamestate, it is visible for all clients!
To get access to player state in menu widget, you have to use the playercontroller
In the gamemode you can change the playername in playerstate.
According to documentation: The GameState exists on the server and the clients, so the server can use replicated variables on the GameState to keep all clients up-to-date on data about the game. Information that is of interest to all players and spectators, but isn’t associated with any one specific player, is ideal for GameState replication. As an example, a baseball game could replicate each team’s score and the current inning via the GameState.
According to documentation: A PlayerState will exist for every player connected to the game on both the server and the clients. This class can be used for replicated properties that all clients, not just the owning client, are interested in, such as the individual player’s current score in a free-for-all game. Like the PlayerController, they are associated with individual Pawns, and are not destroyed and respawned when the Pawn is.
For this part I will make a little game : Collecting coins. At the start there are for example 1000 coins in the bank. Each player can collected coins. When there are no coins left in the bank, the game is finished. Each client gets a message showing the coins collected by each player.
Although it looks a bit overdone for such a small game, I used gamemode, gamestate and playerstate:
Gamemode : Setting the max coins in the bank (1000)
Gamestate : Calculating collected coins by players and check if coins in bank are finished.
Playerstate : Tracking number of coins collected by player.
Playercontroller : used for connecting menu widget with gamestate and playerstate.
In the next screenshots I show the final blueprints, when building you most likely need to go back and forth.
Note: I only used the interface of gamestate and playerstate to get a reference. I should have used more functions going through the interface.
Step 3 Add Gamestate and Playerstate to you gamemode!! At first I had forgotten to do this 🙁
Step 4 Changes to the mainmenu
Step 5 GameMode
Step 6 GameState
Step 7 : PlayerState
Step 8 : Playercontroller
Most of the events in the playercontroller are necessary to connect the menu widget to the gamestate and playerstate. So they are called from the menu, to get something done in the gamestate or playerstate
Step 9 : BP_Pickup
Changes made to the existing BP_Pickup. In the first event you should add an has authority switch, to make sure coins is only set on the remote. The dedicatie server has no coins (has no graphical interface). At first I got a warning in the dedicated server log.
Step 10 : New Blueprint with cube (only one) called BP_Cube