Gamecoding: from idea to your own game with ChatGPT, Claude, and Gemini

Which AI to choose for game creation

First, let's divide things into three parts. Model generates responses; agent or environment allows it to read files, modify the project, and run checks; game engine or library renders the scene and processes the game. Therefore, comparing Cursor and Gemini as two identical "engines" is incorrect. We are choosing a workflow.

Capabilities below are aligned with official documentation as of October 20, 2026. Recommendations are editorial choices for specific scenarios, not the result of a model competition on a single test. Available features and limits depend on your account and plan.

Primary sources: OpenAI: browser games, Claude Code, Claude Artifacts, Google AI Studio Build, Cursor Agent.

Three working combinations

• First project: one available chat, one HTML file, simple shapes instead of a graphics package. Ask for the full file and verify every version.
• Project with development: Codex, Claude Code, or Cursor in a Git folder. One agent makes changes, and you accept the work based on specific criteria.
• There are several AIs: one main tool implements, another looks for weaknesses in rules and checks. Pass the current files and brief to the second model. Matching two answers is not proof of correctness.

Do not switch tools after every failed request. First, clarify the problem and provide the necessary context. A new chat without the current code often "fixes" a version that no longer exists.

1. Idea: one action, one obstacle, one reason to repeat

For an end-to-end example, let's take "Night Courier": the player moves between three lanes, collects fireflies, and avoids puddles for 60 seconds. This is an editorial concept for training, not a finished competition entry. The initial numbers below are hypotheses for testing, not "ideal balance."

The core action is changing lanes in time. The decision is whether to risk it for a firefly or stay safe. A retry is a chance to beat your score. Such a short cycle is easier to complete than an open world with trading, plot, and multiplayer.

Help design a small 2D browser game "Night Courier". The player switches between one of three lanes, collects fireflies, and avoids puddles. A round lasts 60 seconds; three mistakes end the attempt. Do NOT write code yet. Describe the goal, controls, scoring, and the start and end of a round. Suggest one interesting dilemma and three risks of boring or unfair gameplay. Shrink the concept to its smallest playable version. No accounts, no network, no shop, and no external APIs. Provide five verifiable readiness criteria.

What should remain after the step: a short brief with rules and boundaries. If you cannot explain the game in one sentence, it is too early to ask the AI to write hundreds of lines of code.

2. Beginner's Path: the first game in one HTML

Ask for plain HTML with embedded CSS and JavaScript. For this small game, Canvas—a surface on which the browser draws the scene—is sufficient. This is our choice for a simple start: fewer files and dependencies that could get lost. This doesn't mean that any large game should be built in a single file.

Implement a consistent "Night Courier" in a single index.html file: HTML, CSS, JavaScript, and Canvas without libraries or external resources. Three lanes. Controls: arrows or A/D, on mobile—large on-screen buttons. One press switches exactly one lane. The character does not go out of bounds. A firefly gives 1 point and disappears; a puddle takes 1 life only once. Start with 3 lives. The round ends after 60 seconds or after losing all lives. Do not create an impassable wall of obstacles. Add a start with an explanation, a pause, a result, and a "Try Again" button. Restarting resets all objects, score, time, and pressed keys. If focus is lost, the game pauses. Initially, use only simple shapes, no music or decor. All text must be in Ukrainian. The game must work autonomously in a sandbox iframe without allow-same-origin: no localStorage, cookies, fetch, CDN, workers, API keys, or a server. Provide the full file for download. If you can run it—verify the start, loss, time expiration, and three restarts. Clearly separate completed checks from recommended ones.

Download the file. If the service only shows code, ask to generate a file; a fallback is to copy the full generated text into a plain text editor and save it as index.html in UTF-8. Make sure the filename does not end in .html.txt. Open it in a browser. For this self-contained version, a local server is not required.

Go through the entire round and intentionally lose. If only a pretty menu works, the step is not complete. Save a working copy, for example, game-v01.html. Only then add the next capability.

