Project Survivor

My contribution

I designed and programmed the full project in Unity with Mirror and KCP. My work covers the client, server architecture, combat, character progression, procedural loot, inventory, equipment, stash and player trading. I also set up the Linux server and the Jenkins deployment workflow used to update it.

Main systems

Authoritative Linux server with KCP transport for responsive multiplayer combat.
Custom Instance Manager that starts isolated maps and assigns available ports.
Server-side ability and damage pipeline with synchronized combat feedback.
Character progression, loot, inventory and trading systems synchronized with Mirror.

How it works

Multiplayer architecture

From the town to isolated maps

Players first connect to a shared town. When a map is requested, the server saves the player state, selects an available port and starts a separate headless Unity process. The client is redirected only after the new instance has had time to boot.

The map identifier, random seed and selected difficulty are passed to the new server process.
Each map runs in its own process, with separate session state. Capacity still depends on the host and has not been established by a large-scale load test.

Combat and progression

Server-authoritative gameplay

Spells and damage are resolved by the server, while clients receive the visual feedback. A synchronized statistics component manages health, mana, resistances, critical hits, elemental damage and progression.

Spell tags such as Projectile, Fire and Cold determine which character bonuses are applied.
Projectile count, pierce, speed, cooldown and damage are combined at runtime for each cast.

Items and builds

Procedural equipment

Equipment is generated from an item base, rarity and item level. Magic and rare items receive weighted prefixes and suffixes, with tiers and values selected from data-driven pools.

Inventory, equipment and character statistics stay synchronized across the network.
Currency items can modify existing equipment by adding or rerolling affixes.

Player economy

Server-validated trading

The trade system is controlled by the server. It checks player distance and session state, locks offered inventory slots and resets both confirmations whenever an offer changes.

Each trade uses revisions so an outdated client cannot validate a changed offer.
Both players review the final state before the server completes the exchange.

What I learned

Project Survivor is still in development. Building it has broadened my view of Unity beyond local gameplay: I learned to split authority between client and server, anticipate synchronization and lifecycle issues with Mirror and KCP, and debug the consequences of a persistent dedicated Linux process. Running map instances and saving player state made deployment and recovery part of the design, while Jenkins taught me to automate headless builds and repeatable updates to the VPS. It has made me more deliberate about modular, data-driven systems, profiling and validating changes across both the Unity client and the server.

What it is