Enjoyable reflection. Resonates with me.

Making games is incredible but also very challenging. That’s part of its appeal. Highly recommended.

EHG | Remote | Full-time

EHG is hiring! We're looking for a talented Senior Back-End Engineer on Last Epoch. If you love ARPGs and want to work with a great team (and me!), check it out:

https://eleventhhourgames.bamboohr.com/careers/85

Great write up, very interesting. Shame y’all couldn’t get funding even after Day of the Devs! Hang in there, game looks cool.

I've been using Claude to help write a complex prototype for game dev. Overall it's been a big productivity boost. However as the project has grown Claude has gotten much worse. I'm nearing 15k lines and it's borderline more trouble than it's worth. Even when it was helpful, it needed a _lot_ of guidance from me. Almost more helpful as a "rubber ducky" and for the fact that it kept me from deadlocking on analysis. That said, discussing problems and solutions with Claude often does keep things moving and sometimes reveals unexpected solutions.

If Claude could write the code directly unsupervised, it would go wild and produce a ton of garbage. At least if the code it writes in the browser is any indication. It's not that it's all bad, but it's like a very eager junior dev -- potentially dangerous!

Imagining a codebase that is one or two orders of magnitude larger, I think Claude would be useless. Imagining a non-expert driving the process, I think Claude would generate a very rickety proof of concept then fall over. All that said, I wish I had this tool when developing my previous game. Especially for a green field project, it feels like having access to the internet versus pulling reference manuals -- a big force multiplier.

Evidently also planning military training for all men…

EHG | Remote | Full-time

EHG is hiring! We're looking for a talented game dev to help lead development on Last Epoch. If you love ARPGs and want to work with a great team (and me!), check it out:

https://eleventhhourgames.bamboohr.com/careers/74?source=aWQ...

I made a top-down 2D survival horror game with doors that could be opened, closed, locked, unlocked, and peeked through. Zombies could open them when unlocked. Sincerely hope to never make a game with doors that aren’t proximity activated in the future!

+1 to design documents. Would add another reason they're useful: reducing miscommunication & misunderstanding between stakeholders. In my opinion, a tech document's goal is to uncover missed specs, invalid assumptions, broad architectural errors, if we're actually prepared to build (i.e. can we speak credibly to what/how), and finally to reduce miscommunication between various teams/disciplines.

I'll add I think tech doc review is just as important as writing stuff down. In my experience it's often done poorly. Doc should be ready ahead of time, sent to relevant people, read ahead of time, and a list of open questions and comments seeded before the meeting. The meeting should have a notetaker. The meeting should be shorter rather than longer. Have fewer people rather than more. The meeting should not be about reading the document top-to-bottom, but about answering open questions and confirming everyone is on the same page.

Programmers always want to automate content creation. I get it as I’m a coder and it’s a fun problem space. Plus creating content is super time and skill intensive. It’s really hard to get right in my experience. Kind of like trying to automate writing a novel…

OK I read the article. I'm very skeptical of this approach. I doubt we can actually uncover fitness functions that reliably maps to "fun", and I believe it would require huge engineering effort to keep the game "simulable." Their examples aren't convincing. What would be convincing is a full, complex, and _fun_ game using these techniques.

Also the article seems like an ad for their AI solution.