Karan Nandkar
Senior Gameplay Engineer
← PROJECTS / TANKZ
// CASE STUDY

4v4 Tankz N Glory

Multiplayer Combat Systems Built for Fair Competitive Play

UnityMobile · 4v4 Shooter
Shipped
Unity · Mobile Multiplayer · Team Deathmatch · Progression Systems

A real-time 4v4 mobile team-based shooter built around fair multiplayer combat, scalable gameplay systems, and long-term player progression.

Tankz N Glory focused on competitive team battles where responsiveness, combat consistency, and strategic progression directly shaped player retention.

The challenge was not simply building a shooter.

It was creating a multiplayer system players could trust while supporting long-term progression without breaking gameplay balance.

// PROJECT OVERVIEW

Tankz N Glory is a real-time 4v4 team deathmatch game built for mobile devices, designed around fast competitive combat and scalable long-term progression.

The project needed to support:

Unlike casual multiplayer games, players judge shooters through responsiveness and fairness first.

If combat feels delayed, inconsistent, or unbalanced, players experience it as broken gameplay.

The goal was to build multiplayer architecture and progression systems that remained predictable, extensible, and production-ready as new content, tanks, and competitive systems expanded.

// MY OWNERSHIP

I worked on multiplayer combat architecture, gameplay systems design, progression systems, and performance stability across the core PvP loop.

Multiplayer synchronization and combat fairness systems
Server-authoritative combat architecture
Client-side prediction and lag compensation
Ability systems and stat modifier architecture
Inventory and tank progression systems
Tank class and combat role design
Progression and retention system design
Performance optimization for mobile matchmaking and loading

The focus was not just building features, but building systems that could scale without creating competitive instability.

// THE CORE CHALLENGE

Real-time mobile shooters create a difficult balance problem.

Players expect fast, responsive combat, but mobile networks and device limitations constantly fight that expectation.

As development progressed, three major problem areas emerged:

Each issue looked separate, but the root problem was the same: Systems that worked independently needed to remain stable when combined inside competitive multiplayer.

THE REAL ENGINEERING QUESTION

How do we build progression and depth without sacrificing fairness?

That question shaped every major technical decision.

// KEY TECHNICAL DECISIONS
01

Server-Authoritative Multiplayer Combat

Early multiplayer prototypes exposed common real-time shooter problems:

  • Players appearing out of sync
  • Delayed actions under poor network conditions
  • Inconsistent combat outcomes between clients

This directly damaged trust in competitive gameplay.

Instead of relying on client trust, I focused on authoritative combat resolution.

This included:
  • Server-authoritative validation for all combat-critical logic
  • Client-side prediction to keep controls responsive
  • Interpolation for smoother remote player movement
  • Network optimization to send only essential state changes
  • Lag compensation and periodic validation for consistency

The goal was not perfect network conditions.

It was fair combat outcomes under imperfect ones.

That difference matters.

02

Data-Driven Gameplay Systems for Tanks and Abilities

Without strong architecture, customization systems quickly become hard-coded and difficult to balance.

That creates long-term production pain.

I designed gameplay systems as modular, data-driven components instead of tightly coupled feature logic.

This included:

Tank Stats System
  • Attack
  • Defense
  • Speed
  • Critical Chance

Stats could be modified through upgrades, abilities, and progression systems without rewriting core gameplay logic.

Ability System

Abilities applied temporary or conditional modifiers instead of permanent state changes.

This ensured:
  • Predictable stacking behavior
  • Safe activation and deactivation
  • Cleaner balancing across multiple tank types
Inventory System
The inventory handled:
  • Tank ownership
  • Loadouts
  • Unlocks
  • Upgrade progression

Gameplay data was separated from UI representation, making expansion significantly safer.

This allowed new tanks and systems to be added without architectural rewrites.

03

Strategic Depth Through Tank Roles

Early playtests showed that raw shooting mechanics alone were not enough to sustain engagement.

Players needed stronger reasons to coordinate and adapt.

I introduced clear tank classes that created team strategy through role-based gameplay.

This included:
  • Assault → High damage and frontline pressure
  • Support → Buffs, survivability, and team utility
  • Scout → Speed, flanking, and map control

Each role interacted differently with abilities and stat systems, encouraging cooperation and reducing repetitive mirror-match gameplay.

This improved both competitive depth and long-term retention.

04

Progression Systems That Reinforced Gameplay

Without progression systems, matches felt isolated and disposable.

But badly designed progression creates pay-to-win frustration.

The goal was progression that rewarded mastery, not advantage.

This included:
  • XP-based progression tied to performance
  • Transparent stat tracking and player feedback
  • Unlockable upgrades that expanded playstyle choices
  • Matchmaking aligned with progression to preserve fairness

Progression became a retention system without replacing skill-based gameplay.

That distinction is critical.

05

Performance as a Supporting System

Performance was treated as infrastructure, not post-production cleanup.

Gameplay systems fail if technical friction interrupts the player experience.

This included:
  • Optimized asset loading for faster match startup
  • Stable 30 FPS targeting for lower-end devices
  • Match flow allowing players to enter as soon as loading completed
  • Reduced runtime spikes through better memory and state handling

The goal was not visual ambition.

It was frictionless competitive gameplay.

Performance protects fairness too.

// RESULTS

The final architecture delivered stronger multiplayer trust, scalable gameplay systems, and healthier long-term progression loops.

Fair and consistent real-time 4v4 multiplayer combat
Scalable systems for abilities, inventory, and tank progression
Increased strategic depth through clear role-based gameplay
Faster match starts and stable performance across low-end devices
Architecture capable of supporting future competitive modes and content expansion

The result was not just a functional multiplayer shooter, but a system designed for long-term competitive support.

// WHAT I'D IMPROVE NEXT

If Tankz N Glory were extended further, the next major focus would be:

The important part is that the current architecture supports these improvements without major refactoring.

That is what production-ready multiplayer systems should do.

// FINAL REFLECTION

Multiplayer fairness starts with architecture, not balancing.

Players do not trust a game because damage numbers look fair.

They trust it because actions resolve predictably and systems feel consistent.

Tankz N Glory reinforced a principle that applies across every competitive multiplayer project:

Progression should support competition.

It should never replace it.

Good multiplayer systems protect fairness first, because fairness is what keeps players playing.

← Back to Projects// TANKZ · 2023