tl;dr: To play the game in the browser, click here. (Doesn’t work on mobile, sound warning, use escape to access options and see controls.)

What started as a cute little project to learn one or two things about game development eventually turned into a (pretty darn close to perfect) replica of an existing game. You can go and give it a try, or read on to hear my thoughts on Godot, Claude, and gamedev.

Party House is a great game. If you’re not familiar, Party House was released as part of the UFO 50 game collection. (Which is to say, it’s a single game out of fifty.)

Roughly, UFO 50 was a project by Mossmouth (most famously Derek Yu, developer of Spelunky), whose goal it was to release a full 50 games at once. It released in 2024 to widespread critical acclaim, and has a staggering amount of content.

These games vastly vary in scope (some are party games, or can be finished in just a few hours, others are sprawling adventures). Many of them could easily have been released as standalone titles on Steam. Really, it’s a bit absurd just how much “stuff” there is inside of this game, and how silly (non-derogatory) this whole project was.

If you enjoy small indie games at all, I strongly recommend just buying the game, and jumping in. I’d recommend skipping Barbuta (the first game on the list), and going to Mini & Max (my favorite, think of a Mario-ish story-driven platformer in a single connected world, in which your character can shrink and grow in size), Party House, Mooncat (???), Valbrace (first person dungeon crawler) or Night Manor (horror adventure). (Shoutouts to Mortol, and to Avianos for demonstrating that a full 4X strategy game using no more than six buttons is possible.)

So, what’s Party House like? Frankly, you should just play it (again, no mobile support). If you can’t, here’s the quick rundown: Party House is (essentially) a roguelite deckbuilder.

You alternate between a “planning” stage, during which you “purchase” new guests for your party…

…and a “party” stage, during which you pull random guests from your rolodex, and use guest abilities to increase round scores and manage trouble:

You win by getting four Star Guests to attend your party at the same time, and lose once the time runs out. Also, the music bops. That’s it!

Remaking Party House

What was my motivation here? Really, I’d never done a lot of game development. I just wanted to figure out how it “feels” compared to, y’know, other types of coding. That’s it. I always found the weird disconnect between the GUI and the code, and the whole runtime thing weirdly confusing.

(That’s still true, by the way.)

Overall, re-making a game was fun, and significantly easier than building one from scratch.

The original prototype was built with my bare hands, but as it became more and more clear that video games are ~90% polishing everything to “feel good” and wiring up all the little flourishes and assets, I eventually stopped working on it (life was busy), and then when I returned to it I reached for Claude.

(At this point ‘Party House’ had been sitting on my harddrive, untouched, for several months, so I don’t view this as a failure, moral or otherwise.)

I like to cope that I wrote ~80% of the code, and then handed things over to Claude, who wrote the remaining ~80%. I (very quickly) stopped looking at the code, other than for educational purposes. The reason why this worked was that the external game (and the spec Claude and I assembled) worked as a source of truth that kept things from falling apart. The project was small enough that we managed to push it over the finishing line before context management became untenable.

(Also, just for the record, none of the writing on my blog is AI generated. It’s all artisanally hand-crafted sentences, written with my own bare paws, etc.)

One final note: The current version of the remake is built with assets stripped from the original. If I thought there were any risk that this would hurt UFO 50 sales, I’d not release it as is. I worked myself into a bit of a corner: When making a ‘faithful’ remake you’re essentially locked into using the original assets, and stripping them out in favor of something else on the finishing line also doesn’t feel right. For now I’m putting it online as is, and hope that this falls under fair use. (Again, if you enjoy this remake at all, you should buy UFO 50.)

Takeaways on Claude

When I reached for Claude, a very rudimentary version of the game already existed. Core gameplay loop was there, with just ~4 guests or so, none of the scoring animations, and none of the complex guests (which open a rolodex selection menu).

As part of my whole learning experience, I’d already manually extracted the sprites from UFO 50. (For a personal project, there was really no reason not to.)

First, I booted up Claude Code and wrote a (fairly wordy) summary of the situation: I didn’t care enough to finish this game on my own, but I wasn’t sure how it’d be able to help me out, seeing that games are pretty tough to iterate on without being able to “play” them and get the immediate visual feedback.

Claude figured out how to run a headless version of Godot, built a small test suite, and dug up a page of the UFO 50 Wiki to build a spec for the game with me. It correctly highlighted some discrepancies and missing information, and marked them in the spec, which I then edited.

I thought that was pretty impressive. (Y’know, thinking about the state of LLMs even just a year ago, and the fact that people are still stuck on a mental model that AI is completely incapable of reliable workflows.)

Second, we started iterating with pictures. We added F12 as a screenshot button, and I provided a few screenshots from the actual game, allowing it to check its work and compare it.

This worked great: Party House is a grid-based pixel game, giving Claude two screenshots (current vs. intended state, a quasi diff-test) works far better than it has any right to.

Next, sounds. Matching up sprites to the original game was easy enough, music likewise. UFO 50 ships with a collection of ~750 sound effects, with no clear indicators which ones are used by which game without analyzing the game code (which I did not want to do).

