I Shipped My First Game in 3 Weeks Using Sorceress. Here’s What I Learned

I shipped my first game in 3 weeks using Sorceress. Here’s what I learned: the viral-looking version is one person, three weeks, one finished game, and thousands of people asking how it happened. The useful version is less magical and more repeatable. You ship your first game with AI by refusing to build the big game first.

The winning beginner project is almost embarrassingly small: one playable loop, one character, one map, one fail state, one win state. WizardGenie can write and run the code. AI Image Gen, Quick Sprites, SFX Gen, and Music Gen can fill the asset gaps. But the part that makes the project ship is not the model. It is the brutal scope control.

I shipped my first game in 3 weeks using Sorceress: the honest promise

AI can compress the time between idea and playable prototype from weeks to hours. It can scaffold a Phaser game, debug a collision bug, generate a sprite sheet, make a hit sound, draft a title screen, and explain why the build is broken. That is real leverage in the plain English sense of the word: a small creator gets more done per hour.

What AI does not do is choose the correct scope for you. If you ask for a Skyrim-like RPG with crafting, branching dialogue, boss fights, procedural loot, multiplayer, and a living economy, the agent may produce files. It will not produce a sane first project. A first game needs a loop so small you can describe it in one sentence:

• Collect five keys while avoiding guards.
• Survive 90 seconds in a shrinking arena.
• Deliver potions to three villagers before sunset.
• Explore one dungeon room and beat one enemy.

The screenshot that gets clicks is the finished fantasy town. The work that gets you there is a tiny scene that becomes fun before it becomes pretty.

Step 1: choose the game you can finish in one sentence

Start with a genre shape that AI coding agents are already good at: top-down action, platformer, survival arena, clicker, puzzle room, runner, or tiny roguelike. These genres have clear loops, obvious failure states, and simple controls. They also map well to browser tech, which means you can publish without installing an engine or fighting export settings.

Open WizardGenie and write the first prompt like a producer, not a dreamer:

Create a tiny browser game in Phaser.
Title: The Bronze Key.
Genre: top-down fantasy micro-adventure.
Player goal: find one key and reach the locked gate.
Controls: WASD to move, Space to interact.
Map: one small town square with alleys, crates, guards, and one gate.
Failure: if a guard touches the player, restart the room.
Win: if the player reaches the gate while holding the key, show a victory screen.
Keep the first version simple. Use placeholder rectangles until the loop works.

That last sentence matters. Placeholder rectangles are not a failure. They are the fastest way to find out if the game exists. If movement feels bad with rectangles, it will still feel bad with beautiful sprites.

Step 2: make the core loop playable before adding art

Your first milestone is not a screenshot. It is a loop you can play ten times without explaining it to yourself. The player moves. The enemy threatens. The objective is visible. The restart works. The win screen appears. That is the skeleton.

Ask WizardGenie to iterate in small passes:

• Pass 1: movement, camera, boundaries, restart.
• Pass 2: one objective and one win state.
• Pass 3: one enemy behavior that creates pressure.
• Pass 4: UI hints so a stranger knows what to do.
• Pass 5: title screen, restart button, mute button.

Do not ask for inventory, shops, dialogue trees, achievements, save files, procedural generation, or five levels until this one loop works. Liz England’s “Door Problem” is still the best warning here: every ordinary feature expands into design, code, art, animation, UI, audio, testing, and edge cases. A door is not just a door. A locked gate is a whole feature.

Step 3: use AI art after the game is already fun

Once the loop works, replace placeholders with a tiny art set. “Tiny” means tiny. One player sprite, one enemy sprite, one key, one gate, one ground tile, one wall tile, one UI frame. If you need more than ten core assets, the project is probably slipping out of first-game territory.

There are three practical paths inside Sorceress:

• Fast concept route: use AI Image Gen for a key character and environment look, then use that as style reference.
• Pixel route: use Quick Sprites for an animated character sheet, then keep the environment simple.
• Conversion route: use True Pixel to make AI concept art feel more consistent and game-readable.

For a Reddit-style fantasy micro-adventure, the prompt can be plain:

