FORGA — Building an AI-Powered 3D Creation Platform from 0→1

My Role as Founding Engineer

• Founding Engineer: translated the early concept into a working product and owned the technical direction as its scope evolved
• Lead Unity Engineer: owned the Unity WebGL application and core interactive systems
• Technical Architect: mapped the prompt-to-asset and prompt-to-gameplay workflows and helped define the contracts between the WebGL client, AI services, storage, and backend
• AI Gameplay Systems Developer: built the RAG layer that generated Jint-compatible code components inside the running application
• Gameplay and Systems Developer: built the browser editor, racing loop, tournament features, and telemetry-based anti-cheat
• Collaborated with the product, AI, backend, design, and QA stakeholders throughout rapid milestone-based delivery

The Challenge: Turning AI Assets Into Playable 3D Worlds

Generating a mesh was only one part of the problem. A useful AI creation platform also had to manage asynchronous jobs, store generated content, explain failures, preview imperfect assets, and let people turn those assets into something playable.

The browser added another constraint. Unity WebGL had to coordinate several cloud services while staying responsive under tight memory, loading, and code-stripping limits. Later, when the product added competitive racing and paid tournament entry, generated content also had to coexist with persistent accounts, transactions, results, and credible race validation.

What I Built for FORGA

AI-to-3D Pipeline and Asset Library

I integrated a multi-stage creation flow into Unity WebGL. A user could enter a prompt, review generated image concepts, select a direction, and submit it for 3D generation. The wider pipeline classified assets, generated metadata, handled humanoid rigging or mesh segmentation, and stored results in a persistent library.

The Unity client treated generation as an asynchronous job rather than a blocking request. It tracked task IDs, polled for progress, surfaced intermediate states, and recovered from service or browser failures. I also worked through CORS, API Gateway, storage, and model-loading issues during the earliest WebGL integration.

The supporting backend combined Supabase Auth, Postgres, Storage, and Deno Edge Functions with third-party generation services. I designed the Unity-side orchestration and helped shape the service architecture while working with the backend and AI engineers responsible for those services. That separation let the team change providers and generation models without rebuilding the product experience around a single API. It reflects the same principles I use when building game backends with Supabase.

Unity WebGL Level Editor

The prototype evolved from a model viewer into a practical browser editor. I built the systems needed to:

• Create, save, and reload scenes
• Browse generated assets and instantiate them into a level
• Select objects through a hierarchy and edit position, rotation, and scale
• Navigate with keyboard and mouse controls
• Undo and redo editing operations
• Generate assets from a prompt inside the editor

The aim was not to reproduce the full Unity Editor in a browser. It was to expose a smaller set of dependable tools that moved a user from an idea to a shareable scene with as little friction as possible.

Runtime Jint Code Generation With RAG

Generating a mesh did not make it playable. I designed and built a runtime code component system that let users describe gameplay behaviour in natural language, generate a reusable component, and attach it to an asset inside the editor. The selected GameObject and scene hierarchy were included as context so the generated behaviour could target the right objects instead of operating in isolation.

I built the retrieval-augmented generation infrastructure that enabled this workflow. At runtime, the RAG layer supplied the model with the context it needed to generate code components compatible with FORGA's Jint-based execution environment. Users could create new behaviours from a prompt while the application was running, instead of selecting only from a fixed library of precompiled components.

Unity WebGL cannot dynamically compile arbitrary C# assemblies after deployment, so I integrated Jint, a JavaScript interpreter for .NET, as the execution layer. The RAG pipeline generated Jint-compatible JavaScript, which was evaluated immediately and connected to Unity through an API bridge. This allowed FORGA to create and run new gameplay behaviour without rebuilding the player for every component.

Movement and combat components became early reference implementations for the system. Together, runtime retrieval, code generation, Jint execution, and editor integration moved FORGA beyond AI-generated assets toward user-generated gameplay.

From Sandbox to Playable Racing Product

The scope later expanded into a racing experience that tested whether generated content could sit inside a complete game and economy loop. I led implementation of car generation and selection, race entry, wallet and transaction flows, Stripe deposits, tournaments, standings, leaderboards, and reward handling.

On the gameplay side, I added checkpoints, traffic behaviour, obstacles, damage and recovery, audio controls, and race-flow polish. I also optimized memory use and build behaviour so the experience remained viable in WebGL as the project grew.

This work extended the browser-based racing and live game systems I previously developed for RACINO.IO, while adding AI-generated vehicles and a transaction-backed tournament loop.

Telemetry-Based Race Verification

A competitive leaderboard needed more than a finish-time submission from the client. I implemented a two-stage anti-cheat system that recorded race inputs, speed, distance, and timing in Unity, compressed the telemetry, and uploaded it with a secured race session.

Server-side verification checked the session structure and compared each run against exported track geometry and vehicle physics limits. Acceleration, braking, cornering grip, distance, and finish-time plausibility were evaluated before a result could feed a verified leaderboard or tournament outcome.

This approach provided meaningful protection without the cost of running the entire physics simulation on an authoritative game server.

Key Technical Decisions

Design for Long-Running AI Jobs

Image and model generation could take seconds or minutes, fail independently, or return an asset that needed further processing. Task IDs, polling, explicit status transitions, and persisted intermediate results made the workflow observable and recoverable.

Show the User Useful Intermediate Results

The generated image was more than a loading step. It became a blueprint the user could review before paying the time and compute cost of 3D generation. That reduced blind retries and gave people more control over the result.

Treat Generated Assets as Untrusted Content

AI-generated meshes were not automatically game-ready. Scale, topology, materials, rigging, pivots, and performance could all vary. Preview, classification, segmentation, and metadata were necessary product features, not optional polish.

Validate Behaviour, Not Just the Final Score

For racing, a final time alone could not prove a run was legitimate. Recording the path to that result made validation more robust while keeping the WebGL client responsive and the server architecture practical.

Interpret Components Instead of Compiling Them

Traditional Unity gameplay code is compiled before a build ships, which conflicts with a product that creates new behaviour from a prompt. Using Jint separated generated gameplay logic from the compiled player and provided a runtime path that could work within the constraints of a browser build.

Outcome: An End-to-End AI Game Creation Prototype

FORGA progressed from a rapid WebGL demo into an end-to-end product prototype. It combined authentication, AI asset generation, persistent storage, an asset library, scene editing, RAG-powered generation of Jint code components at runtime, and a playable racing loop with tournaments and verified results.

I delivered optimized browser builds across successive milestones and completed a full technical handover of the codebase and backend access. Development paused before a public release, so I describe the work as a production-oriented prototype rather than a shipped platform.

The project reinforced a lesson that applies to most AI creation tools: calling a model is the easy part. The real product work is building the states, constraints, recovery paths, and editing tools that make uncertain outputs useful.