I’ve written before about how November 2025 was an inflection point for coding agents—the point where Opus 4.5 and GPT-5.1 crossed a tipping point that meant their respective coding agents …
For me, it depends on what is defined as an engine.
If an engine is a suite of prepackaged tools and editors—e.g. Unreal, Unity, Godot, etc.—then I dislike game engines.
If an engine is more like a library, or a framework—e.g. Raylib, SDL, LÖVE, etc.—then I very much prefer working with an engine.
I suppose the difference is akin to operating systems: on one hand, we have full suites of software, such as the BSDs and Godot; on the other, we have lots of seperate software, like Linux distros and SDL (+ the code and asset editors of choice).
My exception to all of this is writing ROMs for console emulators, and fantasy consoles like PICO-8.
Even though I like my jam games hand-rolled C or JS with assets made in paint (or laid out in text!) it’s a matter of taste. Even unity, which I could shit on at length, is fine.
Running around hosting purity tests about engines, or AI, only hurts creators who are just trying to make something by whatever means are available to them.
I have nothing against engines; I just don’t enjoy using them.
The trouble with jams is that the LLM is, legally, where the code came from, and said code should either count as an external asset or boilerplate, or the LLM needs to be considered a team member.
Also, legally, the “vibe-coders” or “operators” aren’t the creators of any AI-generated content.
I think there are legal tools which people can employ lawyers against in an attempt to hurt each other.
Indies don’t have access to those legal tools in the first place, so if anything, ‘It can’t be our intellectual property’ is likely a useful defense against large-scale aggressors, but ianal.
I agree with your last quote there, and that’s why I don’t use AI to create games for me ^^
It’s why I don’t use engines!
I couldn’t imagine using an engine for a jam game and getting what I want out of the jam.
But I can respect that decision, because for some folks it’s the vision, for others it’s the marketing, for some it’s making the assets.
There are a lot of pieces that go into making something that stands out.
For me, it depends on what is defined as an engine.
If an engine is a suite of prepackaged tools and editors—e.g. Unreal, Unity, Godot, etc.—then I dislike game engines.
If an engine is more like a library, or a framework—e.g. Raylib, SDL, LÖVE, etc.—then I very much prefer working with an engine.
I suppose the difference is akin to operating systems: on one hand, we have full suites of software, such as the BSDs and Godot; on the other, we have lots of seperate software, like Linux distros and SDL (+ the code and asset editors of choice).
My exception to all of this is writing ROMs for console emulators, and fantasy consoles like PICO-8.
My point is, engines are fine.
Even though I like my jam games hand-rolled C or JS with assets made in paint (or laid out in text!) it’s a matter of taste. Even unity, which I could shit on at length, is fine.
Running around hosting purity tests about engines, or AI, only hurts creators who are just trying to make something by whatever means are available to them.
I have nothing against engines; I just don’t enjoy using them.
The trouble with jams is that the LLM is, legally, where the code came from, and said code should either count as an external asset or boilerplate, or the LLM needs to be considered a team member.
Also, legally, the “vibe-coders” or “operators” aren’t the creators of any AI-generated content.
I also don’t believe in intellectual property.
I think there are legal tools which people can employ lawyers against in an attempt to hurt each other.
Indies don’t have access to those legal tools in the first place, so if anything, ‘It can’t be our intellectual property’ is likely a useful defense against large-scale aggressors, but ianal.