Devlog7. Money and Tile Ownership


Introduction🪙

To support buying, owning, selling, and transferring tile assets in a multiplayer board game, I implemented a shared economy system. It connects directly with the tile layer via TileVisualizer, and manages player balances across the network using Photon’s property sync and RPCs. The system includes three main components: TilePurchaseManager, PlayerMoneyManager, and PlayerMoneyNetwork.

Implementation

TilePurchaseManager:

When a player clicks the Buy button, TilePurchaseManager calls TryPurchaseTile() to check whether the tile is available and the player has enough money. If the conditions are met, it deducts the money, assigns ownership, and broadcasts an event.

Ownership is applied using a Photon RPC call to RPC_AssignOwner() on TileVisualizer, which updates all clients. At the same time, the purchased tile is added to the local list of owned tiles, and updates the player's total tile count.

When a player decides to sell a tile, the ReleaseSingleTile() method removes it from their list, resets ownership via RPC, and updates the count. If a player leaves the game, ReleaseTilesOwnedBy() removes all their properties automatically.


 PlayerMoneyManager:

PlayerMoneyManager handles the logic for adding, subtracting, and setting a player’s money. It uses Photon CustomProperties to store money values and triggers a money update event that other systems (like UI) can subscribe to. If a player’s balance drops to 0, a game over event is fired and the turn is forcibly ended.



Reward money when go through the start point

PlayerMoneyNetwork:

For rent and payments between players, PlayerMoneyNetwork handles synchronized transactions. When a player steps on someone else’s tile, it uses an RPC to safely transfer money between payer and receiver, while checking edge cases like negative balances.

Subtract/ add money for payer/ receiver

Photon Methods

Photon uses two main methods for syncing data: CustomProperties for persistent values like money and tile count, and RPCs for immediate actions like ownership assignment and money transfer.

Stores each player's money values:

ExitGames.Client.Photon.Hashtable props = new() { { "Money", amount } };
player.SetCustomProperties(props);

Transferring money between two players:

photonView.RPC(nameof(RPC_PayPlayer), RpcTarget.All, payerId, receiverId, amount);

Gameplay Demonstration

Sell and pay with 4 players

Final Outcome and Analysis

This system allows players to earn, spend, and transfer money across the network with synchronization. Also it can handle multiple edge cases, including players trying to overpay, run out of funds, or leave the game.

Design Patterns

  • Command: The RequestPayPlayer() → RPC_PayPlayer() chain acts like a command to execute a remote transaction.
  • Mediator: TilePurchaseManager coordinates between tile ownership logic and money updates

Playtest Feedback

During testing, players initially started with 5000 gold and received +500 each time they passed START. However, it caused a rapid land purcahse: by the end of Lap 1 (Round 11), 16 out of 27 tiles were already owned. Most players spent the early game buying tiles nonstop.

As a result, Lap 2 was dominated by chain rent payments and battles. Players who had fewer moves early on quickly fell behind. By Round 20, two players had already lost all their funds and were eliminated. Without room for comeback, the late game became less strategic and more punishing.

To improve pacing,I reduced the initial funds to 3000 gold and increased the lap reward to 1000. This would slow down early expansion and keep the game state more open through the midgame.

🔗Playtest data: playtest doc.

Future Plan

I’ve considered adding a tile trading system, where players could negotiate and transfer owned tiles. This might make mid-game choices more flexible and help players recover when low on cash. Additionally, a mortgage mechanic might be helpful.Players could temporarily give up rent income from a tile in exchange for emergency funds, then reclaim it later.

These features aren't part of the current build, but could be explored if time allows and the design calls for more strategic variety.

Reference


Leave a comment

Log in with itch.io to leave a comment.