Kid Goku: Beyond the Clouds — Inside the Dragon Ball Runner Built With AI

Key Takeaways

• Kid Goku: Beyond the Clouds is an unofficial Dragon Ball browser game featuring a run through Mount Paozu.
• Creator Aniket J credits Claude Opus 5.5, Crayon and Three.js in his announcement. This is a creator-reported technology stack, not an independently audited build.
• The listed controls cover movement, jumping, the Power Pole and Flying Nimbus.
• The project offers a useful case study in AI-assisted game development, but public material does not establish its production cost, development time or cross-device performance.

What Is Kid Goku: Beyond the Clouds?

Kid Goku: Beyond the Clouds is a Dragon Ball fan runner published on Crayon. Its description follows young Goku through Mount Paozu, with Flying Nimbus travel, Power Pole-assisted gorge crossings and dinosaur hazards. The listing explicitly identifies it as an unofficial fan game.

In the original announcement, Aniket describes the project as a tribute to the first Dragon Ball episode at Mount Paozu and credits Opus 5.5, Crayon and Three.js. He also names Dragon Ball Super: Beerus as the inspiration for returning to a fan runner project.

The interesting design choice is the emphasis on traversal. A runner gives familiar character abilities a practical purpose: the player must read the route and choose how to move through it. That creates a clearer foundation for a small browser game than attempting to reproduce an entire fighting game or open-world adventure.

How to Play: Controls and Getting Started

The published instructions list these controls:

These are listing-based instructions; they do not establish that every action works reliably on every device.

Open the game page directly and read any instructions shown by the current build. For a first attempt, learn basic steering and jumping before combining movement with special abilities. Check on-screen prompts rather than assuming that an ability is always available or has unlimited use.

A complete playthrough and consistent desktop/mobile performance have not been independently established for this article. The available evidence supports an introduction to the project, rather than a scored gameplay review.

If the game remains on a loading screen, try the direct page in a current desktop browser and reload once. Persistent failure should be treated as a compatibility or delivery issue to investigate—not evidence that a particular graphics setting will fix it.

Who Created the Game?

Aniket Jatav is a co-founder of Crayon. In a July 2026 interview, he describes a background spanning engineering, design and visual arts. Co-founder Tushar Sharma brings traditional game-development experience, including work on AAA titles.

That relationship matters when interpreting the demonstration. A platform founder can use a game both as a creative project and as a showcase for the tool behind it. The result is worth studying, while the creator's familiarity with the platform makes it an imperfect predictor of a beginner's first attempt.

A useful evaluation therefore asks two separate questions: does the game communicate an appealing experience, and can another developer reproduce a similarly polished result within a reasonable budget?

How Opus 5.5, Crayon and Three.js Fit Together

The announced stack contains three different layers. Their likely division of work is outlined below; the precise allocation inside this project has not been disclosed.

Crayon's documented capabilities include a planning-based build process, chat editing, asset and level editors, code view and version history. Its interface also advertises plain-language asset changes and publication to its Arcade.

Three.js supplies rendering primitives. Its official scene tutorial explains how a scene, camera and renderer work together, with an animation loop updating the display.

This distinction prevents a common misunderstanding: crediting an AI model during development does not establish that the model generates every frame while someone plays. Nor does the announced stack reveal whether the game makes any AI requests at runtime. Answering that would require implementation or network evidence.

What Crayon Adds to AI-Assisted Game Development

In the founder interview, Jatav describes an approximately 15-step process that routes work across multiple models. Specialized agents handle areas such as asset structure, coloring, textures and materials. He also describes clarification and planning before construction, and says detailed game design documents tend to produce stronger results. These are the founder's descriptions of the platform architecture, not a published trace of this game's build.

The practical value of that approach is coordination. A playable runner needs more than code that draws a character:

• Movement must agree with animation timing.
• Camera framing must leave enough room to anticipate obstacles.
• Collision boundaries must feel consistent with visible objects.
• Ability prompts must appear before the player needs them.
• Restarting must reset gameplay state cleanly.

A workflow that separates these tasks can make iteration easier to direct. However, dividing work among agents does not prove that their outputs fit together. Integration testing remains essential.

