Technical Lessons from Building One of Sui's Most Complex Fully On-Chain Games

FOCG Banner

Introduction

Vendetta launched one month ago and is currently one of the most popular games on Sui. It is a complex massively multiplayer strategy game that blends criminal empire building with resource management, territorial battles, and intricate social and economic systems, along with a deep lore. The game requires coordination across various packages, shared and owned objects, and numerous moving parts in both the smart contracts and front-end.

While development is ongoing, we are sharing our early experiences moving from concept to live deployment. These details are often undocumented and may provide useful guidance for others building large-scale applications on Sui.

Early Traction and Player Engagement

Vendetta’s launch exceeded expectations, validating both design and architecture:

  • 6500+ players
  • 250–350 daily active on-chain players
  • 300,000+ on-chain transactions
  • 1000+ unique token holders
  • 1100+ unique Vendetta Original DVD holders
  • 55,000+ token burnt through in-game activities (~5.5% of circulating supply)
  • Active Discord community with alliances, rivalries, and political strategy

This reinforces that fully on-chain games, when built with engaging mechanics and robust infrastructure, can maintain high engagement.

The Shared Object Scalability Challenge

Initial Architecture

Our original design used a unified shared object for player data management, which allowed easy frontend access to all player information from a single source. However, this caused severe congestion with 300–400 concurrent requests during our internal testing.

Owned and Shared Object Combination

We shifted to an architecture where player-specific data resides in owned objects, while shared objects handle global game states.

  • Each player owns a DVD NFT that stores their full game state and serves as their authentication key.
  • The frontend retrieves owned assets first and only queries shared objects for world-level mechanics like map generation or global resource spawning.
  • Shared objects remain critical for multiplayer events that update multiple player states at once, such as battles.

This restructuring removed congestion bottlenecks while preserving decentralization. The owned object pattern proved essential for building scalable multiplayer experiences on Sui.

Ownership and Validation Flow

Owned object (DVD) → PlayerID (shared object) → Frontend accesses PlayerID → Contract validates DVD and PlayerID ownership → Player state is updated.

The primary reason for using shared objects is that the game’s state and resources can change dynamically based on events such as battles, resource operations, building activities, and various crimes. For example, if one player attacks another player’s turf and wins the battle, resources like turf count, number of gangsters, weapons, cash, and XP must be updated for both players. This requires a shared object architecture to manage state changes across multiple participants.

In this system, each player owns a DVD, which contains a reference to their PlayerID, a shared object storing their game stats. When a player, say User A, wants to perform an action like blackmailing User B, the frontend identifies User A’s DVD upon login. User A then selects User B’s PlayerID for the blackmail. The contract first validates that the DVD passed in the transaction belongs to User A and that the PlayerID inside it can only be updated by them. Once validated, the contract processes the blackmail, updating the relevant game state for both User A and User B.

Validation Flow

Package Size Constraints and Modular Architecture

100 KB Limit

Sui Move enforces a strict 100 KB package size limit. As Vendetta grew, we repeatedly hit this ceiling, forcing architectural refactors.

Modular Strategy

We broke the code into specialized packages for distinct gameplay areas: crimes, map systems, events, and more. This:

  • Kept each package within size limits
  • Enabled independent upgrades to individual systems
  • Allowed multiple development streams in parallel
  • Improved code organization and maintainability

The trade-off is more complex dependency management and cross-package integration.

Dynamic Map Generation Architecture

Limitations of Static Maps

Our initial design concept involved pre-generating a fixed number of map tiles as shared objects. For an 8,000 tile game world, this approach would have created thousands of static objects at deployment.

The gas costs alone would have made the game economically unviable for players, and worse yet, every map query would have required accessing a massive shared object, creating the exact congestion problems we were trying to avoid.

Dynamic Generation

We developed a dynamic map generation system that creates new territories as players explore and expand their empires. The system operates on several key principles:

  • Map radius and density parameters define generation rules
  • New shared objects are created automatically as players capture free territories
  • Territory capturing mechanics trigger map expansion when needed
  • The map scales infinitely without requiring pre-allocated storage

This approach successfully eliminated the storage and congestion issues while providing players with a truly expansive game world that grows organically with player activity.

Real-Time State Synchronization

Blockchain Timing Challenge

Fully on-chain games cannot continuously update state without transactions, which complicated mechanics like attack regeneration, raid regeneration, daily check ins or resource accrual.

Hybrid Approach

We combined client-side calculations with contract validation:

  • The frontend tracks elapsed time and estimates incremental changes
  • Smart contracts verify and sync during the next interaction
  • Time checks prevent exploitation while keeping the experience responsive
Hybrid Approach

Dynamic Field Access Limitations

Sui Move does not support generic object’s data accessibility for security reasons. This limitation required us to restructure object interactions and ensure that all necessary data is passed explicitly through function parameters rather than accessed dynamically.

Upgrade and Dependency Management

Sui Move package upgrades have specific limitations regarding what can be modified. Managing dependencies across multiple packages while maintaining upgrade compatibility requires careful planning and version management strategies.

Experience Vendetta

Experience Vendetta at vendettagame.xyz

Conclusion

While Vendetta remains in active development just one month post-launch, our experience demonstrates that sophisticated fully on-chain gaming can attract significant player engagement when properly architected. The technical challenges we encountered and solved provide a roadmap for other developers building complex applications on Sui.

For developers considering similar projects, we recommend designing with Sui’s architectural constraints in mind from day one rather than discovering them mid-development. The platform’s capabilities are substantial, but success requires working with its inherent strengths. We hope these lessons help accelerate development for other teams as the Sui ecosystem continues to mature.

Enlarged image