Idea
New model releases make us want to try something again and again to guage their improvement. For GPT Sol, that meant building a game: one design session, one planning session and then a build session where it could choose the engine and make the calls that turn an idea into something you can actually play.
We gave it a 3D model of our sidekick character. Sol made that in a separate session with its computer-use skill and locally installed Blender, which was a useful test in its own right: could it create a usable asset without someone hovering over every menu? Apparently, yes. Blender survived the encounter.
The build brief was guided with enough info to get it going but the general theme was make an endless platformer that feels good to play, rather than a collection of technically correct menus that nobody opens twice.
A useful endevour for small teams and solo builders who want to test an AI coding model on a complete, contained prototype.
Status
Working, and more addictive than a test project has any right to be. The game drops the player into an endless stretch of space, with a difficulty setting and gravity setting chosen before the first jump. Stay alive, collect time, and keep moving.
Each run starts with 60 seconds on the clock. Pickups add time: Gippity's are broken-coin-looking things, Credits are 3D GBP signs (£), Subs are tiny submarines, and Clouds are little orange clouds. None of this is trying to explain itself too hard, which feels correct.
Platforms spawn in new random positions as you move. Standing still is a losing strategy: wait too long on one platform and it disappears. The background moves between black and faint colour tints in response to system audio, so the game gets a little more lively when your speakers do.
What stood out was the combination of the build and the setup work before it. A playable loop, a model made in Blender, random platform generation, pickups, a timer and audio-reactive visuals are all manageable pieces on their own. Getting them to agree with each other is usually where a prototype starts leaving socks on the floor.
Problems Faced
The first version of platform spawning was too cautious. Sol did not initially judge the character model's scale very well, so the “endless” level became a very long, tidy row of platforms. Fine for a walking simulator; less ideal for a platformer.
We steered it towards a wider spread of valid spawn positions and asked it to account for reachable jumps rather than simply placing the next platform somewhere safe. That meant balancing a few constraints: the player's jump height, the gravity setting, platform spacing and the need to avoid impossible gaps.
Random generation needs rules. Pure randomness is an efficient way to create one excellent jump followed by a small betrayal.
Techniques That Helped
The biggest help was a clear brief before any code was written. We gave Sol room to choose the game engine (it chose Godot), but the outcome was specific: an endless platformer, a controllable character, pickups that extend a countdown, disappearing platforms and responsive visuals. Clear constraints gave it somewhere useful to aim.
We separated the visual work from the game build. One conversation handled creating the character asset in Blender; the other focused on code and gameplay. That kept the build context centred on movement, spawning and game rules instead of carrying a long trail of character-design decisions.
We also let Sol manage its own AGENTS.md and handoff notes during the work. One session was enough, so there was no need to reconstruct the project halfway through. For a small prototype, that continuity made iteration faster: identify the behaviour, describe the change, test again.
Lessons Learned
Start by planning the project with a person, even if that person is just you with a coffee and a notes app. List the player goal, the main mechanics, the parts that need assets and the questions you expect to come up. You will find holes in the idea before the model has to guess its way through them.
Separate conversations by task where it makes sense. In our case, the Blender session could focus on making the character, while the build session spent its context budget on gameplay and code. That is often cleaner than asking one chat to remember every artistic and technical decision at once.
GPT Sol handled a long build context better than we expected, and it can get a prototype a long way with sensible guidance. For many people, a $20-per-month budget is enough to turn a long-held idea into something playable, provided the idea is small enough to explain and you are willing to test what comes back.
Got a prototype idea that needs a second brain or a steady pair of hands? Get in touch with Holeaf and we can help you work out the next jump.