FPS Monopoly
About the Project
FPS Monopoly started as a Unity college project based off of the game FPS Chess, to use a life-size board with huge dice that the player has to throw to determine their move. The plan was to integrate the ability to have the choice when you land on an owned piece between paying rent, or fighting the owner where if you win, you don’t have to pay rent and if you lose, you have to pay double rent. This system could even be branched out to include discounts when trading properties with players and the existing AI could be improved to enable the prior mentioned system to get free utilities and lighting, or pay double if you lose. However I soon realised that, especially at my current Unity abilities, the scale for this project was astronomically big so the project morphed into a sandbox for me to do the class work and try to learn how to integrate Photon successfully.
Development Overview
Gameplay
As explained, this project was designed to follow the basic gameplay loop of monopoly, where the player rolls 2 dice and moves forward that number of spaces landing on a property. Therefore this is where I started before the project changed direction. To achieve this I started by adding the ability to throw some dice, instantiating a die prefab with a trigger on each face just in front of the player with a random rotation and then adding a force to it’s Rigidbody. To give slightly more control to the player and improve engagement, I made it so that the longer you hold down the throw button, the bigger the force applied to the die and therefore the further it will go and the more aggressively it will bounce off of the board bounds. On each die is a script that checks if the die has stopped moving by comparing its position every half second and when it has, it checks through an array of triggers on each face in a for loop to determine which face is in contact with the floor. This returns the upwards facing face to the Game Manager which adds up the 2 rolls of the player and displays this clearly on the screen. It then sets a trigger on the target property active, with a script that freezes the player in place when entered to stop them moving after their turn.
Multiplayer
Something vital in a board game recreation is the ability for multiple players to join and be on the same board, especially one that would involve PVP combat. After some research about the different ways of making a multiplayer game, and realising that local multiplayer wasn’t really possible for this game, I found out about Photon. It’s wide variety of products that simplify multiplayer development, including free options and relatively simple integration, made this a very good choice considering my complete lack of experience in the field. To complete this I referred to a variety of tutorials and documentation, creating and setting up a loading scene and a create/join room scene. Then I inevitably spent lots of time troubleshooting and bug fixing after nothing worked. After joining the same room, I then had to make sure that everything displayed correctly on both players which involved systematically adding the Photon View script to various objects to synchronise their position and rotation. Finally I had to adjust various scripts to ensure that players are controlling their players, that they were seeing out of the correct camera and that they were only throwing their own dice. Whilst I didn’t learn too much about how the networking itself worked, or retain much of what I did learn about it, I did learn lots about how to troubleshoot this process, and gain experience in what needs constant synchronisation and about how to develop mechanics that interact correctly in a multiplayer setting.