For example, a visually convincing pole-vault animation is insufficient if the character's collision body reaches the landing platform too early or too late. The developer still needs to evaluate the interaction as a complete sequence.

Why a Runner Is a Useful AI Game-Development Case Study

A runner offers a relatively compact set of player decisions while leaving room for strong visual identity. This makes it a practical format for studying how generated code, assets and level design interact.

The central development advantage is a narrow gameplay loop. A small prototype can begin with forward movement, lateral control, one obstacle and a restart button. Additional abilities can then be introduced individually.

That structure also makes problems easier to isolate. If ordinary jumps work but a special traversal move fails, the investigation can focus on the ability's activation conditions, trajectory and landing behavior.

The format still has demanding edge cases:

These are evaluation criteria for this genre, not claims that specific defects have been found in Kid Goku.

What the Demonstration Proves—and What It Does Not

The public announcement and game listing establish a named project, a published destination and the creator's account of the tools used. They do not establish a general benchmark for AI game production.

The reviewed material does not disclose:

• Total development time, including revisions and manual work.
• Total generation cost or credits consumed.
• The complete source code and prompt history needed to reproduce the result.
• Device-level performance measurements, including loading time and frame-time stability.
• Retention or revenue data demonstrating an ongoing game business.

Social attention and gameplay quality should also be assessed separately. A striking clip can communicate a concept quickly, but it cannot establish reliable controls, fair difficulty or an enjoyable tenth play session.

For anyone evaluating a similar project, a useful measurement sequence is: visits to the game page, successful loads, first meaningful input, first completed attempt and voluntary replay. Each stage reveals a different problem. A large audience is of limited practical value if players never reach the first controllable moment.

Crayon Pricing and Export Considerations

Crayon's terms effective September 30, 2026 list the following allowances:

Subscription credits do not roll over. Paid plans include export, although availability can depend on game type. Confirm current pricing in the application before purchasing. These figures do not reveal what this game cost to make.

The Crayon homepage advertises self-hosting and export for portals including Poki and CrazyGames. Treat that as a distribution capability to evaluate, rather than a promise that a portal will accept a particular submission.

How to Apply the Lessons to an Original Game

Developers can explore the same traversal ideas using an original character and setting. Start with one playable section, then expand only after the interaction feels coherent.

An example brief could be:

Create an original third-person browser runner set on floating garden paths.

Build one short level first.
Use an original courier character with a spring staff and a leaf glider.
Support keyboard movement, jumping and equivalent touch buttons.
Introduce ordinary jumps before staff-assisted gaps and gliding sections.
Make obstacles visible before the player must react.
Include a clear failure state, pause control and immediate restart.
Keep movement, collision rules and presentation code separate.
Do not add more levels until the first level is reliably playable.

This is an illustrative design brief, not the prompt used for Kid Goku or a guarantee of a particular generated result.

A productive iteration order is:

1. Validate movement with simple geometry. Attractive assets can conceal poor collision or timing decisions.
2. Add one ability at a time. Define when it activates, when it ends and what happens if it is interrupted.
3. Test repeated attempts. Restart bugs often become apparent only after several failures.
4. Replace placeholders while preserving readability. Decoration should not obscure hazards or landing zones.
5. Test the intended delivery environment. Check loading, input and layout on the devices players will actually use.

Fan-Game Status and Website Embedding

Crayon's terms make commercial use subject to third-party rights and place responsibility for submitted and generated content on the creator. Its output provisions should not be interpreted as permission to commercialize Dragon Ball characters or assets.

For a separately operated game, original characters, artwork, audio and branding provide a clearer foundation for development and distribution.

The public play URL is also not a verified iframe embed endpoint. Third-party embedding support has not been established here. Publishers can link readers to the game page; an embedded version should be tested and its distribution permissions confirmed before publication.

Conclusion

Kid Goku: Beyond the Clouds offers a concrete example of how a familiar fictional setting can become an AI-assisted browser-game project. Its value as a development case study lies in the combination of a focused gameplay idea, specialized abilities and a workflow that connects generation with editing and publication.

The strongest takeaway is practical: evaluate the complete player experience, including loading, controls, readability and replay, alongside the visual demonstration.

Explore the published game page, review the creator's announcement, and use the design lessons to plan a small original prototype.