Building Infinite Progression Systems in Unity: How We Engineered 64-Bit Math for an MMORPG

When Domi Online approached us with their vision for a "cap-less" MMORPG (a game where players could grind skills and level up indefinitely for years without hitting numerical limits) we knew we were facing a technical challenge that would require fundamentally rethinking how Unity handles game state.

Most MMORPGs eventually hit a wall. RuneScape caps skills at level 99. World of Warcraft raises the level cap with each expansion. This isn't just a design choice, it's often a technical necessity. Standard video game architectures use 32-bit integers for player stats, which max out at approximately 2.1 billion. For a game designed around infinite grinding, that's not infinity. It's a ticking time bomb.

In this technical deep-dive, we'll walk through how our team engineered a custom 64-bit progression system for Domi Online, bypassing Unity's standard variable limitations to create a mathematically sound foundation that can handle decades of player progression without breaking.

The Problem: Unity's Standard Integer Limits

Unity, like most game engines, uses 32-bit signed integers (int in C#) as the default type for numerical values. This gives you a range of -2,147,483,648 to 2,147,483,647. This is more than sufficient for most games.

But for an MMORPG with no level caps and no skill caps, this creates several critical problems.

Integer Overflow Breaks Game Math

When a 32-bit integer exceeds its maximum value, it doesn't gracefully stop. It overflows. The number wraps around to the negative minimum value, causing catastrophic logic failures:

• A player with 2.1 billion experience suddenly shows as having negative XP
• Leaderboards become meaningless as high-level players rank below beginners
• Combat calculations break when damage values exceed the cap
• Economy systems collapse when currency or item quantities overflow

Future-Proofing Requires Planning Today

Even if 2.1 billion seems impossibly high now, consider the lifespan of successful MMOs. RuneScape has been running for over 20 years. EVE Online has been live since 2003. If Domi Online achieves similar longevity, dedicated players will hit those caps. When they do, the game needs to handle it gracefully.

Standard Solutions Don't Scale

The naive fix of using long (64-bit) for some values and int for others creates a maintenance nightmare. Casting between types introduces bugs, serialization becomes inconsistent, and the codebase becomes a minefield of type mismatches that only surface when a player hits a specific threshold.

Our Solution: A Unified 64-Bit Architecture

Rather than treating 64-bit integers as an edge case, we made them the foundation of Domi Online's entire progression system. Every stat, every experience counter, every currency value uses a custom Int64 wrapper from the ground up.

Custom Serialization Layer

Unity's built-in serialization doesn't optimally handle long types across all platforms, particularly when syncing data between client and server in a multiplayer architecture. We built a custom serialization layer that:

• Compresses 64-bit values for network transmission, reducing bandwidth overhead
• Validates ranges server-side to prevent impossible values from malicious clients
• Maintains precision across all platforms (PC, mobile, WebGL) without floating-point drift

This meant replacing Unity's default serialization for any data structure that contained player progression values, implementing custom write/read methods using FishNet's networking library.

Database Integration for Persistent Worlds

A 64-bit progression system is only as good as its persistence layer. We architected the backend to:

• Store all player stats as BIGINT (64-bit) in the database schema
• Use atomic operations for experience gains to prevent race conditions when multiple systems (combat, questing, gathering) award XP simultaneously
• Implement server-authoritative validation to ensure clients can't spoof their progression values

The server becomes the single source of truth. When a player chops a tree and gains Woodcutting XP, the client sends an action request, the server validates it, applies the XP gain, and broadcasts the updated stat. The client never directly modifies progression values.

UI That Handles Enormous Numbers

Displaying numbers like "5,784,392,847 XP" breaks traditional UI layouts. We implemented:

• Dynamic number formatting that switches between notation styles (5.7B vs 5,784M) based on magnitude
• Logarithmic progress bars for skills, so the visual bar doesn't become imperceptibly small at high levels
• Leaderboard pagination with efficient database queries that can sort billions of records without locking up

The "Harsh World" leaderboard (Domi Online's competitive ranking system) needed to remain responsive even when querying the top players from a database with millions of entries. We implemented indexed queries and cached rankings that refresh on a schedule rather than in real-time.

The Architecture: How It Actually Works

Let's get specific. Here's a simplified example of how our 64-bit experience system is structured:

Core Data Structure

[System.Serializable]
public struct Experience
{
    private long _value;
    
    public long Value 
    { 
        get => _value;
        private set => _value = Math.Max(0, value);
    }
    
    public void Add(long amount)
    {
        // Clamp to prevent overflow even with 64-bit
        if (_value > long.MaxValue - amount)
        {
            _value = long.MaxValue;
            return;
        }
        _value += amount;
    }
}

This wrapper ensures:

• Experience can never be negative (preventing underflow exploits)
• Even 64-bit values have overflow protection (theoretically impossible to reach, but defensive programming matters)
• All modifications go through controlled methods rather than direct field access

Network Synchronization

Using FishNet's networking framework, we serialize experience gains efficiently:

public void WriteExperience(Writer writer, Experience exp)
{
    writer.WriteInt64(exp.Value);
}

public Experience ReadExperience(Reader reader)
{
    return new Experience(reader.ReadInt64());
}

FishNet handles the low-level transmission, but our custom serializers ensure the data remains consistent and validated across the network.

Level Calculation from Experience

Traditional level-up systems use lookup tables. With infinite progression, we needed a mathematical formula:

public static int CalculateLevel(long experience)
{
    // Uses a logarithmic curve that scales infinitely
    // Each level requires exponentially more XP than the last
    return (int)Math.Floor(Math.Log(experience / 100.0 + 1, 1.1));
}

This formula ensures:

• Level 1 requires minimal XP
• Level 100 requires significantly more
• The curve never "breaks" no matter how high the experience value
• Players always feel progression, even at astronomical numbers

The Results: Infinite Scaling Without Compromise

The 64-bit architecture delivered exactly what Domi Online needed:

Mathematical Proof of Infinite Progression

A 64-bit signed integer maxes out at 9,223,372,036,854,775,807 - that's over 9 quintillion. To put this in perspective:

• If a player earned 1 billion XP per second, it would take over 292 years to overflow
• The system can theoretically support trillions of players each grinding millions of skills without collision
• Our logarithmic level formula scales smoothly even at the theoretical maximum value

Real-World Stability

During alpha testing with thousands of concurrent users across Asia and Europe, the system performed flawlessly:

• Zero integer overflow bugs reported across months of stress testing
• Leaderboards remained accurate even with players reaching extreme stat values during testing campaigns
• Database performance remained stable with efficient indexing on 64-bit columns

Development Efficiency

By standardizing on 64-bit from day one, we avoided an entire category of bugs:

• No need to audit codebases for "will this overflow?"
• New features can assume infinite scaling without special cases
• Serialization and networking code is consistent across all progression systems

This architectural decision saved weeks of debugging that would have been spent tracking down rare overflow edge cases months into development.

Lessons Learned: When to Use 64-Bit Architecture

Not every game needs this approach. Here's when it makes sense:

You Should Use 64-Bit If:

1. Your game has no caps on progression systems (levels, skills, currencies)
2. You're building for a 10+ year lifespan where dedicated players will push every limit
3. Your economy involves large numbers (idle games, incremental clickers, trading-focused MMOs)
4. You want leaderboards that will never break no matter how competitive players get

You Don't Need It If:

1. Your game has hard caps by design (level 50 max, 999 item stack limit)
2. You're building a short-term experience (battle royale, puzzle game, narrative adventure)
3. Performance is absolutely critical (competitive FPS where every nanosecond counts)
4. You're working with legacy code that can't be refactored without breaking everything

The overhead of 64-bit integers is minimal on modern hardware, but the architectural commitment is significant. Make the decision early. Retrofitting a 32-bit codebase to 64-bit after launch is a nightmare.

Beyond Domi Online: Applying This to Your Project

If you're building a game with long-term progression, here are the key takeaways:

1. Plan your data types early - changing fundamental types mid-development is expensive
2. Use server-authoritative validation - never trust the client with progression values
3. Design UI for extreme numbers - your leaderboard will look ridiculous if you don't plan for billions
4. Test with absurd values - simulate players at the theoretical maximum to find edge cases before players do

At Ocean View Games, we've applied this same engineering rigour to every project we touch. Whether it's building scalable multiplayer architecture or optimizing Unity development workflows, we treat technical infrastructure as the foundation of great game design - not an afterthought.