How do you start to vibe code a game?

In this series of posts, I am sharing my experience creating a game from absolute zero as a non-developer and non-designer. In the introductory post, I covered why I picked a game for this experiment. Today, we'll go through the first steps of the process: selecting and setting up the key tools.

As someone who is generally enthusiastic about video games, I've heard about game engines. Most modern games are made using Unreal Engine, Unity or proprietary engines that only big studios can afford to develop. Being the smallest of all possible studios (just me), I knew I needed a game engine. But which one?

Key early decisions

The game engine should be selected depending on the type and complexity of the game you want to create. Moreover, before committing to one, you need to understand how it is offered: licence, usage costs, attribution and other legal aspects all need to be considered. If you don't do that, you run the risk of pouring hours of work into your project only to discover later that you need to start all over again.

The second major consideration is picking tools that work well together.

Because I was already paying for ChatGPT Plus, my main agentic coding tool was Codex. So I needed to find a game engine that Codex could interact with to build my game and test its own work.

Testing is an absolutely crucial bit that should be addressed before you start building. Even if you plan to test your game by hand, you still want your coding tool to be able to test and debug alongside you. This alone will save you tons of time and frustrating iterations where it feels like you're going in circles.

So how did I select my game engine?

I asked ChatGPT.

I described, exhaustively, what kind of game I wanted to create. This included:

• Platforms I wanted to support: mobile, desktop, web, consoles
• Types of input the game needed: touch, gamepad, mouse and keyboard
• Visual style: 2D, isometric, 3D
• Genre: action, puzzle, strategy, RPG, simulator, etc. - important for understanding the physics and rendering capabilities you need
• Assets: whether you plan to supply your own art or create assets inside the game engine
• Distribution, business model and update policy - all of which might impact engine selection considerably

What did I ask ChatGPT?

After describing my game concept, I asked it to find at least three game engines that could power my game.

Why three? Because you can only really make a choice if you have options.
For every option, I asked ChatGPT to list:

1. Pros and cons in relation to my specific game
2. A few examples of similar games made with that engine
3. The top five most commonly cited criticisms or issues
4. Costs, licences and tool integration information

Additionally, I asked it to filter out engines Codex couldn't work with effectively and sort the remaining options by cost versus overall fit for my game.

That's how I learned about the existence of a game engine called Godot.

Compared with alternatives such as Unity, it emerged as a clear winner for my needs, the tools I was using and the budget I had. Godot is completely free, which feels like fantastic charity considering what cool games you can make with it.

Setting up the rest of the tools

With my engine selected, I moved on to the supporting tools.
First, of course, the coding agent: Codex.

It doesn't require much configuration except for one important thing: you absolutely want to run it locally rather than purely in the cloud.

The difference is enormous when Codex can test the code, read logs and use other related tools installed on your development machine. Setting everything up locally might take a bit of effort, especially if you've never previously set up a development environment.

You have two general approaches:

• Set everything up yourself following a guide. There are plenty of free courses available, or you can always ask genAI to guide you through it.
• Install Codex, give it enough context and permissions, and ask it to help set up the environment for you.

It's generally much easier on Mac or Linux and a bit more annoying on Windows.

Another key tool you need for game development, assuming you don't want to build absolutely everything inside the engine, is a design tool for custom assets.

Selecting one is similar to selecting a game engine: you need to consider the type of game you're creating, the complexity of its assets, how your engine imports them and which formats it accepts.

I did a bit of tool jumping until it became clear that, for my needs, Canva was the perfect choice. I love Canva and believe it to be one of the best entry-level design tools for non-designers.

Last but not least, you might want an IDE to manage your source code.

For me, an IDE was essential because I wanted to learn how Codex was building my game, understand the architecture and eventually manage some functionality directly in the code.

I had some experience with VS Code before, so I tried a few VS Code-based IDEs and chose Google Antigravity. Mainly because, together with the IDE, it also offered some agentic coding capabilities, with super-small limits on the free plan, which could be useful for simple tasks I didn't necessarily want to bother Codex with.

Project setup and documentation

Before giving Codex its first implementation tasks, you need to set up the project and create context.

Yes, unfortunately, simply writing: "Create me the coolest game. Make no mistakes."
will not cut it. I know - a shocker! Feel free to stop reading here and go play games instead of creating them. 

Still here? Cool! Back to docs. As a minimum, I'd recommend creating the following documents:

• Game overview: your game idea, major gameplay mechanics, guidance on visual style and key features
• Technical architecture: ask genAI to create this with you; it should cover the major game services needed, platform-specific requirements and other important technical decisions
• MVP scope: your defined minimum playable version of the game. And it should be really minimal: one level, one room, one boss, one scene. At this stage, less complexity is almost always better

And please learn about Documentation-Driven Development or Specification-Driven Development.

I didn't.

And I paid for that with extra effort, time and frustration.

Once you have the fundamental docs, you can move to scaffolding. This is where Codex starts becoming genuinely useful.

Start in planning mode. Let Codex read your docs and create a step-by-step plan for implementing the MVP.

One important note: if you're asking Codex to scaffold the project, be extra vigilant about the tools and dependency versions it chooses.

I've encountered a strange Codex quirk where, on a few occasions, it selected tools several major versions behind the latest stable releases. It probably won't make or break your project, but having to upgrade half of your tech stack while you're still building the MVP is deeply annoying and very avoidable.

MVP implementation

Finally, we arrive at the most exciting part: the first prototype of your game.

I am using the word prototype intentionally because you should be emotionally ready to throw it away if it doesn't meet your expectations.

The product creation process is never linear. For every step forward, you often need to take a few steps sideways, then one backwards, then somehow diagonally.

Even more so with games.

Unlike, say, business software that exists to solve a fairly concrete customer problem and is mostly judged on how well it solves it, games are picked based on... vibes.

People choose games using emotional reasoning first. Only afterwards do practicalities come into play: price, platform support, length and so on.

So during game development, and especially solo game development, your taste and judgement become incredibly important. You need to decide whether the MVP deserves another iteration or whether the whole thing should be discarded and rebuilt.

A few practical tips from my MVP implementation:

Don't ask Codex to implement everything at once. This will likely lead to mistakes, lost context and considerably more credit usage than necessary. Instead, give Codex one to three tasks in a single chat together with links to the relevant documentation.

I wouldn't bother with extensive test coverage for the MVP. Your definitions are very likely to change, which means your tests will need to change with them. Test the important stuff, but don't build a cathedral around something you might demolish tomorrow.

Give Codex visual references. Don't ask it to make the game pixel-perfect, but do provide some guidance on what you want the MVP to look like. For the first MVP, I'd let it live almost entirely inside the game engine and use mostly engine-generated or placeholder assets.

Best case: you like it.

Good case: you understand exactly what custom assets you're missing.

Both are useful outcomes.

You don't need to export the project just to test it. Most game engines support previews, so you can play your game inside the engine instead of installing it on a device after every change. If you specifically want to understand how the game feels on the destination device, Codex can help there too. It can work with tools such as Android Studio and Xcode to build and run the game on a testing device or emulator.

Finally, don't be discouraged by the first thing you see.

First versions are always ugly. That's the point.

Product creation is a thinking process first and foremost. You have an idea. Maybe you even have a picture in your head of exactly how it should work. Then you see the actual thing and realise you don't like it.

So you refine it.

You try a few side paths.

It gets better.

Then you repeat that process x number of times and eventually... somehow, there is a game.