3. Developer's Path: agent, repository, and change control

If you are already working with projects, start with a repository. For multiple scenes, sprites, and collisions, you can use Phaser — a library for browser-based 2D games. Its tutorial example shows resource loading, scenes, and interaction. Fix a specific version: an example from a different version's documentation might not match your API.

Separate game rules, controls, and drawing. For "Courier", the state contains the lane, lives, score, objects, and remaining time. Changing the appearance should not change the scoring. Transitions menu → playing → paused → finished must be explicit; restarting creates a clean state.

Read the current project and the "Night Courier" brief. First, propose a plan, module boundaries, and run/build commands. Record the agreed rules in a project instruction file. Work in small, completed increments. Do not add packages without explaining the need. Separate state, input, and rendering. Speed must not depend on the frame rate; prevent simulation jumps when returning from a background tab. Verify invariants: a collected item gives a score once; a completed round does not change the score; a restart does not duplicate listeners or the game loop. End each change with a report: what was changed, how it was verified, and what was not verified. Prepare a static web build with local assets and relative paths for our sandbox iframe. No external APIs or servers during gameplay.

Useful checks here — scoring rules, single collision, state reset. A visual test is needed separately: an automated number check won't show if a button overlaps the player. Before a major change, save a working version in Git; afterwards, review the diff and play through the same scenario.

There is a special condition for the Vibe Jam: all custom code is written and fixed by AI. An experienced participant can plan, verify, give precise tasks, and run the build, but manual code edits do not fit the competition format. This is a rule of our event, not a general definition of AI development.

4. From "it works" to "I want to play again"

Ask a friend to play without your explanations. See if they understand the goal, notice collisions, and find the restart button. The question "was it okay?" helps little. Better: "At what point did it become unclear?" or "Why did you lose?"

In "Courier," change only one thing at a time: the distance between obstacles, the speed, or the penalty cost. If you add acceleration, new enemies, and bonuses all at once, it will be hard to understand what improved the game feel.

• Action must have a response: a short flash or sound upon collection, a visible loss of life upon collision.
• Defeat must have a reason: the obstacle is readable in advance; random generation leaves a chance to avoid the hit.
• Controls must be predictable: the button triggers once, the finger doesn't block a danger zone, and the page doesn't scroll instead of playing the game.
• The replay must start quickly: after completion, the score and one clear button are visible.

Formulate edits as observations: "After pressing right, the hero sometimes jumps two lanes instead of one" is more useful than "make the controls feel better." Adjust difficulty, round length, and distances through gameplay, not through the authoritative tone of an AI response.

5. Graphics and sound: where generators truly help

An image generator is convenient for backgrounds, covers, portraits, or initial sprite variants. But a beautiful illustration is not yet a finished animation: frames may differ in size, pose, or anchor point. For a first game, simple geometric objects are often more reliable.

First, define the art direction: top-down camera, dark blue background, amber useful items, blue hero, consistent outline thickness. Create one control asset, insert it into the game, and check readability at real size. Only then order the rest of the set.

Create one 2D firefly sprite for a top-down camera game. Amber glow, dark sharp outline, simple recognizable shape, object center in the center of the frame. Transparent background, no text, frames, ground shadows, or extraneous objects. In-game, the resource will be displayed at approximately 32×32 pixels, so it must be readable without fine details. This is a single static sprite, not an animation sheet.

Check actual transparency, cropping, and file size. Reducing the image size on screen does not reduce the download size. Ask the agent to optimize resources and place them in the build folder, rather than using temporary chat links.

Add sound after the mechanics: a short collection signal and a completion signal, with a separate mute button. Ask to start audio after player action and verify this in the target browser. For generated or downloaded resources, save the source and terms of use. Do not use famous characters or music just because the service allowed them to be generated.

6. How to fix a game with AI when "everything is broken"

