DEV Community: Simone Sturniolo

How I made a Game with Claude from scratch

Simone Sturniolo — Sun, 01 Nov 2026 21:56:03 +0000

Coding agents are quite powerful. Claude Opus 5.5 in particular has been hailed for its smarts and creativity from its release (especially compared to its relatively contained cost in comparison to the behemoth Fable, or the OpenAI rival Astra). There's tons of examples of images, videos, and even music made with Claude, and I'm sure quite a lot of games too. I decided to experiment with it myself to test the limits of it, and what it could do. My challenge was to make a game entirely with Claude. No separate AI models for image or music generation and basically no manual coding - just me prompting my way to a full, functional browser game. The chance was offered to me by the LittleJS Jam 3, a friendly competition for amateur gaming that is quite accepting of AI coding and asset creation [^1]. The competition's only requirements were that the game should run in the browser, that it should use the LittleJS game framework, and that it should adhere to the chosen theme keyword: zig-zag.

Read on for my experience and insights in making a game for this jam in just a few days with only a Claude subscription, and what the final result ended up being!

The idea

First, I decided I wanted full creative control over the high level of the concept and game design. I still wanted this to be my game in a meaningful sense, not just a full AI creation. My core concept was "Zig-Zag Heroes", a survivors-like (or "bullet heaven") game played entirely in one dimension with just two buttons, left and right. Basically something borrowing in equal parts from Vampire Survivors and One Finger Death Punch, both masterpieces of dumb and fun arcade gameplay. My core ideas could be summed up as:

it'll be about surviving enemy waves from both sides with a character that shoots only in front of them;
the enemies would drop XP which allows the character to level up and choose passive or active skills to boost themselves;
the aesthetic and style will be somewhat inspired by classic side scroller shooters and beat 'em ups (think Streets of Rage or Metal Slug), with bombastic and cartoonish visual effects;
to make the mechanics a bit more varied, since compared to the already simple control scheme of VS I was also taking away one whole dimension of motions, special skills/weapons wouldn't be auto-firing, but triggered via specific key combos relying on order and timing of button presses.

With these parameters in mind I set to work having Claude lay out an example of game mechanics with a first level and a few basic skills, using only placeholder art (made just of flat colored rectangles, essentially). This actually worked quite well from the get go, and a few tweaks were enough to refine it in a workable loop. One interesting thing that Claude did entirely autonomously: it created a "bot" using scripted behaviour to play the game on its behalf at high speed and accumulated statistics over several runs which it then used to balance the game. The result was really good in my experience; while I did suggest a few tweaks now and then the levels felt challenging and right almost immediately.

Art and Music

After establishing the core gameplay, it was time to start developing the actual style and feel of the game and adding content. This required creating sprites, sounds, and music.

For art, just a few weeks before I had already developed Claude Pixet, my own custom MCP for pixel art, which had already produced fairly good results:

During the usage for this project, Claude expanded on the ways to use this tool, including suggesting a new method altogether in which it maps characters to palette colors, then "draws" a pixel image entirely as ASCII. As a result, it produced rather legible and good looking sprites, albeit somewhat generic. Here's the first hero, a clear reference to the classic original 2D Duke Nukem:

The design was an interpretation of my own direction, as was the case for every successive level, hero and enemy. In general, all art ended up being made by Claude with my steering, which included e.g. listing what kind of items should be visible in each level's scenery. The one case where for some reason Claude seemed to keep getting it wrong and I had to personally intervene was the boss enemy of the first level, the Biker King. There were several attempts which mostly failed in capturing the right pose for someone riding a motorbike. At the end I took it up on my own hands and simply drew the entire sprite with a pixel art editor. It's not particularly good, but that gives you a sense of how bad the Claude versions were.

For music, I did not need to develop a custom tool. Instead I just told Claude to use the music programming language ChucK. It was a good fit since I needed chiptune, not any kind of realistic-sound sampled music, so this way Claude could design simple synths for its instruments, the compose with them. For example, for the space level, I told it to use theremin-sounding synths and generally evoke cheesy 50s science fiction, mixed with the boppiness and energy of the disco cover of the Star Wars theme. It came up with a plan that it writes as such:

// "Galactic Boogie" - Outer Space level theme. Space disco: E Dorian (with heroic C and D major chords), 120 BPM.
// Form (loops forever): F (4 bars, brass fanfare over string stabs) - G (8 bars, the groove: octave disco bass,
// funky muted guitar, string pads, laser zaps) - C (4 bars, the brass theme) - K (4 bars, breakdown: arpeggio,
// bass and claps) - L (4 bars, last chorus: the theme with everything, arpeggio on top, a B7 turnaround).
// 24 bars at 120 BPM = 48 s: keep music/songs.jsonc "seconds" in step if the form or tempo changes.
//
// Voices: disco bass (square and saw through a plucky filter), string synth (detuned saws, slow attack), brass
// lead (three detuned saws, a filter that opens on each note, vibrato), muted funk guitar (a short filtered
// chord), arpeggio (square with an echo), laser zaps (fast falling sweeps), drums (four-on-the-floor kick, claps,
// open and closed hats, toms).
// Melodies are sixteenths in MIDI: 0 = rest, -1 = hold.

