How to Write Your First Prompt for an AI Game (What the Makko Team Actually Does)
Three approaches from the Makko team on writing a first prompt that actually works. Jeremy, Tony, and Cesar each do it differently. Here is why.
The first prompt is where most people get stuck. You open a blank input field, you know what you want to build, and you type something like "make me a cyberpunk platformer." The AI returns something. It is not wrong, exactly. It is just not yours. The game it builds does not match the game in your head, and you are not sure what to change.
The problem is almost never the tool. It is the prompt. Vague input produces generic output, and the first prompt sets the direction for everything that follows. Get it right and every iteration builds toward something real. Get it wrong and you spend three sessions correcting drift instead of building.
The Makko team builds games in public every week using the same tools available to every creator on the platform. During a recent session, Cesar asked the team a direct question: how do you actually write your first prompt when starting a new game? Jeremy, Tony, and Cesar each gave a different answer. All three work. Understanding why each one works and when to use which is more useful than any single template.
Why the first prompt matters more than any prompt that follows
In prompt-based game creation, the AI does not just respond to individual requests in isolation. It builds on what already exists in the project. Every prompt after the first one is influenced by the decisions the first prompt locked in: the genre, the tone, the mechanical premise, the visual direction.
This is why a first prompt like "make a platformer" produces something so different from "make a fast-paced sci-fi platformer where the player is a courier diving into collapsing dimensions to recover fragments before the city loses them forever." Both are one sentence. The second one gives the AI a player fantasy, a setting, a core verb, and a reason for the gameplay loop to exist. That context does not just affect the first output. It carries through into every system the AI builds afterward.
Makko's core principle is that intent-driven game development starts with the creator, not the AI. The AI handles implementation. You handle direction. The first prompt is the clearest expression of your direction that exists in the project, and the AI will refer back to it for as long as you are building.
That is the pressure the first prompt is under. Here is how three people who build games with AI every week approach it.
The Makko philosophy: AI speed with human creative control
Before getting into the specific prompting approaches, it helps to understand the principle they all share. Jeremy, Makko's CEO, frames it this way: creators stay in control. You can start from a rough drawing, a one-line idea, or a design doc you wrote at 2am, and still land exactly where your vision needs to go. The AI is fast. You are the director.
That principle shapes every approach below. None of them are about typing less or getting the AI to do more. They are about communicating your intent precisely enough that the AI builds the right thing the first time, which means less correction later.
Jeremy's approach: structure the intent before you type
Jeremy's approach treats the first prompt like a brief, not a request. Before typing anything into the AI, he works out the answers to a small set of questions: what is the player doing, what is the core loop, what is the tone. Not as a formal document. Just as a clear internal picture. The prompt itself is the output of that thinking, not the start of it.
The practical effect is that his first prompt tends to be longer and more specific than most people write. Where a new creator might type "make a survival game," Jeremy might write something that specifies the survival mechanic, the win condition, the core tension, and the visual style in one structured paragraph. The AI gets enough context to make real decisions instead of defaulting to the most common version of the genre.
This approach works best when you already have a clear idea of what you want to build. If you have been thinking about a specific game concept for a while and you know what makes it different from everything else in the genre, writing a structured first prompt is fast because the thinking is already done. The prompt is just the transcription.
Where it runs into friction is when the idea is still forming. If you are exploring a genre rather than executing a specific concept, a highly structured first prompt can lock you into a direction before you know if it is the right one. For that situation, Tony's approach handles it better.
Tony's approach: copy something that already works, then adapt it
Tony, one of Makko's co-founders, takes a different starting point. His first prompt is almost never written from scratch. He starts by finding an existing prompt from a previous session, from a game he has already built, from a template that covers the genre he is working in, and adapts it to the new project. The structure is already proven. The only thing he changes is the content.
The logic is clear: if a prompt structure produced a working game loop once, it will probably produce a working game loop again. Writing a first prompt from scratch every time means rediscovering the same structural patterns repeatedly. Starting from something that already worked means you only have to solve the part that is actually new.
This approach is particularly useful when you are iterating on a genre you have built in before. If Tony already has a platformer prompt that generated a solid movement system and core loop, and he is building a new platformer with a different setting and mechanic, starting from that existing prompt and replacing the specifics is faster than building from scratch and produces a more structurally reliable result.
The thing to watch for with this approach is that adapted prompts can carry assumptions from the original project that do not fit the new one. If the original prompt had specific movement mechanics or progression systems baked in, and you do not consciously remove them, the AI may build those into the new project by default. Adaptation requires active reading, not just swapping the genre name.
Cesar's approach: describe what you want to say, not what you want to build
Cesar's approach is the most counterintuitive of the three and the one that tends to produce the most unexpected results. Instead of describing the game's systems or mechanics in the first prompt, he describes what the game should communicate to the player. Not "a platformer with dash mechanics and enemy waves" but something closer to "a game that makes the player feel like they are always one move away from either escape or disaster."
The reasoning is that what a game feels like and what a game is made of are two different descriptions of the same thing. Starting from the feeling rather than the components often produces a more coherent result. When the AI is working from a mechanical description, it assembles systems. When it is working from an experiential description, it tends to make decisions about those systems that serve the intended feeling rather than just satisfying the spec.
This approach works best when you have a strong intuition about how a game should feel but have not yet decided on the specific mechanics that will produce that feeling. It is also the approach most likely to surface unexpected solutions. The AI may propose a system you would not have specified directly but that turns out to be exactly right for the experience you described.
The tradeoff is precision. A feeling-first prompt gives the AI more interpretive latitude, which means more variance in the output. You may need more iteration passes to lock in the specific mechanics once the emotional direction is established. Cesar's approach often works best as a starting point that Jeremy's structured thinking then refines on the second or third prompt.
What all three approaches have in common
The approaches look different on the surface but they are all solving the same problem: how do you give the AI enough context to make decisions that serve your game instead of defaulting to the most generic version of whatever genre you named?
Jeremy solves it by thinking through the structure before typing. Tony solves it by starting from a structure that already worked. Cesar solves it by describing the experience instead of the components. All three are ways of providing richer context than "make me a [genre] game."
The other thing they share is that none of them treat the first prompt as the final word. In agentic AI game development, the first prompt is the starting point for a conversation, not a specification document the AI executes exactly. The goal of a good first prompt is not to get everything right. It is to give the AI enough to work with so the first output is close enough to iterate from rather than having to start over.
Three questions to answer before you type your first prompt
Across the three approaches, the same underlying questions appear in different forms. Answering these before opening a new project will make any first prompt stronger regardless of which approach you use.
What is the player's core action? Not the genre. The specific thing the player does moment to moment. "Run and jump" is a genre default. "Dive through collapsing dimensional fractures and extract fragments before the exit closes" is a core action. The more specific this is, the more the AI can build systems that serve it.
What should the player feel? This is Cesar's question, and it is worth asking even if you end up writing a structured prompt. A survival game where the player should feel clever and methodical produces different mechanics than a survival game where the player should feel constantly overwhelmed and reactive. Same genre, completely different design decisions.
What is the one thing that makes this game different? Every genre has defaults. Platformers have jumping, enemy clearing, and level progression. If your platformer has something that breaks from those defaults, a mechanic, a setting, a relationship between systems that is specific to your game, that difference belongs in the first prompt. It is the thing the AI would never guess from the genre name alone, and it is the thing that makes your game yours.
These three questions are not a template. They are a check. If you can answer all three before you open the prompt field, you have enough to write a first prompt that gives the AI real direction. If you cannot answer one of them, that is the gap to close before you start, not after.
Putting it into practice
The Makko team uses these approaches every week building games live in public. The game being built during this session, Rift Runners, is a cyberpunk run-based platformer where players dive into collapsing dimensions to recover fragments. It went from a blank prompt field to a playable prototype in one session. The first prompt used Jeremy's structured approach combined with Cesar's feeling-first framing: it specified the core mechanic, the player fantasy, and the tone before describing any individual system.
The faster way to learn the approach is to use it. Pick a game idea you have had for a while, answer the three questions above, and write the first prompt. The first output will tell you more about what is working and what needs refinement than any template can.
For detailed walkthroughs and live build sessions, visit the Makko YouTube channel.
