Auto Siege is a game where, each round, players spend gold to improve their offense and defense. The better your ally Attackers perform against opposing towers, the more damage is dealt. The last player standing wins.
Shop Phase:
Spend gold to buy Attackers, Defenders, or Level Ups. Place Towers on your board and order your Attackers optimally. Edit your path by connecting the start and end tiles.
Buy Level Ups to:
Improve the quality of your shop
Increase the number of Attackers sent
Increase the number of Towers allowed on your board
Expand the number of tiles your path can use
Battle Phase:
Players are paired for battle. Attackers on each player's numbered tiles are sent to the opposing player's board.
Attackers of the same Tribe can have synergies with each other. For example, the Undead Giant becomes stronger when other Undead die nearby, and Crumble summons multiple Undead upon death. Towers of the same Tribe also have synergies. For example, Arcane Towers increase their chance of double casting their abilities when there are more Arcane Towers on the board.
Stacking Tower synergies and building Attacker compositions that scale into the late game is the key to victory.
Tools:
This project was developed in the Unity Game Engine using C# for scripting. It features real-time multiplayer functionality powered by Netcode for GameObjects, with custom 3D voxel models created in MagicaVoxel.
In Auto Siege, players can click and drag their Units to place them on specific tiles. The position of these Units must be synchronized across all clients in the multiplayer session.
The code shown includes two key functions that handle the initial phase of grabbing a Unit:
TryGrab() is a client-side method triggered when the user clicks the mouse. It checks whether a Unit is under the cursor using a raycast. If a valid Unit is found, it sends a request to the server to initiate a grab.
GrabUnitServerRPC() is a server-side Remote Procedure Call (RPC) that processes the client's grab request. It verifies that the request is valid—ensuring the game is in the correct phase and the Unit is located on the requesting player's board. If the validation passes, the server updates its internal data to reflect that the player is now holding the Unit.
During each server update, the server uses input data (e.g., mouse position) sent by clients to update the positions of any Units they are currently holding, ensuring consistent and synchronized movement across all clients.