Building Gridzo: A Scalable Competitive Gaming Platform with Unity WebGL, Next.js and DynamoDB
This article was created as part of my submission for the H0 Hackathon.
Introduction
Most online competitive games are built as isolated ecosystems. Every new game typically starts from scratch with its own authentication system, leaderboards, player profiles, and progression. As an indie game developer, I wanted to build something reusable instead—a platform where competitive games could plug into a common infrastructure.
That idea became Gridzo.
Gridzo is a cloud-native gaming platform that provides shared player identities, persistent profiles, leaderboards, statistics, and competitive infrastructure. The first game running on the platform is Sky City Rush – Competitive, a Unity WebGL racing game where players compete globally across multiple tracks.
Rather than building a website around a game, I built a platform around competitive gaming.
Why I built Gridzo
As I continued developing games, I noticed that every multiplayer or competitive title required solving the same set of backend problems:
- User authentication
- Player profiles
- Leaderboards
- Match history
- Statistics
- Persistent storage
- Deployment
These systems rarely depend on the gameplay itself.
I wanted to separate the competitive platform from the games.
That led to Gridzo—a platform where each game focuses on gameplay while Gridzo provides the competitive ecosystem.
Sky City Rush became the first proof-of-concept demonstrating this architecture.
The problem with game-specific competitive systems
Traditional online games tightly couple gameplay with backend services.
Game
├── Authentication
├── Profiles
├── Leaderboards
├── Statistics
├── Rankings
└── Match History
This works for one title but becomes increasingly difficult to maintain as additional games are introduced.
Gridzo instead follows a platform approach.
Gridzo Platform
┌────────────────────┐
│ Authentication │
│ Player Profiles │
│ Leaderboards │
│ Statistics │
│ Game Registry │
└────────────────────┘
▲
┌────────┼─────────┐
│ │
Sky City Rush Future Games
Every game shares the same identity and competitive systems while remaining independent in terms of gameplay.
Architecture overview
The frontend is built with Next.js and deployed on Vercel.
The racing experience is developed in Unity and exported as a WebGL application hosted on Amazon S3 and delivered globally through Amazon CloudFront.
Player authentication is handled using Firebase Authentication, while all persistent game data is stored in Amazon DynamoDB.
The communication flow looks like this:
Player
↓
gridzo.loen.in
↓
Amazon Route53
↓
Amazon CloudFront
↓
Vercel (Next.js)
↓
Unity WebGL
↓
Race Result
↓
Next.js API
↓
Amazon DynamoDB
This architecture cleanly separates gameplay from backend services while allowing both to evolve independently.
Unity ↔ Next.js communication
One of the most interesting technical challenges was enabling communication between Unity WebGL and the Next.js application.
When a player finishes a race:
- Unity collects the race data.
- A JavaScript bridge exposes browser functions to Unity.
- Unity submits the race result to the Next.js API.
- The backend validates and stores the run.
- Updated competitive information (such as leaderboard rank and personal best) is sent back into Unity.
- Unity displays an in-game result screen.
This creates a seamless experience where the player never leaves the game while all competitive logic is handled by the web application.
DynamoDB data model
Instead of storing game-specific information, the database is designed around reusable platform concepts.
Some of the primary tables include:
- Players — Global player identities
- PlayerProfiles — Shared profile information
- Games — Registry of games available on Gridzo
- GameRuns — Every competitive run submitted by players
- Usernames — Username lookup and uniqueness
A single GameRuns table serves as the source of truth for competitive data.
Leaderboards, race history, and statistics are generated from these runs, making the architecture flexible enough to support very different types of games without redesigning the database.
Scalability considerations
Although Gridzo currently hosts only one game, it was designed with future growth in mind.
Several architectural decisions contribute to scalability:
- Independent hosting for the web application and Unity assets
- Global asset delivery using CloudFront
- Stateless backend APIs
- DynamoDB partitioning for horizontal scaling
- Shared authentication across multiple games
- Centralized game registry
- Generic data models that are not tied to a specific game
Adding another game should primarily involve:
- Registering the game in the Games table
- Uploading the WebGL build
- Defining how its competitive metrics are interpreted
The existing player identities, statistics, and profile systems can then be reused without modification.
Challenges
Building Gridzo required solving several integration challenges.
The biggest was establishing reliable communication between Unity WebGL and the React application. Creating a JavaScript bridge that allowed asynchronous communication between Unity and Next.js took several iterations.
Deploying Unity assets separately from the frontend also introduced challenges around CORS configuration, CloudFront caching, and browser security policies.
Designing a database schema that works for multiple future games instead of only Sky City Rush also required several revisions before arriving at a more generic platform-oriented model.
Finally, balancing gameplay responsiveness with backend persistence was important. Race submissions needed to feel instantaneous while still updating competitive rankings reliably.
Future roadmap
Gridzo is intended to become more than a single-game platform.
Future work includes:
- Self-service developer onboarding
- Multi-game leaderboards
- Game-specific profile pages
- Ghost sharing between players
- Competitive tournaments
- Seasonal rankings
- Cross-game achievements
- Player matchmaking
- REST APIs and SDKs for third-party developers
The long-term goal is to allow developers to publish competitive games on Gridzo while sharing a common player ecosystem.
Conclusion
Gridzo started as an experiment in building competitive infrastructure that could outlive a single game.
Sky City Rush – Competitive demonstrates that vision by combining Unity WebGL, Next.js, Firebase Authentication, DynamoDB, CloudFront, and Vercel into a unified gaming platform.
While there is still plenty of work ahead, the project establishes a strong foundation for a future where independent developers can build games on top of a shared competitive platform instead of rebuilding the same backend systems every time.
If this hackathon marks the beginning of Gridzo's journey, I hope many more games will eventually join the platform.
Thanks for reading! This article was created as part of my submission for the **H0 Hackathon.
#H0Hackathon