What ended up happening is that I threw a few videos at Claude (with background music removed), and told it to “match” those to the sounds in the SFX folder.

Without access to Python, it wrote a sound matching tool (roughly 400 lines of GDScript), and used that (along with the sprites) to figure out which sounds played at which exact moment.

This was not entirely unprompted: I guided it into this direction, but it’s still impressive that it can just pull a functioning sound analysis library out of its head, and implement it in a bespoke scripting language.

At this point we iterated with this: I played the game now and then, gave it some feedback, played the original, and occasionally provided it with videos from the game. This worked great.

At this stage, my iteration loop was to send it a vague, long prompt with ~a dozen small inconsistencies and fixes. Claude worked for up to an hour, and methodically worked its way down the list.

Here’s an example, half of which won’t make any sense without context:

1. Cursor should wrap left and right at the edge of the screen
2. When returning to the party, there are often still floating score numbers. It'd probably be fine if we added a minor delay at the end of the party, so that they've certainly disappeared. Or we just clean them up before we return
3. When climber comes in, she gets a flashing yellow background like during scoring, because she has an 'on entrance' ability. (I added a new video)
4. Werewolf also has a special entrance sound, and also flashes. (I also added a new video to the reference folder)
5. I believe in the rolodex, the second list of characters is those who've already shown up. The third is those that were kicked out for any reason (e.g. previous party police, but also security guard)
6. When a guest that brings additional friends enters, there should be a short delay, and the sound effect must play for each incoming guest.
7. During a victory, the party loop must repeat infinitely until the user presses cancel or activate.
8. I added a new video demonstrating the sound effect that plays when e.g. the driver's ability is used to fetch a guest from the rolodex
9. If fetching someone (e.g. magician or driver) and there's just one possible target, it should be selected automatically.
10. If you cannot afford to pay something (negative money during scoring), you get a -7 popularity. I added a video demonstrating this. (No such mechanism exists for pop, i.e. it just caps at a lowest value of 0 with no special acknowledgement. I added a video.)

As far as AI-assisted coding goes, this is still real amateur hours. For vibecoding, you could be even less hands-on, and for a proper verification-loop you obviously don’t want to tell Claude all of these things manually: You want to give it a way to verify that the game is consistent with the original, and then just have it find all the minor issues on its own.

Claude lamented that it’s unable to take screenshots (without my help, that is). This was a point of annoyance, but there (almost certainly) would’ve been some way to push past that, which would’ve made it much easier for Claude to iterate. The reasoning itself was not the bottleneck, it was giving Claude access to the data it needed.

The obvious step to take the whole process to the ’next level’ is to just hand Claude a longplay and some assets, and then ask it to build a pixel-perfect replica purely based on that input. (Party House had been hands-on enough that I didn’t care to push it into that direction. It doesn’t make sense to pivot when the game is already basically done. It’d be a fun project though, and I’m pretty confident that stronger models can do this, at least for certain simple games.)

We were slowly creeping into spec rot / context rot territory by the end, with docs and test suite slowly growing more bloated and complex. It was still completely bearable, but I imagine that this would be a real issue for a larger, more complex game.

Takeaways on Game Development

It’s pretty obvious that AI-assisted coding can make certain tasks significantly easier, and is not just going to disappear.

I don’t want to get into a discussion over whether my Party House code is “maintainable” or “high quality” or anything like that. This isn’t to say that code quality doesn’t matter. It really, really does. But it doesn’t matter for self-contained projects like this. Party House doesn’t need to be maintained.

If you do game development, one of the most critical, fundamental truths you have to learn is that actually releasing a game is the only thing that matters, and code quality only matters insofar as it prevents you from getting there.

At this point Party House is as done as I’d like it to be (with some minor discrepancies and two-player mode missing). What matters for me is that it exists at all, and would not exist in this form without AI assistance.

(If you’re working on a compiler, filesystem, operating system, or anything ambitious, by all means, you should care about maintainability and overarching code structure. Nothing is more embarrassing than a self-proclaimed code guru who slopped it up silly style, and ended up with an incomprehensible blob of a codebase which even Claude cannot reason over anymore.)

Many highly regarded indie games (e.g. Undertale, Balatro, Slay the Princess, Fear and Hunger) were (essentially) built by artists or hobbyists, using “““non-professional””” engines such as GameMaker, Love2D, Ren’Py or RPG Maker.

I can almost guarantee that there’s crimes happening inside of these codebases. These developers went in with a vision of a game, and focused on building and shipping the game, instead of getting stuck on code quality or engine considerations. These are games built by people with an artistic vision, not by people who’re stuck relentlessly fixating on the tools that they’re using.

One of the greatest mistakes you (as an aspiring game developer) can make is to get hung up on your tools.

This is a well-known fact, to the degree that there’s a famous saying that goes something like

“You can either be a game developer, or a game engine developer, but not both.”
— Some guy

This is the same reason why you should tell new game developers to actually ship projects and stick to an engine, instead of getting caught up in full rewrites or new projects the instant they run into difficulties or annoyances.