pixel art top-down fantasy rogue heroine, dark cloak, leather armor,
small readable silhouette, 32x32 sprite sheet, idle and walk frames,
transparent background, consistent lighting, muted medieval palette

Then constrain the palette. First games fall apart visually when every asset looks like it came from a different universe. One lighting direction, one palette, one camera angle. A less detailed but consistent game looks more finished than a gallery of impressive disconnected assets.

Step 4: add sound like a game designer, not a composer

Sound is the fastest way to make a small game feel real. You do not need a full orchestral score. You need feedback. Step, pickup, hit, win, lose, button click. Five sound effects can do more for a first game than ten extra mechanics.

Use SFX Gen with short, specific prompts:

• Pickup: “bright magical key pickup, tiny sparkle, 0.4 seconds, fantasy UI”.
• Guard hit: “soft armor bump, wooden shield thud, non-gory, 0.3 seconds”.
• Gate open: “old iron gate unlock and swing, satisfying, 1.2 seconds”.
• Victory: “short fantasy success sting, warm bells, 2 seconds”.

For music, use Music Gen to make one short loop: “quiet medieval town at night, low strings, soft hand drum, mysterious but cozy, loopable, no vocals.” Put it low in the mix. If the player notices the music more than the game, turn it down.

Step 5: follow the three-week schedule

The point of a three-week schedule is not speed for its own sake. It is protection. A deadline keeps the project from growing teeth. If the headline is “I shipped my first game in 3 weeks using Sorceress,” the schedule has to protect the loop from every tempting extra feature. Here is the plan I would use if the goal were to make the kind of “I shipped my first game” post that people actually click.

Week 1: the loop

Day 1 is the prompt and first playable build. Day 2 is controls and collision. Day 3 is the objective. Day 4 is failure and restart. Day 5 is one enemy behavior. Day 6 is UI hints. Day 7 is a stranger test: give the game to one person and say nothing. If they cannot figure out what to do in 30 seconds, the design is not done.

Week 2: the asset pass

Replace placeholders, but do not add mechanics. This is where AI helps most: sprites, icons, sound, music, title screen, maybe a tiny cut-in illustration. Keep every asset serving the existing loop. If a new asset implies a new feature, skip it.

Week 3: polish and publish

Balance, bug fix, add a menu, add credits, write a one-paragraph description, capture screenshots, and publish. If you still have time, add one optional flourish: particles on pickup, a minimap dot, a short intro card, or a better victory screen. Not all four.

Step 6: publish before you feel ready

A first game is not a portfolio masterpiece. It is proof that you can finish. The final step to ship your first game with AI is putting the browser build somewhere people can actually play it, then resisting the urge to rebuild the whole thing. Use the Sorceress publishing flow, then write a short postmortem: what you built, what AI helped with, what broke, what you would cut sooner next time.

The postmortem is not fluff. It turns the project into a learning artifact. People respond to specific lessons:

• “My first prompt was too big.”
• “The game got better when I removed the inventory.”
• “AI art helped, but consistent palette mattered more.”
• “The enemy was fun only after I made it slower.”
• “Publishing took less time than avoiding publishing.”

That is the honest version of the viral hook. Not “AI made a complete game for me while I watched.” More like: “AI let me stay in motion long enough to finish.”

What to cut if the schedule slips

Cut features in this order: story, extra levels, inventory, dialogue, crafting, meta-progression, settings menus, alternate characters, procedural generation, boss fights. Keep controls, objective, restart, win, fail, audio feedback, and one good screenshot. The screenshot gets people to click. The restart button gets them to keep playing.

If you are three days from launch and the game is not fun, do not add content. Simplify the loop. Make the enemy slower. Make the goal clearer. Make the camera better. Add a big arrow. Reduce the map. The boring fix is usually the correct fix.

The first-game QA checklist

Before publishing, run this checklist manually:

• The game starts from a clean browser refresh.
• The player knows the controls without reading a long tutorial.
• The win condition works twice in a row.
• The fail state restarts cleanly.
• Audio can be muted.
• The game fits on a laptop screen.
• The first screenshot communicates the fantasy immediately.
• The title and description say what the player does, not just the lore.

That is enough. Ship it. The second game is where you get ambitious.