Here you can hear the result. It's notable that unlike with images, Claude can't take in audio input, so there basically was no feedback loop possible - it was composing effectively "deaf". Even so, the result is perfectly serviceable.

Writing, design, gameplay

Most of the rest of the development was directed extremely qualitatively by me, and almost immediately caught on an expanded upon by Claude. I won't say it literally one-shotted everything, but it came pretty close. The first draft of anything was almost always very good and it only needed tweaks, often a matter of taste more than necessity.

Gameplay, past the basics, required mostly establishing what each skill would do and the various enemy patterns and bosses. I described most of those (for example "the Nuke skill has a certain % chance of killing each enemy on screen", or "the Galactic Emperor boss fires a ray gun and calls for missiles from his fleet"), diving more in depth into patterns and ideas, but almost never gave numbers. These were refined by Claude via basic formulas and the bot runs.

The writing was not the biggest crux of the game, given that all it amounts to is quippy flavour text, but it's the one thing where I actually took the most hands on approach. I had Claude essentially defer for all text data to JSON files where I then mostly rewrote all of it myself. That said, a few of Claude's original ideas remain wherever I thought they were funny enough and I couldn't come up with anything better (such as "Tanks for Playing" after defeating the Tank Bros).

Token usage

The project took me about a week of my Pro subscription from start to finish. Usually just generating a level could be as much as a whole 5 hour session's worth of tokens. That's not a lot in the grand scheme of things (it could have been done in a couple of sessions on a Max subscription), but it was troubling how much the usage tended to grow as the project did, even if I used compaction regularly. Part of the problem was likely that I did most of it in a single thread, hoping that this would help with stylistic consistency. In hindsight I might have had better efficiency breaking tasks down, but ultimately, for a project of this size, it worked out nevertheless.

The final product

You can play the game on Itch.io or here on Wavedash, with achievements and cloud saves.

How many Python packages are versioned correctly?

Simone Sturniolo — Thu, 03 Oct 2024 21:09:16 +0000

The other day, as I was looking into a database of vulnerabilities in Python packages, I realized that some of the package versions in there could not be easily parsed and compared with other version strings because they did not abide by the standards of Python versioning - either the old PEP 440 or the Version Specifiers specification that superseded it. So I started wondering how common this was. How many packages on the Python Package Index actually have valid versions?

The obvious answer was: go check. So I created a new virtual environment, downloaded requests, and proceeded to write a multiprocessing script to query the PyPI API for literally every version string used by every package . It took me a few hours even running on all cores but by the end of it I had retrieved over 6,057,703 version strings from 545,018 packages, stored in a neat SQLite database. You can find it on Kaggle.

Next came parsing. I found two libraries that promised to validate a version string for compliance:

pepver: "PEP-440 version parsing, interpretation and manipulation"
parver: "parver allows parsing and manipulation of PEP 440 version numbers"

Note that to be fair both these still stick to PEP-440, which has now been replaced, so I will keep that in mind, especially when looking at the strings marked as non compliant.

After another couple of hours of intense multiprocessing I had updated my database with two boolean columns indicating whether the strings parsed successfully with these two packages (also on Kaggle).

The results

For a quick summary of my findings:

out of 6,057,703 version strings, 5,542 (0.09%) were found defective;
out of 545,018 packages, 1,285 (0.24%) had at least one defective version string.

So overall the state of the repository seems pretty healthy! The version strings found wrong by both libraries are of all kinds. Some simply use the suffixes in a non-standard way but overall follow the semantic versioning paradigm while others are just commit hashes or strings of words and numbers.

The cases where the two libraries disagree are more interesting. These are the ones that pepver does not validate but parver does:

0.0.2.R
0.0.2.R3
0.0.2.R4
0.0.2.R5
0.0.2.R6
0.0.2.R7

In this case, I would say pepver is in the wrong. Per PEP440 and current versioning rules, r is an acceptable spelling for the post-release tag (standardised to post), and letters are case-insensitive. So effectively 0.0.2.R3 normalizes to 0.0.2.post3 and is perfectly legal.

Meanwhile, here is a random sample of versions that pepver admits but parver does not:

0.0.1dev-20141025
1.5.0-dev-618
0.3.4.dev.20180830
1.15.0-dev-1552
1.4.0-dev-510
0.0.9.dev-20121012
0.2dev-20101203
0.3.4.dev.20180905
1.15.0-dev-1606
0.2.1dev-20110627
1.12.0-dev-1379
1.1.1-dev-275
1.3.1-dev-427

They all have in common the tendency to use other numbers (occasionally dates) after the dev suffix, with some separator. This is indeed also wrong, as the specification doesn't allow for the separator in this case. So again parver seems right.

Anyway, that pretty much satisfied my original curiosity, and reassured me that for the vast majority of cases, the standard methods of parsing and comparing versions will be sufficient. Even among the non-standard versions it's often fairly easy to identify an order, as the deviations are minimal. Still, it's useful to be aware of all the quirks of the official versioning, and to know when we can or can not rely on them.