Claude Code is, in this context, a tool. You need to know how to leverage it. You need to be careful with context bloat. You need to have a very specific idea of what you actually want, and need to know how to translate those desires into something actionable. You need to be very, very aware of tradeoffs.

And, of course, you need to be very careful that your own skills, your own “feeling” for what you’re trying to build, and your own grasp on the mechanics doesn’t slip away if you rely too much on a tool.

That said, if you actually want to ship a game, then you should use the best tools you can get.

I assume that, at the moment, there’s a pretty firm divide among indie creators and developers between those that are embracing new tools, and those that are actively rejecting them. I am very much sympathetic to economic concerns, the downward pressure on labor and concentration of power, but it doesn’t exactly change that you (as a creator) will have to (eventually) make a decision on how you work, and cannot go back to a world in which these tools do not exist.

For me, I have no qualms reaching for AI tools for projects where I care about the outcome. If I want to fix a printer, I want to fix a printer. Claude is better at debugging a printer than I am. I will lose out on an incremental skill increase of printer debugging. I am fine with that, and can spend that time learning something else.

When it comes to writing I don’t make the same compromise. Writing is a form of self-expression, and about honing my thinking skills. If I cannot put it into words myself, that’s a problem. Using Claude to write this article for me would defeat the point, so I am not going to do that.

Just remember two things:

First, releasing a game is always better than not releasing anything.

Second, just because it’s easier than ever to release a game, doesn’t mean you have any excuse to annoy people with unpolished, low quality, unoriginal AI slop. Have a strong vision of what you’re actually trying to build! If everything is easy, originality, vision and quality matters!

This is NOT to say that my remake is the pinnacle of quality.

What I did wasn’t even game development, it was spec-driven development. I just used an existing game as the spec. I skipped the hardest part, I didn’t have to do any actual game design.

But that’s fine! This was a fun side project, and doing game design was never the goal. This was a stepping stone. The goal was getting to a point where I’d feel confident tackling a real game project. Y’know, including the interesting part, working out a vision and then figuring out how to execute it.

I don’t know if that will happen anytime soon, but I’m happy that tools exist that turn game development from a brutal multi-year coding endeavor into a slightly more manageable process. It’s not like anyone has an unlimited amount of time available to them, after all.

Takeaways on Godot

The scene tree system kind of sucks? I do not like how everything seems to be split between the UI and the code, instead of being a unified whole. I assume no game engine exists that unifies these, so maybe that’s fine.

I was never a big fan of heavyweight IDEs or editors, so some of this probably just comes down to preference. (The three people who follow this blog will already know about that).

Still, with something like the scene tree system, it always felt like there are two different ways of doing everything: Either I can open the GUI, press on my node, and then click ‘Create child node’, or I could jump into the code, and construct a child node inside of the code (and attach it).

Don’t get me wrong, I understand why the visual workflow is useful to people, but I can’t imagine that there is any game engine in existence in which these are truly unified in a way that is fully bidirectional. You can call this the big curse of WYSIWYG editors.

Side note, I will register a prediction here: WYSIWYG editors are clumsy and essentially GUI-only. I am reasonably confident that the rise of AI will move the industry away from them, towards tools that can be interacted with as raw text, for the obvious reasons. (For the record, Claude had no issues whatsoever handling Godot’s .import and .tscn files, but Google Docs doesn’t even have that.)

In my ideal world, the game engine would leverage something like Zig’s compile-time execution feature.

As a result, the UI / scene tree would be exactly the subset of the code that is constructed at compile time. This would allow you to construct a basic scaffolding at compile time, and to hand things over to runtime whenever you need to. This ‘scene tree’ should be autogenerated based on the code.

This would (ideally) align the GUI with the code, and cut down the need of the editor to keep track of additional bespoke state.

The hard part here is (as always) making this work bidirectionally, i.e. ensuring that GUI buttons can track down the correct spot in the code, and modify it in a way that makes sense.

If we can’t make that work, I’d still be happy: I think treating the GUI purely as a visualization (and debug and jump-to-location) tool is all I need.

I don’t know, maybe I’m alone on this topic, I’m not deeply enough involved with game devs to know how they feel about this. Frankly, once Claude got involved most of this became a non-issue anyway, and in future projects I might try to just avoid the GUI altogether.

Other than this, Godot was honestly great. I’m happy to see it take off, and happy to see that we’re seeing all sorts of new games being built on top of the Godot engine.

Even GDScript was honestly quite fine! I question whether the investment into a full new programming language was really worth it (over sticking to C# and, say, Lua), but in itself the language really isn’t that bad.

Finally, if you (the reader) are interested in dabbling with game development, I don’t think my commentary here on Godot is going to be useful.

You should just go and make a game. Use any engine. I’d recommend Godot, but what really matters is committing to something, and keeping at it for a while. Just make it small, such that it’s remotely manageable. Like, say, a small remake of a classic.

Just work on it, and release something, no matter how small it is. The rest isn’t all that important.

PS: Small shoutout to Terraforming Titans, a great incremental game about terraforming, developed with heavy AI assistance, and featuring complex planet-scale climate simulation.