My mood has been unnaturally high for around two weeks, stronger in this last one. This is unusual for me, I don't really have lasting moods. Most of the time I'm just neutral, so it's nice to feel something for an extended period.

There are multiple reasons for it, but I think it's mostly because things are going great, both in my real life and in my work. January was easily my most productive month ever. I got my engine done, and Emoji Ball Battles' prototype came out way better than I expected.

I guess actually getting things done in a timely manner makes me really happy?

It is interesting how being in this state changes how I perceive reality and act. For instance, I'm much more open to interacting with others now, yearning for it, even, which rarely happened before. I've been reaching out to people I haven't talked to in ages, saying things like, "Hey, wanna go out and grab something to eat?" And I actually want to do it. And some of them said yes, and we did it, and it was great! I'm pretty sure I haven't felt this way about people since I was a teenager.

It's not just people, though. Everything I do has a different energy to it. Like I'm just... more? It's like there's a shield around me, preventing anything that could go wrong from damaging me, which means I can act without fear. It's like I'm 100% uninhibited. It's such a good state to be in, it's kind of intoxicating. Whatever it is, I hope it continues.

This month I got the engine done and got Emoji Ball Battles' prototype off the ground. I was able to do both so quickly due to the AI.

The productivity gains varied a lot depending on the type of work. The hardest part, the engine's C code, took 5 days. That part alone would have taken me 1.5~ month by myself, so it's roughly a 9x improvement.

The framework's YueScript code and the game were different. The framework (Anchor Phase 10) took about the same time as it would have manually. The game's prototype took 9 days, and by myself it would have taken around 2 weeks, so a 1.5x improvement at best.

This difference is striking, but predictable. As I mentioned in Verifiers and Readers, gamedev is a reader-oriented discipline, which means the human has to stay in the loop and many things can't be automated. For the framework code, I wanted every line to be correct, as this is code I'll carry for the rest of my life, so I carefully reviewed everything the agent wrote and had it change a lot of it if it wasn't up to my standards. This naturally slowed things down. Gameplay code is more disposable, so I cared slightly less, but the same dynamic applies.

And specifically for what I worked on in Emoji Ball Battles, how the gameplay feels and juice, you can't give the agent a verifiable win condition, it's purely based on feel. The agent helps in a few cases, generating code for some slightly complex system based on my plain language description, but most of the time I'm just tuning values and seeing how things feel.

I believe the productivity gains will increase as I finish more games and have more examples the agent can draw from. If I ever make an emoji-style game again, which I will, everything visual-related can be copied over. A whole visual design language is already built for these kinds of games, thus making future games come out faster.

The pace at which AI is evolving is interesting. But I can't say I'm excited about most of the discourse around it. Most people seem to be projecting into the future with too narrow of a focus. The difference between verifiers and readers doesn't seem to be appreciated. The fact that there's work that isn't verifiable doesn't seem apparent to most people. They project a future where all work is automated, without concern for the parts that can't be.

As someone working in a largely unverifiable field, my view is much more conservative. The real productivity gains gains for my game making have been 1.5x at best, in the future that might double to 3x, a great improvement, but not earth-shattering. I think the future is one where verifiable fields see huge improvements and unverifiable fields see modest ones.

There's a FOMO nature to all this that I notice too. Tweets like this are common. I understand why people feel it, but I don't. There's nothing about AI tooling that could make me juice a game faster, for instance. The bottleneck is me looking at the screen and saying: this looks right, or this looks wrong. Can this eventually be taught to the AI? Yes, but it's also just a matter of taste in the end.

Can taste be taught to the AI? Yes... but, to get any benefit from it now I'd have to train my own small model on this specific task to do exactly what I want. To do that I'd need to have lots of games to draw from and lots of examples of "this looks right, this looks wrong", and that ends up being a lot of work. I do not want to become an AI developer.

So, for now, my strategy is simple: use the current models as they exist, without heavy infrastructure investment, and move on to the next model when it releases. Model releases are fast enough that if you invest heavilty into tooling this year, it could all be obsolete by the next. And for specific tooling, like the taste example, it's not clear whether it will work, whether I have enough data, etc. So I'm being careful to not fall into the trap of building AI tools instead of just making things with the tools that already exist.

That said, there are ways I plan to use these models for genuinely verifiable work. Emoji Ball Battles is a game that plays itself, which means I can theoretically have millions of rounds played automatically, each with different weapons and builds, and run analysis on that data to make the game better. Going through the full possibility space will take time, maybe hours or days, but this is feasible work, and it's the kind of work where agents actually increase productivity by a lot.

Christopher Alexander has an observation about problem solving that I like: you should always be focusing on solving the part that has the fewest degrees of freedom. When figuring out how to design a kitchen, for instance, there are a bunch of subproblems to solve: where to put the stove and the windows and the kitchen table. And which of these have the fewest degrees of freedom? The windows. If you want good light, there is going to be only one wall where you can place the windows, and at best two spots on that wall where the window looks natural. So you put the window there. And now what? The kitchen table, because you want to have that where the good light falls. The stove can wait because that can sit nearly anywhere. If you start by placing the stove, there is a big risk that you block the only good position for one of the other subproblems that have fewer degrees of freedom, and so the whole design will suffer.

Kind of idea I read and go, "yea, this is right," only to realize I think it's right because I've been doing it intuitively all along. For instance, if you want to eventually make an engine and own the entire stack, it's more correct to start from the high-level API and then move down.

It would seem like the high-level gameplay code has the most degrees of freedom, and the low-level engine code has the fewest. But this flips if you count your own opinions as constraints. If you have strong views about how a game should be coded, which I do, then the high-level API is actually the most constrained problem, as only a few designs will satisfy you. The low-level engine, by constrast, can support that fixed architecture in any number of ways.

My plan for Emoji Ball Battles is simple. This is the best prototype I've ever made, so it seems natural that I'll finish it. The most constrained part of the game is combat, so that's what I'll expand next.

Within combat, weapons are the obvious focus, since how the game feels depends primarily on them. And, importantly, this can't really be pre-designed, it's all about how each weapon feels against the others, which depends on a lot of playtesting.

After that, I'll add classes (the emojis), then passives/items/relics. Once I have all that, I can start balancing using the million playthroughs method I mentioned. And then, only after that, I can start thinking about the meta-loop and how the player will go from the start to the end of his build.

This is by far the project I worked on that I'm most confident about. The question of whether I'll finish it feels ridiculous, the game is already finished, it's only a matter of time until it becomes reality. Which makes me think about what I'll do next...

Oh yea, if you're one of the two people reading this blog, and you want to help me test this game, send me a message on Discord at "adn327ex".

My previous account got banned because I jokingly said I was 5 years old, and apparently the Discord bots reading all your messages do not take hostages. You'd think paying for Discord for over 5 years would perhaps buy you some leniency, but because Discord is run by degenerate furries, I guess the grooming allegations caught up to them and now they have to "take the problem seriously."

I could get the account unbanned, but to do that I'd have to send them a selfie. And I cannot imagine anything more humiliating than a selfie of me holding a paper saying "a327ex" being seen by other human beings, so that's that. Well, in the end, I'm never giving them another cent again, but I'm pragmatic, so talk to me there!

I'll probably have a playable build that requires testing in 1 or 2 months.