I've been having a bunch of fun working on a couple games on a new platform - everything (platform and games) developed with AI.
quackwave.com
Hasn't really been stress tested yet (this is the first time I'm mentioning it publicly), but it's been fun playing with friends & family and iterating.
Party game platform, think "jackbox but no host screen" - just need a web browser open on phone/tablet/PC.
Your comment matches my experience: it has to do what can and cannot be verified. As an example, it was much easier to have AI write a large e2e test using Playwright (then add test cases and expand) than to assume it'll correctly fix bugs without guidelines like this. Also, the human loop is still important in things like screenshot verification - but the frontier models are getting even better here so I'm not sure for how much longer this will be true. The ratio of test code to production code is a bit over 2:1 right now.
I have an amusing update to report, I've checked one of the major new features that was added a few days ago. It turns out it was implemented backwards, and in a way which defeats the entire purpose.
Nevertheless, several thousand lines of test code were added, and all tests pass!
I found this particularly amusing because, I've been obsessed with correctness and verification lately, thinking about rewriting the game in Rust, and adding formal verification to the game.
What I realized here is that, this wouldn't have helped at all. The AI would have just written the wrong code in Rust, and then written a mathematical proof that the wrong code is correct...
Agree. The tests are great! Playtesting reveals that gameplay breaks my assumptions on how the system should work. Where to go from here?
Telling AI to "do TDD" is a shortcut that gets me over 80% there by itself in aggregate with little effort. The last 20% is painful. More painful than the usual "last 20%" in game design and development. I think this is part of the human vs. LLM gap.
If you revert the code to before the feature was implemented, then called out the way not to do it (the failed version you're describing) - what would happen? Maybe that "80% there" turns into "90% there", or maybe it's a bit better. Or maybe a bit worse. Working with LLMs vs. humans, does the gap shrink further if you gave other people the same requirements you gave the LLM? I think it depends on who you're working with - other people have their own opinions and don't necessarily just do exactly what they're told without taking their experiences into account.
In a way I see it like playing a game of telephone. I have my understanding of the system, I translate it into words, the LLM interprets it and does what it does based on that. For some reason, it feels like this is a telephone game with 3 people: A to B to C where the translation layer of my thoughts into words is an inserted "B". In contrast, if instead I'm expressing my thoughts to another person it's A to B. This extra connection here is lossy in the same way a game of telephone is lossy from player A to player C.
I work in the slot game industry. Plenty of ex-video game devs in this space. Much better work-life balance, but it's very clearly not the same as making video games.
Probably true in general. But there are always exceptions. Hard to imagine a tool better than Excel for slot game math calculations. Maybe it can be done?
Calculations for slot machine mechanics and payouts have been in Excel for a long time. There can be a LOT of complexity in these workbooks. Sometimes it’s tricky to debug - but what’s the alternative? Code is often hard to debug too.
Simulating results (Monte Carlo) is nice but having two sets of data for validation/checking against each other is nice.
The app refreshing every time it comes into focus is annoying. Not sure when this started but it’s frustrating when what I click on isn’t there after the app refreshes
It is useful to use the words hard and easy. As you mention, changing perspective around these concepts is the crux.
Hard problems or domains are unknowns. Working towards solving hard problems involves thinking through unknowns, which may or may not lead to understanding. An aversion to hard problems is an aversion to the unknown.
It's not as mature as other platforms, but it's built extremely well from the base up. Unity has a huge ecosystem and tools, but it's built on a shitty/messy platform full of bugs and hacks.
If I was to make a quick & simple 2d or mobile game today, I'd go with Unity. If you want to make something that will require more effort, but work well for years, Godot is better.
I definitely recommend GDScript, especially if you are using Godot 4 / GDScript 2. The language was designed to be used in Godot to make games, and in my opinion it’s very good at that. The editor integration is great, defining export variables for the inspector, adding doc comments that show up in the built in help viewer, dragging nodes and files into your script to get their onready and preload paths, etc… It’s just really nice to use, and takes literally a day to become proficient.
Yeah, I recently looked at setting up some C# dev for Godot 4 and I found documentation scarce. Conversely, GDScript was much better catered for, even allowing for the fact that the documentation isn't all there for Godot 4 yet
quackwave.com
Hasn't really been stress tested yet (this is the first time I'm mentioning it publicly), but it's been fun playing with friends & family and iterating.
Party game platform, think "jackbox but no host screen" - just need a web browser open on phone/tablet/PC.
Your comment matches my experience: it has to do what can and cannot be verified. As an example, it was much easier to have AI write a large e2e test using Playwright (then add test cases and expand) than to assume it'll correctly fix bugs without guidelines like this. Also, the human loop is still important in things like screenshot verification - but the frontier models are getting even better here so I'm not sure for how much longer this will be true. The ratio of test code to production code is a bit over 2:1 right now.