{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibm4ht754twmbtyrljjmlu5fjkhvwlh7dec3stuyiedya6tc32ztm",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpdikl7dxcv2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiedqzvifblefosmwubautrxaurnufcasf5gcj3yc7e5le7zppyeaq"
    },
    "mimeType": "image/webp",
    "size": 82374
  },
  "path": "/amirated/building-gridzo-a-scalable-competitive-gaming-platform-with-unity-webgl-nextjs-and-dynamodb-4p24",
  "publishedAt": "2026-06-28T07:35:09.000Z",
  "site": "https://dev.to",
  "tags": [
    "webgl",
    "nextjs",
    "aws",
    "vercel"
  ],
  "textContent": "#  Building Gridzo: A Scalable Competitive Gaming Platform with Unity WebGL, Next.js and DynamoDB\n\n> **This article was created as part of my submission for the H0 Hackathon.**\n\n##  Introduction\n\nMost 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.\n\nThat idea became **Gridzo**.\n\nGridzo 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.\n\nRather than building a website around a game, I built a platform around competitive gaming.\n\n##  Why I built Gridzo\n\nAs I continued developing games, I noticed that every multiplayer or competitive title required solving the same set of backend problems:\n\n  * User authentication\n  * Player profiles\n  * Leaderboards\n  * Match history\n  * Statistics\n  * Persistent storage\n  * Deployment\n\n\n\nThese systems rarely depend on the gameplay itself.\n\nI wanted to separate the **competitive platform** from the **games**.\n\nThat led to Gridzo—a platform where each game focuses on gameplay while Gridzo provides the competitive ecosystem.\n\nSky City Rush became the first proof-of-concept demonstrating this architecture.\n\n##  The problem with game-specific competitive systems\n\nTraditional online games tightly couple gameplay with backend services.\n\n\n\n    Game\n     ├── Authentication\n     ├── Profiles\n     ├── Leaderboards\n     ├── Statistics\n     ├── Rankings\n     └── Match History\n\n\nThis works for one title but becomes increasingly difficult to maintain as additional games are introduced.\n\nGridzo instead follows a platform approach.\n\n\n\n                Gridzo Platform\n             ┌────────────────────┐\n             │ Authentication      │\n             │ Player Profiles     │\n             │ Leaderboards         │\n             │ Statistics           │\n             │ Game Registry        │\n             └────────────────────┘\n                     ▲\n            ┌────────┼─────────┐\n            │                  │\n    Sky City Rush        Future Games\n\n\nEvery game shares the same identity and competitive systems while remaining independent in terms of gameplay.\n\n##  Architecture overview\n\nThe frontend is built with **Next.js** and deployed on **Vercel**.\n\nThe racing experience is developed in **Unity** and exported as a **WebGL** application hosted on **Amazon S3** and delivered globally through **Amazon CloudFront**.\n\nPlayer authentication is handled using **Firebase Authentication** , while all persistent game data is stored in **Amazon DynamoDB**.\n\nThe communication flow looks like this:\n\n\n\n    Player\n\n    ↓\n\n    gridzo.loen.in\n\n    ↓\n\n    Amazon Route53\n\n    ↓\n\n    Amazon CloudFront\n\n    ↓\n\n    Vercel (Next.js)\n\n    ↓\n\n    Unity WebGL\n\n    ↓\n\n    Race Result\n\n    ↓\n\n    Next.js API\n\n    ↓\n\n    Amazon DynamoDB\n\n\nThis architecture cleanly separates gameplay from backend services while allowing both to evolve independently.\n\n##  Unity ↔ Next.js communication\n\nOne of the most interesting technical challenges was enabling communication between Unity WebGL and the Next.js application.\n\nWhen a player finishes a race:\n\n  1. Unity collects the race data.\n  2. A JavaScript bridge exposes browser functions to Unity.\n  3. Unity submits the race result to the Next.js API.\n  4. The backend validates and stores the run.\n  5. Updated competitive information (such as leaderboard rank and personal best) is sent back into Unity.\n  6. Unity displays an in-game result screen.\n\n\n\nThis creates a seamless experience where the player never leaves the game while all competitive logic is handled by the web application.\n\n##  DynamoDB data model\n\nInstead of storing game-specific information, the database is designed around reusable platform concepts.\n\nSome of the primary tables include:\n\n  * **Players** — Global player identities\n  * **PlayerProfiles** — Shared profile information\n  * **Games** — Registry of games available on Gridzo\n  * **GameRuns** — Every competitive run submitted by players\n  * **Usernames** — Username lookup and uniqueness\n\n\n\nA single **GameRuns** table serves as the source of truth for competitive data.\n\nLeaderboards, 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.\n\n##  Scalability considerations\n\nAlthough Gridzo currently hosts only one game, it was designed with future growth in mind.\n\nSeveral architectural decisions contribute to scalability:\n\n  * Independent hosting for the web application and Unity assets\n  * Global asset delivery using CloudFront\n  * Stateless backend APIs\n  * DynamoDB partitioning for horizontal scaling\n  * Shared authentication across multiple games\n  * Centralized game registry\n  * Generic data models that are not tied to a specific game\n\n\n\nAdding another game should primarily involve:\n\n  * Registering the game in the **Games** table\n  * Uploading the WebGL build\n  * Defining how its competitive metrics are interpreted\n\n\n\nThe existing player identities, statistics, and profile systems can then be reused without modification.\n\n##  Challenges\n\nBuilding Gridzo required solving several integration challenges.\n\nThe 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.\n\nDeploying Unity assets separately from the frontend also introduced challenges around CORS configuration, CloudFront caching, and browser security policies.\n\nDesigning 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.\n\nFinally, balancing gameplay responsiveness with backend persistence was important. Race submissions needed to feel instantaneous while still updating competitive rankings reliably.\n\n##  Future roadmap\n\nGridzo is intended to become more than a single-game platform.\n\nFuture work includes:\n\n  * Self-service developer onboarding\n  * Multi-game leaderboards\n  * Game-specific profile pages\n  * Ghost sharing between players\n  * Competitive tournaments\n  * Seasonal rankings\n  * Cross-game achievements\n  * Player matchmaking\n  * REST APIs and SDKs for third-party developers\n\n\n\nThe long-term goal is to allow developers to publish competitive games on Gridzo while sharing a common player ecosystem.\n\n##  Conclusion\n\nGridzo started as an experiment in building competitive infrastructure that could outlive a single game.\n\nSky City Rush – Competitive demonstrates that vision by combining Unity WebGL, Next.js, Firebase Authentication, DynamoDB, CloudFront, and Vercel into a unified gaming platform.\n\nWhile 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.\n\nIf this hackathon marks the beginning of Gridzo's journey, I hope many more games will eventually join the platform.\n\n_Thanks for reading! This article was created as part of my submission for the **H0 Hackathon_ _._\n\n**#H0Hackathon**",
  "title": "Building Gridzo: A Scalable Competitive Gaming Platform with Unity WebGL, Next.js and DynamoDB"
}