Making Video Games in 2025 (without an engine)
noelberry.ca388 points by alvivar 4 days ago
388 points by alvivar 4 days ago
3 anecdotes:
- For Talos Principle 2, Croteam switched from their own engine to UE5. The description was "It would be like attempting to sprint and catch up with a train that is already far down the track and accelerating even faster.". From a user's perspective, observe the graphics of Serious Sam Siberian Mayhem and Talos Principle 2: Same company, released at a similar time. Talos Principle (UE5) looks dramatically better than SS. (In-house engine)
- Jon Blow rolls his own engines (and lang), and releases games very slowly
- Expedition 33 recently released as a phenomenal game that leaned heavily on features in UE5 (Face/body, graphics, map/terrain gen etc.) They focused on the game itself, and let the engine do the heavy lifting... to a superb result.
From my own anecdotes in graphics programming: Producing a simple engine is easy. Producing something that's photorealistic etc is massively more difficult. Let along all the other things an engine provides for you. Modern games have so many complexities the engine abstracts out; we don't need to roll a new engine for each game or studio, each trying to have optimized netcode, human characters, photorealistic lighting, GUI map editors + terrain gen etc.
I use my own graphics engine for my scientific programs, but it has much simpler requirements than a game engine.
Not a gamedev, but I think a huge thing in a modern studio context is being able to parallelize effort. With UE5 you get authoring tools up and down the stack, so your artists and storyboarders and level designers can all start creating the world and setting up the scripted events and cinematics, even if key assets or behaviours aren't in place and are just placeholders. The developers are basically writing plugins into this system in collaboration with the design process.
Very different world from 20-30 years ago where the initial "game design" was happening in paint programs or even graph paper notebooks.
Did you play the Talos Principle Reawakened? They took a great performing game made with their own engine, re-released it with UE5, and now it performs like doggy doodoo.
Then again,UE5 has massive criticism leveraged against it- for pushing exotic and hyped up technology, that is not really production ready and demands you tailor your whole workflow around them. Held against last gen custom engines - ue5 almost always looks worse.
My experience with making your own engine vs using an off the shelf solution - the former can be viable and even superior on the condition that you know what you're doing. That is if you've built entire games or engines before, or have enough experience with the internals of one.
Otherwise it can be a dangerous fool's errand on which many projects go to die. My younger naive self can attest to this, he loved trying to build his own overly-ambitious engines. But he never finished any games.
Another thought if you do roll your own - keep it simple stupid. When your brain tells you that some amazing nested scene graph with integrated occlusion culling would be the coolest thing in the world, but you lack evidence that you'll actually need all that functionality, tell your brain that it's being stupid and just implement some kind of basic flat scene structure. You can always retrofit it later.
Also - study the code of the likes of Carmack. Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code.
Do not worship complexity.
These are the words of someone who has walked both roads!
I think the biggest mistake you can make is shifting your mindset from making a game to making a game engine. No, you still want to be dead set on making your game, you just don't have the ready-made building blocks from an off-the-shelf engine, so you have to make your own as you go, and only as needed. Personally, when I was working on my little game, I found it helpful to call the endeavour—just like Noel Berry in TFA—"making a game without an engine", rather than "making a custom game engine". I only really wrote the absolutely necessary plumbing that I needed for the game I was making, nothing more.
The same goes for software libraries in general, I think. Just make your program. Don't make an overly general library for something you won't need anyway. If the code proves useful for reuse, just factor it out after the fact and generalize as needed.
EDIT: Typos, wording
The way I phrase this to myself is ‘make the tool, don’t make the tool that makes the tool.’
On the contrary, making the tool that makes the tool is what I live for! My personal tech stack has benefited incredibly from this practice and fuels my startup, though it did take me 20 years of slow iteration to get here.
that's really dope, but i'm not sure if it'll work out the same way nowadays. i think we're in a weird stage where momentum REALLY matters in a way that it didn't 10 years ago or 5 years down the line (probably)
Well I’m not anti ;) … I just mean if your goal is to make the thing and you’re sure you need a tool to do it, watch out for the temptation to make the tool that makes the tool, which is the LONG way around, as OP was saying
> Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code
Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple.
Ironically one of the things that the Quake engine relies on is clever culling. Like Doom, the level is stored in a pre-computed binary space partition tree so that the engine can uniquely determine from what volume you're in what the set of possibly visible quads is (if my memory is correct, oddly the engine uses quads rather than triangles) AND how to draw them in reverse order using painter's algorithm, because the software renderer doesn't have a z-buffer.
https://www.fabiensanglard.net/quakeSource/quakeSourceRendit...
The BSP partitioning used to take several minutes to run back in the day.
Anyway, the point I was trying to make was that Carmack used a few, clever, high-impact techniques to achieve effects, which were also "imperfect but good enough".
If you're not Carmack, don't over-optimize until you've run a profiler.
> Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple.
Not the best example. That snippet was in use at SGI for years and actually written by Gary Tarolli. Quake's optimization was mostly done by Michael Abrash.
The original id engines were also famously inflexible. They fit the mold of "developing an engine, not a game" to a T. What you saw them do was all they could do. Look at how much Half-Life needed to add to be viable. idtech3 also only broke out of its niche because Ritual and Infinity Ward heavily modified it and passed it around. There's a good reason the engine-based ecosystem is so prominent now.
> (if my memory is correct, oddly the engine uses quads rather than triangles)
I'm also working off a near 30-year-old memory but I recall quads not being unusual around this time. I remember a preview of Tomb Raider 3 in Official Playstation Magazine making a big deal out of the updated engine using triangles instead of quads to draw things. This was around 1998, so a couple of years after Quake came out.
I see making a game engine as the illusion of progress on making a game. Making a game engine is fun and relatively easy. You have a check list of things to do. Each of them the solutions are relatively well known. so you do them and make tons of progress. You get a window open, then you get a triangle up, then you get a texture loaded, then you get some basic text for debugging, then you read the keyboard for input, etc etc. each day new stuff comes up and you think you’re making progress but really you haven’t even started making the game , you’re just reproducing what you could have already had if you’d started with an existing engine.
Then you start it hit the more tedious stuff. loading animated characters, blending animations on selective subtrees of a character hierarchy. Making a level editor. Adding quality of life feature to it like undo. Etc…
I’m not saying you shouldn’t do this. It’s fun to do. just don’t delude yourself that that’s making progress on your game. It’s instead making progress on a game engine. That’s a different thing.
I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them. I wouldn't do it again.
All that said, some nuance. If the game you are making is simple for some defintion of simple, Celeste, Dead Cells, Geometry Wars. Then making your own engine isn't much work and there maybe some benefits.
On the other hand, see all the tiles made with engines. Silksong is Unity. A Short Hike is Unity. Blue Prince is Unity. Valheim is Unity. Peak is Unity. Dredge is Unity. You don't need to make your own engine to make an indie game.
Randy (funny gamedev guy from YouTube) said in a recent video that he realized he'd spent the last ten years making engines to avoid the creative terror of action making a game. I'm paraphrasing slightly, but that's what it came down to.
"I thought if I made a really good engine, making a game would be the easy part!" I had similar thoughts when I was younger. Surely if I just upgrade my tools, the hard part will become the easy part!
Jonathan Blow says making engines is easy, because enginedev only takes a relatively small part of development — the game itself takes way more time and energy.
So his argument is, in the grand scheme of things, the engine is not that much work. (Since you're gonna spend ten years working on the game anyway, of course ;)
Jonathan Blow also makes games at a very slow pace; e.g. his Sokoban games. There are other factors at play, but his pace is consistent with the speed drawback of rolling your own engine.
And the thing usually is that what you want from your engine is the flexibility to be able to change things around easily so you can iterate and experiment on the game design itself. Sometimes a custom engine can give you that (especially if you're going off the beaten track) but often the tooling around the off-the-shelf engines is much better for it.
That's also why the Handmade Hero series took more than 600 episodes to eventually go nowhere.
That’s also why 99% of people building games with Unity or Unreal never get anywhere by themselves or just produce asset-flip slop, and then complain on Reddit about marketing being hard.
Programming an engine requires dedication, but pretty much every other area in gamedev require similar dedication to get to an acceptable result.
> I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them.
Solo? Or part of a team?
Yeah don't end up like me with a folder full of library code, "tests", "prototypes" and a dozen implementations of the Tiled API but no game.
For certain personality types I think making an engine can make it very easy to get distracted and wind up in the weeds of something you don't actually need, overoptimizing, fence-painting etc. Using an engine can help with self-discipline and focus on the end rather than the means, although then you need to make sure you don't just wind up with a ton of mostly finished tutorial projects and no game.
I believe most of programmers who dive into game dev are actually interested in game engine and tools development.
when Quake was being written, it was pushing the level of managable complexity at the time.
they used NeXT workstations to develop it, the programming tools on PCs were too weak for such a project
today it might look simple, but it's easy to say that when you open it in VS Code and have Intellisense, autocomplete, go to definition, ultra fast compilers, tons of RAM, and google for everything
"Also - study the code of the likes of Carmack. Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code."
Also says something about the accumulation of complexity. At that time Carmack (and his team) were able to create a state of the art engine in a few years. Now consider the task today, if you were to create a state of the art engine today it'd take tremendously more work.
An interesting thing is I think a lot of it's caused purely by the graphical fidelity. For instance an animated character back then was just a key framed polygon soup - compare that with the convincing humanoids games have now.
And yet often the actual gameplay code itself may only be 2x to 3x more complicated then the days of old.
I think of counterstrike for instance - it's still just guys shooting guns in a constrained arena.
AI may change the game here. Most games are slop coded by humans anyway as the industry prioritizes speed and dead lines over code quality.
So having AI build the slop instead of a human seems to make sense. I really wonder how AI is changing the gaming industry.
The articles author strangely left AI out of what he wrote. While I know a lot of HN readers are traditional and love the old way of doing things I don’t know how much longer that way will last.
It’ll last as long as there are humans who like making things themselves.
That’s what they said about assembly coders.
Guess what, there are still people who write code in assembler.
For plenty of reasons there are lots of programmers who still need to know how to code in assembly, read assembly, etc.
I've been working on Metropolis 1998[1] for +4 years now. Custom C++ engine built with a modified version of SFML 2.5 and SQLite.
Creating my own engine was both a personal and strategic decision for me. I was really worried about running into performance issues with generalist engines, and I did not want the friction of working with someone else's mental model. Pretty sure that friction would have caused so much burnout for me. There's also the long payoff of operating in an environment that you understand top to bottom.
I ignored all the advice about making smaller games first, creating an engine first, etc. Metropolis 1998 is my first game and so far it's working out just fine. But your mileage will vary.. I started development with 10+ years of software experience and fond memories of Rollercoaster Tycoon and SimCity 2000/4.
I only add what I need. There's no level/scene editors (outside of the game being one itself :P ). No scene graphs. Shaders are coded by hand. Right now the entire game is about 45MB.
[1] https://store.steampowered.com/app/2287430/Metropolis_1998/
Curious how long you spent on the "engine" vs just writing the game? Based on the stuff I see on Steam you're pretty far along. I see it's Windows only which makes sense for your goals (and honestly seems very easy to run in a VM.) Was it easier to target and test for a single platform?
(Also thanks this is exactly the kind of game I'm into.)
A few weeks ago I was curious about this too:
- - Total days - 1631
Engine: 610
Pathing / Roads: 287
Features: 477
Marketing: 45
Burnout: 130
Other: 82
You're welcome!
Thanks for the breakdown, I'm also sending the game to friends who like this genre of game so hope you get some downloads!
Looks fantastic! Growing up on RollerCoaster (+Transport) Tycoon and SimCity myself, this is exactly the kind of project I'd dream about building, if only I had your dedication!
Your screenshots look dangerous i.e. I'm constantly seeking some hiding aliens there
> Our game, Celeste
I was really enjoying reading this piece until I read the above, then I realized I am reading for a big developer, the maker of, Celeste [1]. I am definitely adding this to my list of favorite articles about making games.
Also, you may want to check a previous discussion from nine months ago (573 points, 246 comments ): https://news.ycombinator.com/item?id=44038209
_____________
Better link to Itch (<https://maddymakesgamesinc.itch.io/celeste>) than Steam, Itch by default only takes a 10% cut instead of 30%.
But Celeste came out in 2018. How is it relevant to 2025 as suggested in the title?
Also, pretty sure it was a small indie team rather than a “big developer”
It's the same developer as Celeste, but in the article they talk about "city of none" [0], that's a yet unreleased game they're working on right now.
--
0: https://cityofnone.com/I think Celeste was popular enough in the indie space to get "big developer". To put some words in OP's mouth, its not "Big Developer" as in a large studio. But "Big Developer" as in well known and acclaimed.
In the article they make that 2025 is a tipping point where open source frameworks and libraries "just work", making speedy, fun development possible without needing to fight the clunkiness of heavyweight engines.
And any new stuff regarding Celeste or from their devs will forever be relevant to me! Highly recommend to any who haven't played it.
How is it not relevant? Celeste wasn't exactly a pinnacle of bleeding edge technology when it came out.
If I remember correctly it was a team of 2.
I thought Celeste was a solo project of Maddy Thorson [0] before reading this piece.
0: https://maddymakesgames.com/
Fans of Celeste will almost certainly enjoy the local multiplayer game Towerfall by the same developers.
Just want to +1 this. It is a game so good I bought (and beat) it twice, once on Switch and once on Steam.
on that theme it reminds my of the Pico-8 community (although technically it is an engine but you dont need to do engine programming even for generating music!!)
compiled a personal webpage to play with mobile controls and a javascript engine to play the pico-8 games and i love the celeste port on that!
A lot of modern games ‘feel’ the same to me now. Same sort of lighting, blur.. even the texture loading and pop in. They all sort of blend into one mess.
I liked when games all felt very distinctly different and I feel like part of that was that they all varied on ‘engine’
That's the Unity / Unreal look. I can see why that might be a problem, but I actually really like the Unreal 4 look and think fondly about many games using that engine that I like. The way it handles lighting, fog effects and color in general makes me feel "I'm home".
This is why I am impressed by the works of Enhance Games. Their titles Tetris effect, Rez Infinte (UE4), Humanity and Lumines Arise (Unity) dont show any of the usual traits of those engines. They have done a great job of avoiding the defaults of these engines and crafting something new with the engines as the base foundation.
But I suspect that when you have multiple years to build Tetris, you can spend a lot of time crafting your own style.
that's because fundamentally, they are the same. Different assets and scripts, same internals / foundation.
After I read the title, I fully expected this to be about writing games using AI. But no, actually there is no mention of AI to be found in the text, not even in the "Miscellaneous Thoughts" section, which seems to be mostly answers to "why don't you use X?" questions. Refreshing...
The author is Noel Berry, creator of Celeste. They don't shout about it, but with that pedigree, I'm confident they'll be staying well away from AI.
Why would a game development pedigree correlate with rejecting AI? As Carmack said:
> AI tools will allow the best to reach even greater heights, while enabling smaller teams to accomplish more, and bring in some completely new creator demographics.
Carmack isn't exactly a neutral observer here, his main gig since quitting VR has been as the founder of a VC-backed AI startup. He has a clear financial interest in joining the chorus of AI boosters.
A less cynical interpretation of his actions would be that he's never shown to be motivated by money and is working on technology that interests him and that he can make an important contribution to
[flagged]
Are you saying Carmack isn't a "talented and successful developer"?
I hate to say it but honestly, kinda, yeah... I do think that. Has he done anything significant since the early 1990s? All I've known him for since then is wasting a bunch of years spinning wheels at a virtual reality toy company and posting on Elon Musk's child pornography platform. I would not look to Carmack for tech inspiration in 2026, personally.
Slop is a garbage in, garbage out deal - in the hands of a competent developer who can review the changes, AI generated code is fine.
Or they'll take a look at what, if anything at all,they can use in their workflow as a useful tool not a magic solution.
No need to brag about that.
They don’t seem to enthusiastic: https://bsky.app/profile/noelfb.bsky.social/post/3maa3m5x4vs...
> can use in their workflow as a useful tool not a magic solution.
Like what? If you can already program your game and create art for it, what is it going to be doing?
People are so obsessed with using AI stuff for the sake of it, it’s nuts
I don't use AI for the sake of it, I use it where and when it is useful. For example:
1. advanced autocomplete -- if you have or paste the structure of a JSON or other format, or a class fields, it is good at autocompleting things like serialization, case statements, or other repetitive/boilerplate code;
2. questions -- it can often be difficult to find an answer on Google/etc. (esp. if you don't know exactly what you are looking for, or if Google decides to ignore a key term such as the programming language), but can be better via an AI.
Like all tools, you need to read, check, and verify its output.
Genuine question re #1: does your text editor not already do that?
Text editors/IDEs have simple autocomplete and the ability to do some expansion, e.g. a for loop with placeholders to fill in. Those work and are still useful.
JetBrains also has local line-based LLM models for various languages.
With the LLM-based autocomplete it a) generally autocompletes more code at once, and b) will often pick up on patterns in the existing code. E.g. if you have a similar method, list of print/string buffer write statements, or other repetitive code in the file it will often use that as a model for the generated code.
The JetBrains local autocomplete is hilarious but occasionally useful. I find it really hit and miss in terms of when it will decide to autocomplete and whether it will exhastively complete all elements, miss some out or get itself into a loop over several.
That sure sounds like you're describing customizable snippets, which AFAIK every major editor supports?
Customizable snipping is a feature editors support (which I mentioned as they are related/similar to what the AI is doing), but is different to the AI autocomplete behaviour.
If I have a JSON structure, I can paste that into the file as a comment, e.g.:
# {"foo": 1, "bar": "test", "baz"}
@dataclass
class FooBar:
foo:
@dataclass
class FooBar:
foo: int
bar: str
baz: int
def __str__(self):
return f'Foo(foo={self.foo}, bar={self.bar}, baz={self.baz})'
class Foo(Base):
__tablename__ = 'foos'
bar_id: Mapped[int | None] = mapped_column(ForeignKey('bars.id'), default=None)
bar: Mapped[Optional['Bar']] = relationship()