Do not ask to rewrite the entire game after every crash. Revert to the last working version or localize the problem. Provide the current file, sequence of actions, expected result, and actual result. If there is a console error, copy it verbatim along with the browser name.

There is a bug in the attached current version. Steps: start round → lose all lives → press "Try Again" → move right. Expected: a new round with three lives and initial speed. Actual: the game speeds up after every restart. Find the cause in this file. Check for duplicate game loops, timers, and listeners. Make the smallest possible fix; do not change the design or rules. Repeat three restarts and explain which checks you actually performed. If running the game is not possible, provide an exact manual testing scenario.

For more complex projects, it is useful to have a separate review of the code created by the agent. Ask for a list of reproducible defects with consequences, rather than general approval. The final check is the game's behavior.

7. Ready build and participation in the Vibe Jam

In our AI browser game contest, you can show your results and play others' works. Participation is free, the announced prize is 500 UAH. See exact dates, current stage, and full rules in the hub: after the submission period ends, this mini-course will remain as a learning path.

The platform accepts standalone HTML up to 2 MiB or ZIP up to 20 MiB. For ZIP, an index.html index.html is required in the root, up to 200 files and up to 40 MiB after extraction. Files must be browser-ready. A repository archive with source files and "run npm" instructions does not replace a web build.

In a project with a build tool, ask the agent to run a consistent command and package the contents of the ready folder with all resources. The final launch occurs in a sandboxed window: no backend, external CDNs, API keys, or network services. If you added an AI character that calls an API every time, you must rework this mechanic to be autonomous for this competition.

Pre-submission checklist

• It is clear from the first screen what to do and how to control it.
• Start, win or finish, loss, pause, and three restarts work.
• The score does not change after the round ends; no double counting.
• Tested specifically on the devices you specify in the application; for phones — a real touchscreen.
• The final file launches in the competition preview; all images and sounds are in place.
• The title, short description, and controls match the actual game.
• The cover shows the game: an automatic frame or your own screenshot if capture failed.

On the "Add Game" tab, log in via email with a confirmation code or via ChatGPT, drag an HTML or ZIP into the window, or select a file. Test the game, fill in the details, and submit for moderation. One participant can add several different games via "My Games" → "Add another game". Each undergoes verification and participates separately.

Once voting opens, there is one vote per account per round, regardless of the number of your own works. You cannot vote for any of your own games. Statistics display is controlled by the organizer. Always check the hub rules for details and current status.

Frequently asked questions about making games with AI

Is it possible to make a game without programming knowledge?

You can start with a small game and ask the AI to generate all the code. At the same time, you will have to learn how to save files, describe defects, and verify the result. The larger the project, the more valuable understanding the state, events, and code structure becomes.

Which AI writes games best?

This material does not establish a universal winner. Choose an available tool and give it one clear brief. Evaluate the full cycle: can you get the files, find an error, fix it, and assemble a working game? The appeal of the first screenshot is only one part.

Is a paid subscription required?

To start, check the capabilities of your current account. Free tiers may have limitations, and long sessions might hit a quota. Purchasing multiple subscriptions is not a requirement of the competition. Compare costs after your own small test, not before it.

Must the finished game use AI during gameplay?

No. AI can help create code and resources, and the result will run as standard JavaScript. For our competition, this is a useful separation: you develop with AI, but play autonomously without requests to the model.

Can I just submit a link to an artifact or AI Studio?

This Vibe Jam requires a ready HTML or ZIP file that passes verification in the hub. A link to a third-party service prototype does not replace the file.

Sources and limits of the material

Product capabilities have been verified via the official pages listed under the table; the technical example of the library is based on Phaser documentation. Competition terms have been cross-referenced with the current implementation and Vibe Jam rules. Verification date — 20.10.2026.

"Night Courier," prompts, workflow, and test scenarios — editorial proprietary training materials. We do not present them as a comparative test of all services or a ready-to-use verified game. The generation result depends on the model, available tools, context, and your own verification.