FROM COMIC TO PRACTICE / POST 106
Make one level. Then make it better.
Patrick tested a new ChatGPT image model by making a one-level, 1990s-style run-and-gun parody about scope creep, approvals and deadlines. The joke became ASH VECTOR, a playable game and an action-movie-style trailer. Here is a small workflow you can reuse to learn from a similarly unnecessary idea.
What the post confirms
Patrick says he made ASH VECTOR as a one-level parody of a childhood favorite. The post names the ChatGPT image-model test, the office-process enemies, a 1990s-style trailer and an early generated pose where Su accidentally had an extra arm. He made a corrected pose before moving on. The post does not list his complete engine, code stack or trailer software, so the steps below are a reader’s build template, not a reconstruction of every tool he used.
1. Pick the smallest playable joke.
Choose a mechanic you enjoy, then invent your own character and obstacle. Write one sentence that a player can test: “Move, dodge a silly office obstacle, use one simple action and reach the exit.” Draw a single screen with Start and Exit visible. A one-level brief is small enough to finish and clear enough to tell you when an extra feature belongs in the Ideas Later folder.
2. Give the art rules before generating more art.
Describe the hero’s silhouette, palette, proportions and poses. Ask the image model for an original concept sheet, then compare every new asset with the reference. Inspect anatomy, expressions, readable shapes and consistency at game size. If a draft adds an arm or makes an obstacle disappear into the background, correct it before it becomes a sprite. The comedy in Patrick’s post comes from catching a real image-generation mistake rather than pretending it never happened.
3. Build the complete loop before the spectacle.
Implement movement, one action, one hazard, a clear hit or miss response, and an exit. Test from Start to Exit with the controls a player will actually use. If a hazard is hidden, improve contrast; if a challenge cannot be anticipated, add a warning or more reaction time. Let someone else play without coaching, and write down where they hesitate. Their confusion is useful data, even when your trailer idea is excellent.
4. Save the workflow as a reusable skill.
For your own projects, put a short SKILL.md or checklist beside the game: one-level brief → original art reference → asset review → playable loop → full-run playtest → cut list → short trailer → publish and feedback. Add acceptance checks at each arrow, such as “Start-to-Exit works” and “all art passes a two-person visual review.” Reuse that sequence for a different game concept while making new art, characters and examples. This is a suggested way to clone your own workflow; the LinkedIn post does not claim Patrick used this exact skill file for ASH VECTOR.
5. Share the real game and listen.
Cut a short trailer from the game’s actual start, challenge and finish. Exaggerate the feeling, not the feature list. Then publish a playable build with specific questions: How did movement feel? Which obstacle was hard to see? Where did you get confused? Put responses into Fix Now, Test Next and Ideas Later. You can try Patrick’s ASH VECTOR game ↗ and decide what a one-level experiment taught you.
Where the story came from
Read Patrick’s original LinkedIn post and comment ↗. The giant Scope Creep monster, tiny robot, dialogue and project-room scenes are fiction. The practical build sequence is an adaptation of the post’s “start building and see what gets weird” lesson.