Another week of GSoC has flew by! This week, I worked on implementing Game Restart and Player Statistics systems. I learnt a lot about implementing things correctly for a multiplayer gameplay through trial-and-error.

Player Statistics System

Player Statistics system includes storing information about kills and deaths of player in the game. It is necessary to store a statistics in a way such that everyone who is playing can check them. However, no one except the main server should be able to make changes to it. So, a PlayerStatistics Component was added to the player with its fields marked with @Replicate. Terasology engine does not copy all the components from server to clients. Hence it is necessary to mark the fields and components, which we want each player/client to have access to, with @Replicate. Default replication mode is Server-to-Client which just suits our needs! Next, task was to add a system to modify this component. Similar to Components, Terasology engine provides a way to separate where a particular system is going to run. Hence, a simple RegisterMode.Authority does the trick to ensure that the given system runs only on server.

Now, once the game is over and Game Over Screen is displayed, we need to display the Statistics correctly too. Hence, I used migLayout for this purpose which functions essentially as a table layout. You go on adding cells to a row and specify when to change to a new row. More details can be found here.

Here’s the final outcome:

Game Restart System

Events are always replicated as opposed to Components. One can specify which the type of replication through annotations like @ServerEvent, @BroadcastEvent, etc. You can read more about it here. So, I used a ServerEvent when Restart Button is pressed to prevent clients from any kind of cheating. Then, once relevant changes are done on server, I used a BroadcastEvent to specify all the clients that restart process has completed.

PR: Added Statistics and Game Restart Systems #88

Problems with Player Skinning

Some bugs were discovered in a pr I worked during Community Bonding period. I was saving the SkeletalMesh Component after modifying it but it was discovered that VisualCharacter Entity that holds this component is not replicated on clients. Hence, I used another component LASTeam, which is replicated to clients, to modify the skeletal mesh everytime a character is spawned or the LASTeam Component is changed. It now works correctly when a player leaves and joins again or even if the game loaded from a save file.

PR: Changing player skins through skeletal mesh #80

How it looks now:

What’s Next?

I am planning to work on minor but essential things pending for Gameplay system like automatically taking flag back to base if they haven’t been taken by anyone for some time after dropping, randomizing spawn position, ensuring that loading game from save file works properly, etc.