[HN Gopher] Making Video Games in 2025 (without an engine)
       ___________________________________________________________________
        
       Making Video Games in 2025 (without an engine)
        
       Author : alvivar
       Score  : 391 points
       Date   : 2026-02-27 04:38 UTC (3 days ago)
        
 (HTM) web link (www.noelberry.ca)
 (TXT) w3m dump (www.noelberry.ca)
        
       | rob74 wrote:
       | 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...
        
         | oneeyedpigeon wrote:
         | 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.
        
           | Vespasian wrote:
           | 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.
        
             | dwroberts wrote:
             | > 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
        
               | segh wrote:
               | I can do long division manually but I still reach for a
               | calculator.
        
               | dwroberts wrote:
               | Do you also spend a lot of time maximising calculator
               | utilisation in other places? Maybe trying to write
               | letters with it or composing music with it?
        
               | hjkl0 wrote:
               | Won't you get much better results trying to maximize
               | utilization of some sort of LLM? For many people, you'd
               | get faster and better results trying to optimize for LLMs
               | than for any standard word processor or music composition
               | tool.
        
               | anonnon wrote:
               | > but I still reach for a calculator
               | 
               | Does the calculator give you a slightly different answer
               | each time, even with the same inputs?
        
               | rhdunn wrote:
               | 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.
        
               | bandrami wrote:
               | Genuine question re #1: does your text editor not already
               | do that?
        
               | socalgal2 wrote:
               | Without ai my text editor auto completes letters into
               | existing identifiers or adds a closing brace
               | 
               | With ai it add several lines of code at once as soon as
               | it thinks it recognizes a common pattern.
               | 
               | It's not perfect and it can get in the way but it's
               | amazing when it guesses right and spits out the next 3-4
               | lines I would have typed
        
               | bandrami wrote:
               | I'm trying to think of a text editor that doesn't support
               | customizable snippets and templates, and failing
        
               | ses1984 wrote:
               | Those two things aren't the same at all, they're so
               | different it's hard to believe you're not being
               | intentionally obtuse.
        
               | bandrami wrote:
               | I mean, in the sense that customizable snippets are more
               | flexible and can cover a wider variety of use-cases, I
               | guess?
        
               | bluefirebrand wrote:
               | Personally I find this workflow is jarring. I get into
               | flow typing code and then the AI autocompletes the next
               | four lines on a tab input. Now my flow is screeching to a
               | halt because I have to switch from flow mode to review
               | mode to make sure it actually autocompleted what I wanted
        
               | rhdunn wrote:
               | 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.
        
               | bandrami wrote:
               | That sure sounds like you're describing customizable
               | snippets, which AFAIK every major editor supports?
        
               | bubblewand wrote:
               | Sitting here on the sidelines having never configured
               | snippets or macros or any of that in any of my editors,
               | which I could have done like 30 years ago but never
               | bothered in all this time, doing quizzical-dog look at
               | all these people thrilled about LLMs.
               | 
               | I guess they might finally get me to use those things
               | since they take the "configuring" and "remembering
               | shortcuts" part out, but so much of this doesn't look new
               | at all. Super old, actually.
        
               | rhdunn wrote:
               | 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:
               | 
               | and the AI will/can autocomplete/generate that to:
               | @dataclass         class FooBar:             foo: int
               | bar: str             baz: int
               | 
               | using the JSON example. Then if you type:
               | def __str__(self):
               | 
               | the AI could then contextually generate, e.g.:
               | return f'Foo(foo={self.foo}, bar={self.bar},
               | baz={self.baz})'
               | 
               | Or if you have a SQLAlchemy model:
               | class Foo(Base):             __tablename__ = 'foos'
               | bar_id: Mapped[int | None] =
               | mapped_column(ForeignKey('bars.id'), default=None)
               | 
               | typing `bar:` the AI can autocomplete:
               | bar: Mapped[Optional['Bar']] = relationship()
               | 
               | picking up that you have a `Bar` class in the file.
               | Especially if you have other similar id/object
               | definitions in the file.
        
               | bandrami wrote:
               | Right, it's a less-flexible paste macro you don't
               | actually have control over. _shrug_
        
               | meheleventyone wrote:
               | 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.
        
               | Cthulhu_ wrote:
               | Speaking for myself (who can program and all that), AI
               | solves some of the tedium in my day job (building UI
               | components). Most of that work nowadays is boilerplate.
               | 
               | But at the moment it's also helping me solve more complex
               | issues with building applications - it's JS, so you can
               | imagine how complex it can be.
               | 
               | I yearn for a simpler workflow to be honest, I don't want
               | to rely on SO or LLMs to solve build issues. I want to
               | work in Go but there's only a handful of companies using
               | it in my country, plus my CV basically says I mainly did
               | front-end in the past ~15 years.
        
               | truetraveller wrote:
               | "People are so obsessed with using AI stuff for the sake
               | of it, it's nuts".
               | 
               | This is a GREAT observation. Thank you!
        
             | tumdum_ wrote:
             | They don't seem to enthusiastic: https://bsky.app/profile/n
             | oelfb.bsky.social/post/3maa3m5x4vs...
        
           | MasterScrat wrote:
           | 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.
        
             | jsheard wrote:
             | 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.
        
               | indy wrote:
               | 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
        
       | kleiba wrote:
       | Discussed before: https://news.ycombinator.com/item?id=44038209
       | 
       | (246 comments)
        
       | rimmontrieu wrote:
       | Nice article, engines are bloated and introduce so many
       | overheads. If you don't intend to ship any AAA games, consider
       | investing your times to learn code-first game frameworks like
       | libGDX, MonoGame, love2d,... or even lower level stuffs like SDL,
       | bgfx, opengl which are good enough for almost any cases. A bit
       | higher learning curve is expected but it won't hide anything from
       | you, or bury you under tons of bloated abstractions.
        
         | JoeyJoJoJr wrote:
         | I'd highly recommend going with SDL if it's 2D. IMO libraries
         | like MonoGame, Love2D, LibGDX only offer small conveniences
         | over SDL with big negative tradeoffs, sacrificing portability,
         | quality of libraries, and conventions. The downsides of using
         | C++ are now heavily mitigated with the use AI tools.
         | 
         | I could never jell with C++ until I had Cursor hold my hand
         | (especially around the build system), and now I feel like I am
         | developing games with a razor sharp knife that I could never
         | before access. The patterns associated working directly with
         | memory suddenly clicked and now it's the only I want to build
         | games.
        
           | tripledry wrote:
           | Similar, I also went back to mainly C++ and Raylib now that I
           | can delegate the "boring" stuff to AI, never had any issues
           | with programming in C++ it was mainly adding dependencies and
           | builds I hated (configuration).
           | 
           | I still don't use it (AI) for the game programming as it
           | sucks the joy out of it for me. Especially when AI usage is
           | currently being pushed hard at work.
        
           | raincole wrote:
           | I'm actually building my own mini-engine with SDL_GPU. It
           | works ok so far. I'm quite confident that it's capable enough
           | to replicate most of Unity's URP features (except the shader
           | graph as I don't plan to expose such an interface for
           | artists).
           | 
           | But I haven't reached to the more tedious parts, like doing
           | skeleton animation on GPU and testing cross platform (SDL
           | should be naturally cross platform, but I never tested
           | it...), etc. The most tedious part, imo, is to build your own
           | 3D scene editor.
           | 
           | At very least I can say SDL has reached a passable state for
           | 3D. It doesn't support some modern features like bindless
           | though.
           | 
           | And one doesn't need to stich with C++ if they don't want to.
           | SDL is pure C and if your favorite language can call foreign
           | function it's not that hard to make it work with SDL.
        
         | simooooo wrote:
         | Nobody seems to consider that doing it yourself, requires you
         | implement it at least as efficiently as the commercial engine
         | did, otherwise you're just creating a worse-performing
         | implementation that seems to behave just like a bloated engine
         | does.
        
           | flohofwoe wrote:
           | The big difference is that the big game engines have to cover
           | all sorts of genres and scenarios, which often results in
           | bloated "jack of all trades master of none" code compared to
           | engine-layer code that's highly specialized for exactly one,
           | or few very similar games.
        
             | Joel_Mckay wrote:
             | If building a custom commercial game engine these days... A
             | team is 100% focused on the wrong problem, as the game-play
             | content is what sells. Customers only care about game-
             | engines when broken or cheating.
             | 
             | Godot, Unreal, CryEngine, and even Unity... all solve edge-
             | cases most don't even know they will encounter. Trying
             | something custom usually means teams simply run out of
             | resources before a game ships, and is unlikely stable on
             | most platforms/ports. =3
        
               | flohofwoe wrote:
               | Many of those "edge cases" lurk in the platform
               | abstraction layer (driver or OS bugs which needs to be
               | worked around), and many of those problems are also taken
               | care of in cross-platform wrappers like SDL (and for 2D
               | games this is completely sufficient, you don't need UE5,
               | Unity or Godot to render a couple thousand sprites and
               | play music and audio effects).
               | 
               | But even more complex custom/inhouse engines are usually
               | not written from scratch, those are often mostly glued
               | together from specialized middleware libraries which
               | solve the tricky problems (e.g. physics engines like
               | Jolt, vegetation rendering like SpeedTree, audio engines
               | and authoring tools like FMOD or WWise, LOD solutions
               | like Simplygon, etc etc...)
        
               | zetanor wrote:
               | >Customers only care about game-engines when broken or
               | cheating
               | 
               | Most game engines _are_ broken by default. Modern
               | customers just aren 't very discerning ("It's for the
               | pigs. Pigs eat slop."). You can feel holes and rough
               | edges in the vast majority of new releases, including AAA
               | titles.
               | 
               | Unreal is the worst for this and Unreal-based games
               | almost always have two things in common: a very
               | particular, soft, sticky and unresponsive look & feel
               | (often alleviated but never fully corrected by turning
               | off some combination of motion blur, AA and VSync), as
               | well as a UI that mishandles mouse pointers.
               | 
               | Unity devs seem to rely on a (more diverse but still
               | quite) small pool of subsystems and renderers; possibly
               | some mix of baseline and Asset Store components. This
               | gives each Unity game a specific subset of flaws from a
               | wider common pool. That is, you can tell that game A uses
               | the same movement subsystem as games B and C (but not D),
               | that game B uses the same UI subsystem as games C and D
               | (but not A), and that game D uses the same rendering
               | subsystem as games A and B (but not C).
        
               | Joel_Mckay wrote:
               | In my humble opinion, the difference between good and
               | great was often whether the Shaders and pre-Baked work
               | was done well enough to go unnoticed.
               | 
               | Forcing devs to use a mid-grade GPU also tends to reduce
               | chasing performance issues later. For example, high
               | frame-generation artifacts users often perceive as
               | "floats" or "wobbly". =3
        
           | Levitating wrote:
           | That's not necessarily true, engines also create overhead. If
           | you create your own engine, you can tailor it exactly to your
           | use case.
           | 
           | Besides not all games need performance, I have been working
           | on a clone of the original elite game using SDL. It gets 6000
           | fps easily.
        
         | Cthulhu_ wrote:
         | SDL is used in Factorio, which IMO is the best showcase of what
         | is possible if you go all-in on e.g. C++ when it comes to
         | performance, both in terms of what is rendered on screen and
         | the mind-blowing numbers of what your factories are doing.
        
           | rahkiin wrote:
           | And most gameplay is written in Lua
        
         | rimmontrieu wrote:
         | For more context, I've developed over 200 games[0] using libGDX
         | and threejs. I've learnt so much from working with code-
         | oriented frameworks that are closer to the system APIs. I can
         | never imagine if I could do all that in today full-blown game
         | engines in term of effectiveness and development speed.
         | 
         | [0]: https://ookigame.com
        
         | Froztnova wrote:
         | I've been building some stuff with love2D for a while now, more
         | a hobby than anything else, and I've really enjoyed the
         | process. Nothing really crazy, just a 2D platformer.
         | 
         | I think that if I were making something in 3D or I were more
         | serious I'd use an engine, but I've found that I get more
         | satisfaction from building tools than from learning how to use
         | tools that other people have built.
        
         | racefan76 wrote:
         | How does one pick a tool/framework from these options when
         | starting out with game development? I've seen the sentiment of
         | "just pick anything" but the amount of choices is giving me
         | some analysis paralysis.
        
       | bob1029 wrote:
       | The primary thing I'm going for in a commercial engine is
       | platform targeting and stability. Some of the defaults are
       | certainly "bland", but that ensures I can actually ship this
       | thing to a meaningful % of the available market. Unity's coverage
       | is so consistent that I've been debating using it for non gaming
       | applications. There aren't many cross platform ecosystems that
       | work this well.
        
         | bizzletk wrote:
         | What are some things that you'd build with Unity that aren't
         | games?
        
           | bob1029 wrote:
           | User interfaces for complex physical plants.
           | 
           | https://en.wikipedia.org/wiki/Digital_twin
        
             | dwattttt wrote:
             | A storied history:
             | https://en.wikipedia.org/wiki/SimRefinery
        
           | voidUpdate wrote:
           | Not OP, but at PSJOB, I use Unity most of the time making
           | demo and sales apps for clients to use at shows. The fact
           | that it can build for basically every common platform and
           | (most of the time) not need any special considerations for
           | that makes it ideal for us. Sure, we could write web apps or
           | something, but that's a different department.
           | 
           | I'm also not sure if it's still in the installer, but it used
           | to ask you what you would be using unity for, and I don't
           | remember most of the options, but one of them was "military
           | simulations" or something like that, so they are aware of the
           | possibility
        
         | Zarathruster wrote:
         | Just a polite heads-up in case you weren't aware: for non-game
         | usage of Unity, the licensing situation is... a little
         | complicated. That goes for the engine as well as a lot of the
         | stuff I've seen in the Asset Store. Just a thing to bear in
         | mind, and potentially a reason to use a different engine.
        
           | bob1029 wrote:
           | It's not _that_ complicated.
           | 
           | The pro license at ~$2k/year per seat is all you need unless
           | you are making a shitload of money. In which case, you are
           | going to pay ~5k/year per seat.
        
             | Zarathruster wrote:
             | Unless you intend to build "industrial real-time 3D
             | applications like employee training, product configurators
             | and embedded systems." In which case you must use the
             | Industry License, for which you must pay "Custom pricing."
             | 
             | I last looked into the matter when considering RFP's for
             | government contracts for VR software. Didn't feel like
             | haggling with Unity's sales reps, especially since the
             | government hasn't been the greatest client of late.
             | 
             | All of this is before you get to the Asset Store, which
             | largely seems to assume that gamedevs are the customers.
             | I'd rather not re-read the license agreement for every
             | asset I've bought, but I know for certain that a number of
             | them are explicitly games-only.
        
       | redbell wrote:
       | > 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
       | 
       | _____________
       | 
       | 1. https://store.steampowered.com/app/504230/Celeste/
        
         | iNic wrote:
         | Just want to +1 this. It is a game so good I bought (and beat)
         | it twice, once on Switch and once on Steam.
        
         | hjkl0 wrote:
         | 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"
        
           | PacificSpecific wrote:
           | 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.
        
           | tecleandor wrote:
           | 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/
        
           | Murfalo wrote:
           | 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.
        
           | ecshafer wrote:
           | 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.
        
         | kelvinjps10 wrote:
         | I also reached the same conclusion, it feels wholesome
        
         | tmtvl wrote:
         | Better link to Itch
         | (<https://maddymakesgamesinc.itch.io/celeste>) than Steam, Itch
         | by default only takes a 10% cut instead of 30%.
        
         | wasting_time wrote:
         | 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.
        
       | imtringued wrote:
       | >I often find the default feature implementations in large
       | engines like Unity so lacking I end up writing my own anyway.
       | Eventually, my projects end up being mostly my own tools and
       | systems, and the engine becomes just a vehicle for a nice UI and
       | some rendering...
       | 
       | I honestly don't see anything wrong with using the engine for its
       | UI and "some rendering" kind of sweeps a lot of the complicated
       | 3d light handling under the rug. I think the biggest mistake
       | large engines have made is baking in features as first class
       | citizens instead of those features being part of a standard
       | plugin you could have written yourself from scratch once you
       | reach that stage.
       | 
       | I've contemplated building my own editor UI, but after four weeks
       | I realized that I'm just rebuilding the same UI structure you see
       | in FreeCAD, Blender, Isaac Sim, Godot, etc. There's always a 3D
       | viewport, there's a scene tree and there is an inspector panel
       | for looking at the properties. So why not just use the Godot
       | editor as a UI and provide my own custom nodes? By the time I've
       | outgrown the training wheels, I've spent months working on the
       | actually differentiating features.
        
         | nkrisc wrote:
         | > I honestly don't see anything wrong with using the engine for
         | its UI and "some rendering" kind of sweeps a lot of the
         | complicated 3d light handling under the rug. I think the
         | biggest mistake large engines have made is baking in features
         | as first class citizens instead of those features being part of
         | a standard plugin you could have written yourself from scratch
         | once you reach that stage.
         | 
         | Godot is more or less built that way. The entire node system is
         | an abstraction over the various "servers" and you can even
         | completely forgo it if you want, providing your own MainLoop
         | implementation (instead of the included SceneTree
         | implementation of MainLoop) and then just use the servers
         | directly.
         | 
         | A lot of the editor features are also implemented as plugins.
         | It's been very easy turning the Godot editor into a custom
         | editor for my game by writing some simple plugins
        
       | abcde666777 wrote:
       | 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!
        
         | spppedury wrote:
         | 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
        
         | pjc50 wrote:
         | > 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.
        
           | scott_w wrote:
           | > (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.
        
           | BearOso wrote:
           | > 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.
        
         | samiv wrote:
         | "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.
        
           | direwolf20 wrote:
           | But you could create Quake.
        
             | andai wrote:
             | Quake is peak graphics anyway. We hit diminishing returns
             | after that ;)
        
           | abcde666777 wrote:
           | 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.
        
         | socalgal2 wrote:
         | 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.
        
           | andai wrote:
           | 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 ;)
        
             | kleiba wrote:
             | That's also why the Handmade Hero series took more than 600
             | episodes to eventually go nowhere.
        
             | rcxdude wrote:
             | 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.
        
             | whstl wrote:
             | 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.
        
             | the__alchemist wrote:
             | 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.
        
             | jz391 wrote:
             | And, of course, the next level of procrastination is to
             | develop your own programming language, which you will use
             | to write the engine to use in creating the game :-)
             | Definitely hats off to Jon for pulling it off - he had a
             | lot of focus and some previous experience - and it also
             | helps to have re$ource$ from past successful games. For
             | many of us, the lure of developing better tools, rather
             | than the end product, proves to be too strong to resist. At
             | least Jon stopped short of developing own OS :-)
        
           | krapp wrote:
           | 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.
        
           | andsoitis wrote:
           | > I've shipped 18 games, 4 of them AAA. I wrote the engines
           | for most fo them.
           | 
           | Solo? Or part of a team?
        
             | ses1984 wrote:
             | Can you name one solo dev AAA game let alone four?
        
         | spiffyk wrote:
         | 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
        
           | doctorhandshake wrote:
           | The way I phrase this to myself is 'make the tool, don't make
           | the tool that makes the tool.'
        
             | herpdyderp wrote:
             | 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.
        
               | doctorhandshake wrote:
               | 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
        
               | performative wrote:
               | 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)
        
           | __xor_eax_eax wrote:
           | YAGNI still undefeated in 2026
        
         | zerr wrote:
         | I believe most of programmers who dive into game dev are
         | actually interested in game engine and tools development.
        
         | threethirtytwo wrote:
         | 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.
        
           | agentultra wrote:
           | It'll last as long as there are humans who like making things
           | themselves.
        
             | threethirtytwo wrote:
             | That's what they said about assembly coders.
        
               | agentultra wrote:
               | 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.
        
       | Madmallard wrote:
       | Has he dealt with some of the more challenging problems in game
       | dev that engines help a lot with? Like... multiplayer netcode.
       | 
       | Seems like if you're doing this for a hobby or solo/small team
       | then maybe it's reasonable.
       | 
       | For most people where they want to be a game dev but they
       | probably will just work in industry, it seems like learning the
       | major engines to competency cannot be ignored.
        
         | rob74 wrote:
         | Well yeah, he's working with a pretty small team, and quite
         | successfully:
         | https://en.wikipedia.org/wiki/Celeste_(video_game)
         | 
         | I would say that one of the "Miscellaneous Thoughts" at the end
         | of your article answers your question pretty well:
         | 
         | > _I need only the best fancy tech to pull off my game idea
         | 
         | Then use Unreal! There's nothing wrong with that, but my
         | projects don't require those kinds of features (and I would
         | argue most of the things I do need can usually be learned
         | fairly quickly)._
        
         | jesus_666 wrote:
         | You should use tools that are appropriate to what you intend to
         | achieve. If you want to make a 3D game then Unreal, Unity, or
         | Godot are appropriate choices. If you want to make a 2D game
         | then something like MonoGame might make more sense than Unreal.
         | You don't need highly refined netcode if your game never needs
         | to exchange data in realtime.
         | 
         | Heck, I've seen someone build a visual novel-type game with
         | WinForms. That was actually a sensible choice for the game's
         | presentation and interaction needs.
         | 
         | Of course if you want to become a game dev at a studio then you
         | should be competent with whatever the studio uses (or something
         | comparable so you can pivot to their stack). If you only want
         | to make your hobby project and maybe publish it later it
         | doesn't matter if your engine is Unreal, MonoGame, RPG Maker
         | 2000, or vanilla JS/DOM.
        
         | raincole wrote:
         | > that engines help a lot with? Like... multiplayer netcode.
         | 
         | Rust (the top 10 most downloaded game ever on Steam) is built
         | with Unity. However they ended up to write their own netcode
         | anyway. Of course Unity isn't known for the best netcode, but
         | how much an engine helps is often overstated. Genshin even
         | bought Unity's source code to customize it.
        
           | voidUpdate wrote:
           | Unity used to have a pretty good netcode implementation, but
           | then they ripped it out in newer versions and still don't
           | really have a good replacement for it
        
             | raincole wrote:
             | Unity used to have _____ but now they don't.
             | 
             | This is the mantra of the past decade of game dev.
        
             | Zarathruster wrote:
             | Interesting. I'm new to this and trying to get a grasp of
             | the situation but there's a ton of noise.
             | 
             | What's wrong with Netcode for GameObjects, and what are the
             | odds I'll regret going with it?
        
               | voidUpdate wrote:
               | I mean, I dont hate netcode for gameobjects, but
               | generally I prefer to have the application just set up
               | some sockets for me and I'll handle the rest myself,
               | which you can do in NfG, but I've not used it too much.
               | There was a really long gap between having working
               | netcode stuff, and I wrote what I felt was a really nice
               | layer over the top of the old LLAPI for a project I was
               | going to work on, and then they immediately deprecated
               | it.
               | 
               | Im sure NfG is fine
        
         | grian42 wrote:
         | multiplayer netcode isnt overly difficult to write unless
         | you're at the highest lvl of complexity lol. it's not a black
         | box, it's just transferring bytes around efficiently and
         | keeping track of state, your "netcode" can literally just be
         | bare tcp (+ssl), validation, and state, it's not that deep.
        
           | Madmallard wrote:
           | handling latency to keep a coherent experience in a real-time
           | game is an unsolvable problem where every single mechanic
           | requires a planned out scheme and companies go so far as
           | buying data centers in optimized locations to help out with
           | the illusion
           | 
           | that's probably what you mean by highest level of complexity
           | 
           | but even just a regular turn-based game there's a lot of
           | questions you need to answer and decisions to make regarding
           | latency, packet loss, and disconnects that all have to be
           | solved in a coherent and consistent way
        
             | intelVISA wrote:
             | Bytes + FSM, don't overcomplicate unless your salary
             | depends on the solution.
        
           | kayamon wrote:
           | How are you handling NAT traversal?
        
         | allthetime wrote:
         | Netcode is tricky, but it's a solved problem (in terms of
         | practical use). There are many first class examples to base
         | your own work off of.
        
       | gethly wrote:
       | i am making a text editor/ide in Go and i too switched from
       | raylib to sdl. it's likely one of the best graphics layers out
       | there.
        
       | lovegrenoble wrote:
       | https://en.wikipedia.org/wiki/Celeste_(video_game)
        
       | bitwize wrote:
       | Creating a game with an engine is like designing a character with
       | a pixel dollbase. You can get something out quickly, skipping a
       | few steps because they're done for you, but you have to live with
       | whatever choices were made by the creator of the engine/dollbase.
       | Those choices can constrain your execution and to some extent,
       | your imagination.
        
         | charcircuit wrote:
         | While true, people overestimate how limiting it actually is.
         | It's like wanting to make your own kernel for your application
         | instead of using an off the shelf one like Linux. Sure you
         | might be able to eek out some extra performance but there are
         | so many upsides in reusing Linux.
        
         | krapp wrote:
         | >Those choices can constrain your execution and to some extent,
         | your imagination.
         | 
         | In theory, yes. In practice 99.9% of the games developers want
         | to make are feasible with an off the shelf engine.
        
       | jesse_dot_id wrote:
       | This was a great read. I'm in my 40's and have mostly done web
       | dev/devops type stuff throughout my career. Making video games
       | has always eluded me even though I've always been interested in
       | it. I think it's that everything feels like a brand new language
       | I have to learn. Perhaps creating an engine is the move.
        
         | Cthulhu_ wrote:
         | I'm no game developer, but I'd say don't create an engine if
         | what you want to do is build a game. Do create an engine if you
         | want to create an engine though.
         | 
         | But yeah, it is like learning a new language. But that's not a
         | bad thing! I found messing around / following some tutorials
         | for e.g. pico-8 to be both liberating (two characters are
         | enough for a variable name) and educative (using functions like
         | min/max to the fullest)
         | 
         | [0] https://www.lexaloffle.com/pico-8.php
        
         | endemic wrote:
         | If you're familiar with web development, you can make games
         | with HTML/JS, which is almost its own "engine." Think DOM
         | elements for sprites, CSS animations for movement,
         | requestAnimationFrame for an update loop, etc. This has the
         | extra benefit of zero friction for players -- no native app
         | installation necessary!
        
           | jesse_dot_id wrote:
           | I have thought about doing this via PhaserJS in the past, but
           | it just never clicks for some reason. I feel like my brain is
           | missing some important component for making game design make
           | sense.
        
         | bluefirebrand wrote:
         | I'm not quite 40 yet, but I feel the same
         | 
         | I have wanted to make games my whole life but I got into web to
         | make a living. Now it's been decades of game ideas and no
         | implementations, just frustration. Something about unity,
         | unreal, godot just never clicks with me
         | 
         | Maybe I'll try making my own engine too. Best of luck to you,
         | maybe the both of us can make our dreams come true with a
         | slightly different approaches
        
       | sgt wrote:
       | What's the best place to get some cool graphics assets, sound etc
       | when making a love2d or sdl or {yourfavoritetech} game?
        
         | armcat wrote:
         | I've used itch.io before, it's great! I even made a game using
         | some free assets and AI:
         | https://github.com/acatovic/gothicvania-codex-demo
        
         | u361 wrote:
         | Putting as much love into it as you can.
        
         | samiv wrote:
         | Don't know about "cool" but I always end up going back to
         | opengameart.org
         | 
         | While most of the stuff is one off assets that do not fit
         | together there are also some nice sets by some creators such as
         | Kenney or Emcee Flesher
         | 
         | Also the Liberated Pixel Cup (LPC) stuff is pretty nice.
         | 
         | Mind you I mostly just look for 2D assets.
         | 
         | https://opengameart.org/users/kenney
         | 
         | https://opengameart.org/users/emcee-flesher
         | 
         | https://opengameart.org/content/lpc-collection
        
         | kurtdev wrote:
         | For prototyping I usually use Kenney assets (from kenney.nl).
         | Theres lots of assets for many types of games which lets you
         | rapidly prototype and iterate without worrying about making
         | assets first. For sounds you can use BFXR and just play around.
         | Sometimes playing around with sounds can even lead to new
         | feature ideas :)
        
         | krapp wrote:
         | itch.io is good for sprite assets and fonts I find.
        
       | sbiru93 wrote:
       | Very interesting article.
       | 
       | It's kinda sad SFML never get quoted, It was my framework ( after
       | ALLEGRO ) where i learned c++ and I think it dosen't get much
       | love nowdays even if it is very light and strong
        
         | Subdivide8452 wrote:
         | SFML definitely needs more love than it's receiving.
        
         | throwaway2046 wrote:
         | I've almost never seen SFML used in the wild. Does it offer
         | anything significant over SDL?
        
       | u361 wrote:
       | Making video games in 2025, sans AI, sans an engine, is harder
       | than some poeple could handle it, and very rewarding: it's like
       | playing Celeste.
        
       | roflcopter69 wrote:
       | I read that article a while ago and highly enjoyed it. C# truly
       | has become a very good language for game development and since
       | NativeAOT has become a thing, we will less and less rely on hacks
       | like IL2CPP or BRUTE which transpile the C# IL to C++ such that
       | it can run on JIT restricted platforms like consoles or iOS.
       | 
       | I'd really love to go all-in with C# and SDL3 to make an engine-
       | less cross-platform game but I still miss a good way to make
       | complex game UIs without doing everything from scratch. Does
       | anyone have a good suggestion for making non-trivial game UIs
       | without using a full game engine? So far, I only found
       | https://github.com/vchelaru/Gum and
       | https://github.com/mikke89/RmlUi but I think there's not really
       | something super mature and feature packed, or is there? I'm aware
       | of https://github.com/ocornut/imgui, as the article also
       | mentioned, but that's more for debug UIs, right?
        
         | pjc50 wrote:
         | Interested in knowing your modern dotnet gamedev stack. Am I
         | right in thinking that Unity are still stuck in ".NET
         | Framework" era? How is Godot?
        
           | roflcopter69 wrote:
           | I myself don't have much of a dotnet gamedev stack going on
           | unfortunately. Although I've been dabbling with MonoGame and
           | have been enjoying it so far. MonoGame matured quite a bit
           | since I previously used it which was more than 5 years ago!
           | 
           | Unity indeed is still using Mono instead of CoreCLR and is
           | kinda stuck in that sense. But to be fair, they are trying to
           | migrate to CoreCLR which will let them profit from all the
           | crazy optimizations that Microsoft has poured into the
           | runtime and ecosystem.
           | 
           | Godot is kind of a hate love for me when it comes to C#.
           | Godot gives me the most hope that there can be a free,
           | community-driven but powerful game engine and it having C#
           | support built-in seems great at first glance until you
           | realize that GDScript, which is veeeeery dynamic language,
           | pretty much nullifies a lot of the advantages you'd get from
           | using C# because you find yourself doing weird type system
           | stuff that GDScript imposes on all the other languages. The
           | best you can do is doing as much as possible in C# and use
           | Godot as kind of a input and rendering abstraction layer. But
           | then you're missing out on a lot of the functionality that
           | Godot offers which should raise the question why use a game
           | engine in the first place. It's difficult, at least for me.
           | Others might have figured it out much better.
        
           | S04dKHzrKT wrote:
           | Stride runs on the latest version of dotnet and c#. I don't
           | have enough experience with it to know its pros and cons
           | though.
           | 
           | https://www.stride3d.net/
        
       | roflcopter69 wrote:
       | I see `dotnet watch` being mentioned for code hot reload which is
       | such a great feature for quickly iterating on a game. Not having
       | to restart the whole game just because one has changed a few if
       | statements and values really helps staying in the flow.
       | 
       | But I'm still not too enthusiastic about having GC in C# which is
       | why ideally I'd like to start making a small 2D game just with
       | SDL3 and C++ but how could I get this nice hot reload workflow
       | there? I don't have the money to pay for expensive proprietary
       | tools like https://liveplusplus.tech so what can I do? I guess
       | there's the "game as dynamic library" trick from Handmade Hero
       | (see https://www.youtube.com/shorts/seWAIURXxH0) so maybe that
       | would work good enough? Maybe https://github.com/fungos/cr would
       | do most of what's needed here?
       | 
       | Also, how does one even do modern C++ these days? Is it possible
       | to have big C++ code bases that still compile fast these days? Is
       | CMake 4 good(tm) now? Are modules really there yet? I rely on
       | clangd as LSP for working with C++ but I read that clangd still
       | fundamentally struggles with C++ modules
       | https://chuanqixu9.github.io/c++/2025/12/03/Clangd-support-f...
       | and it's so bad that there has even been some effort going into
       | making a new C++ LSP https://github.com/clice-io/clice
        
         | neonsunset wrote:
         | .NET also now has an (amazing) alternate low-pause/effectively
         | pauseless GC: https://github.com/VSadov/Satori
         | 
         | Builds: https://github.com/hez2010/Satori/releases
         | 
         | how to use? do self-contained publish (but not single file),
         | replace 3 files in the folder with the one from Satori release
         | you can check if it's in use with
         | GC.GetConfigurationVariables().ContainsKey("SatoriGC")
         | 
         | It is a far, far superior experience to touching anything C++.
        
           | roflcopter69 wrote:
           | Oh thanks, that looks very intriguing! The maintainer seems
           | to be a Microsoft employee so there's that? I wonder though,
           | is this a niche hidden gem or really something that more
           | people should consider using? Also, what about compatibility
           | with platforms like Android, iOS or consoles? That'd be very
           | important for gamedev.
        
         | dxuh wrote:
         | I quite like modern C++, so I really tried to make it work for
         | gamedev, but I think you can't really do it. You can use all
         | the modern C++ features that are not in the standard library
         | though! I am working on a little game the last few months and
         | after a while I just decided to not use any of the C++ standard
         | library (I just use a few C headers) and make my own Vector,
         | Array, Span, String, FlatMap. And using those the game compiles
         | _really_ fast. If I touch a header that is included almost
         | everywhere (the big game state struct), I can compile and link
         | (mold) in ~300ms. If I touch player.cpp I compile in 250ms.
         | That is mostly good enough for me, but I am thinking about the
         | "game code as dynamic library" thing myself.
         | 
         | I always thought CMake was good enough. I use FetchContent for
         | all external dependencies and git submodules + add_directory
         | for all internal dependencies. It took me a while to figure out
         | that this was the simplest thing that works reliably though. I
         | have used vcpkg and conan extensively and have completely given
         | up on them.
         | 
         | I don't use C++ modules, because afaik they are still mostly
         | broken. Without modules clangd works wonderfully and has been
         | working wonderfully for a few years. I really, really like it.
         | I think it can be done! I am missing reflection though, but if
         | I would really want to use it, I'd probably just use clang
         | -ast-dump instead of the new reflection functionality.
        
           | roflcopter69 wrote:
           | Thanks for the reply!
           | 
           | > I quite like modern C++, so I really tried to make it work
           | for gamedev, but I think you can't really do it.
           | 
           | What exactly do you mean? What parts of modern C++ did not
           | work for you?
           | 
           | > You can use all the modern C++ features that are not in the
           | standard library though!
           | 
           | > I just decided to not use any of the C++ standard library
           | (I just use a few C headers)
           | 
           | So what do you do with C++ that C alone couldn't do?
        
             | dxuh wrote:
             | I think the standard library is good, but if you pull in
             | ANY of it's headers you add a couple hundred milliseconds
             | to every translation unit. So when making games (and only
             | then), I avoid the standard library.
             | 
             | What I do like and use is overloading, references,
             | templates, concepts, lambdas, enum classes, user defined
             | literals, constexpr, operator overloading for math (!),
             | little syntax stuff like structured binding declarations,
             | "auto" and range based for. I also made my own little fmt
             | (like https://riki.house/fmt). C++ is a _much_ nicer
             | language than C imo, even without the standard library.
        
         | pjc50 wrote:
         | C++ is really not very amenable to this because every change to
         | the contents of a class messes up your entire memory layout.
         | "game as DLL" is definitely a viable solution to that, but so
         | is "game in scripting engine": many games delegate a lot of
         | their mechanics to e.g. Lua precisely because it's so easy to
         | tweak in-engine if you just want to change a bonus from 5% to
         | 10% and so on.
        
           | roflcopter69 wrote:
           | > C++ is really not very amenable to this because every
           | change to the contents of a class messes up your entire
           | memory layout
           | 
           | I think even `dotnet watch` at some point nopes out when you
           | change too much. I think they call it "rude edit" and ask you
           | to completely restart the program in that case. So I don't
           | expect every possible C++ edit to be manageable by hot
           | reload. But changing a few if conditions or constants should
           | be fine or not?
           | 
           | I'm more and more questioning scripting languages in games.
           | What are the main reasons to use something like Lua? I think
           | it's having not to rebuild the engine, no compile times,
           | changing stuff while the game is running and being more
           | accessible to non-programmers. But I think it's rather
           | infuriating, all those points could be less relevant if the
           | tooling for "real" programming languages was better. And with
           | coding agents becoming more wide-spread I guess accessibility
           | to non-programmers also becomes less of a point. I guess it's
           | just my personal dislike for scripting languages in games,
           | but really, it would be so much nicer imo if there was only
           | need for one language that does it all. But seems like a
           | difficult thing to achieve.
        
         | Anonyneko wrote:
         | You could also offload potentially GC-heavy parts to C++ and
         | write the rest in C#. Depends on the game, but usually most of
         | the game logic that you'll be constantly tinkering with doesn't
         | require all that much memory in the first place.
        
         | spacechild1 wrote:
         | If you implement the actual game logic in a scripting language
         | like Lua, hot reloading becomes trivial. sol2 is a really
         | awesome Lua binding library for C++:
         | https://github.com/ThePhD/sol2
        
           | roflcopter69 wrote:
           | Thanks for the Lua bindings suggestion!
           | 
           | It's just that I quite dislike using such a scripting
           | language. It's personal preference, for sure, but here's a
           | bit more context
           | https://news.ycombinator.com/item?id=47220602
        
       | ps173 wrote:
       | Reading this I realized even for someone who just wants to make
       | games that are fun for him, I find engines very less rewarding to
       | work with. I always loved game libraries that provided utilities
       | to build things but hated do everything ones ( love2d supremacy
       | ). It's great to see experienced and accomplished professionals
       | validating my take :)
       | 
       | I saw this documentary on how celeste was made [1], which
       | completely inspired me and got me into indie game dev community.
       | Unfortunately I haven't made any games as of now that I would
       | proudly showcase but the seed that your effort put is still there
       | and one day I will get back to making games. Thanks a lot for
       | making celeste I absolutely love it! ---- 1.
       | https://youtu.be/MSKOQr_YS-U?si=AGzl5ILzxkoIB-j9
        
       | phendrenad2 wrote:
       | Note that this is primarily about 2D indie games. For 3D, it's
       | not much of a question, you probably need an engine.
        
       | PacificSpecific wrote:
       | I generally worked on AAA stuff but the few times I released
       | stuff independently I ended up writing my own framework/engine.
       | 
       | I think the issue was when I used an engine the scope was too
       | large and I never completed the work so I never released the game
       | (or I released it for free because I felt it was incomplete and
       | wasn't worth charging for)
       | 
       | It's great to work in a constrained environment
        
       | RASBR89 wrote:
       | 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'
        
         | boca_honey wrote:
         | 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".
        
           | HerbManic wrote:
           | 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.
        
         | allthetime wrote:
         | that's because fundamentally, they are the same. Different
         | assets and scripts, same internals / foundation.
        
       | baby wrote:
       | No MacOS version for Celeste 64. I would have thought building
       | something from scratch would have meant that its easier to do
       | multiplatform right?
        
         | Levitating wrote:
         | XCode licensing might play a part, as well as the need for
         | apple harwdware
        
       | hollowturtle wrote:
       | To anyone with experience on the matter: I'm looking for making a
       | mobile app which resembles more of a game or "a graphical app"
       | and was looking into tech I could use, all I need is a drawing
       | API I could use cross platform for Android and iOS without much
       | hassle, don't need any OS specific widget/component, I just want
       | to draw stuff on the screen, handle touch input and do some
       | network calls. Possibly with a statically typed language that
       | gets compiled and has good performance. So far I excluded React
       | Native because it's javascript and has too many
       | dependencies(especially with expo) and SDL3 with plain C which
       | seemed a little too much low level to dealing with on a mobile
       | phone. Also tried go mobile but seems unmaintained and gives
       | opengl context which is deprecated on iOS, and finally I'd really
       | liked using Raylib but no iOS support :(. Any suggestion?
        
         | newswasboring wrote:
         | If you are willing to try out Lua there is Love[1]. Supports
         | most common platforms on PC and mobile.
         | 
         | [1] https://love2d.org/
        
           | hollowturtle wrote:
           | I really like love2d and used prior but lua isn't compiled
           | and network support is limited, although I see they now
           | support https requests on the latest version
        
         | arjonagelhout wrote:
         | I personally use Skia, in combination with a very thin platform
         | layer. I do use C++ so that might still be a bit too low level,
         | but after having set up everything, the Skia API is really nice
         | for just drawing some text / other primitives onto the screen.
         | 
         | React Native uses Skia under the hood as far as I recall.
        
           | hollowturtle wrote:
           | I'd love to use Skia. Any template/starter I can look for
           | having both Skia and c++ compiling inside xcode/android
           | studio?
        
         | hu3 wrote:
         | C# + https://monogame.net
         | 
         | - Desktop: Windows, MacOS, Linux
         | 
         | - Mobile: Android, iOS, iPadOS
         | 
         | - Console: Playstation 4, Playstation 5, Xbox One, Nintendo
         | Switch
         | 
         | It used to be XNA but then Microsoft discontinued and the
         | community created the API compatible MonoGame.
         | 
         | Notable games: Terraria (when it was XNA), Stardew Valley,
         | Celeste, Terraria and Fez.
        
         | gr4vityWall wrote:
         | OpenFL should cover your needs pretty well. https://openfl.org
        
       | agentultra wrote:
       | I'm in the middle of making a game now in C with raylib. Super
       | small in scope. No level editor or tooling needed.
       | 
       | It's easy for me. I just know C and raylib's API is small. I got
       | cross platform compilation going in an afternoon.
       | 
       | I've worked through some things with Godot. There's just so much
       | to learn that it'd take me longer to learn Godot than to get
       | running with C.
       | 
       | Feel much the same as the author.
        
         | ecshafer wrote:
         | For me when there is a library or framework or "engine". You
         | are often having to learn the specifics of how this thing
         | works, and ALSO map your mind to the way it works. When you
         | write things yourself you are only in your own mindset. So you
         | can write your 90% self implementation in less time than
         | learning this new mindset. Then you can build everything
         | together without special ways of piping things together. Adding
         | more frameworks or libraries is an exponential explosion in
         | complexity, and more and more of your time is spent with glue
         | code. When you write everything yourself, you are in one design
         | space and things flow more naturally.
        
       | JKCalhoun wrote:
       | 100% agree.
       | 
       | * There is overhead in learning how a specific game engine works.
       | 
       | * Often, due to a game engine API, it seems to herd you into
       | writing the same game everyone else is writing with that engine.
       | 
       | I wanted _just enough_ "game engine" to abstract away the pixel-
       | buffer, windowing, user-events on the various target platforms
       | and then do no more.
       | 
       | "I have been using SDL3 as it does everything I need as a cross-
       | platform abstraction over the system - from windowing, to game
       | controllers, to rendering."
       | 
       | And that is exactly where I landed as well. SDL3 [1] absolutely
       | matched what I wanted. Then again, I enjoy writing sprite-based
       | games. If you want to write a 1st-person shooter though I'm sure
       | you will still want to go with one of the giant game engines.
       | 
       | (Actually it was SDL2 since it was two years ago I was exploring
       | it: https://store.steampowered.com/app/2318420/Glypha_Vintage/)
        
       | lasgawe wrote:
       | A lot of modern games do feel like they blend together visually,
       | similar lighting models, motion blur, depth of field, texture
       | streaming pop in and I think part of that comes from so many
       | titles relying on the same engines. When more studios were
       | building or heavily customizing their own engines, games tended
       | to have a more distinct identity.
        
       | zeroq wrote:
       | There's a huge difference between "making a game" and "shipping a
       | game".
       | 
       | If journey is more important to you than the destination then
       | developing games without an engine can be a great adventure.
       | 
       | But if you bank on shipping your product within budget and scope
       | then you'd better pick up one. Any one. And stick with it.
        
       | YesBox wrote:
       | 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/
        
         | megalomanu wrote:
         | 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!
        
           | YesBox wrote:
           | Thank you! I'm fueled by passion more than dedication.
        
         | Karrot_Kream wrote:
         | 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.)
        
           | YesBox wrote:
           | 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
           | 
           | The game engine is cross-platform ready, but as a solo dev
           | I'm just targeting Windows for now.
           | 
           | You're welcome!
        
             | performative wrote:
             | the burnout chunk got an agony-fueled chuckle out of me
             | thank you
        
             | Karrot_Kream wrote:
             | Thanks for the breakdown, I'm also sending the game to
             | friends who like this genre of game so hope you get some
             | downloads!
        
         | vmykyt wrote:
         | Your screenshots look dangerous i.e. I'm constantly seeking
         | some hiding aliens there
        
         | adwf wrote:
         | [delayed]
        
       | alvivar wrote:
       | Inspired by this blog post by Noel Berry, I started playing with
       | SDL3 and C# yesterday, experimenting with falling sand algorithms
       | (implemented sand, stone, and water)
       | https://github.com/alvivar/falling-sand
        
       | the__alchemist wrote:
       | 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.
        
         | mikepurvis wrote:
         | 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.
        
         | jonny_eh wrote:
         | 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.
        
           | the__alchemist wrote:
           | I did. Was kind of underwhelmed by the graphics too. Although
           | that may be in line with a remake. Ie, I gave it benefit of
           | the doubt since I don't know how much effort they put into it
           | beyond "making it work".
        
         | indubioprorubik wrote:
         | 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.
         | 
         | https://www.youtube.com/watch?v=Ls4QS3F8rJU&t=539s
        
       | TimFogarty wrote:
       | If you're interested on a dive into building game engines, I've
       | enjoyed some of Cherno's videos [1] on developing his game engine
       | Hazel [2][3]. It's cool to see the amount of work that has to go
       | into building an engine. I believe Noel when he says building
       | games without a commercial engine is more fun - there's a lot of
       | fascinating optimizations and tricks at the engine layer.
       | 
       | [1]
       | https://www.youtube.com/playlist?list=PLlrATfBNZ98drHSOb-h2e...
       | 
       | [2] https://hazelengine.com/
       | 
       | [3] https://github.com/TheCherno/Hazel
        
       | ventare wrote:
       | I remember reading this article a while back. It may be partially
       | responsible for me starting my own game project in a custom
       | engine. Also the last 10 years of my professional life have been
       | spent wrangling Unity and Unreal, and, well, I just didn't want
       | to do it anymore.
       | 
       | So I narrowed my game concept to be more stylized, no
       | photorealism, no human characters, etc, in order to make
       | something both unique, and deliverable.
       | 
       | Its inspiring to see others doing the same thing for similar
       | reasons. Maybe I'm not completely crazy after all :)
        
       | wolttam wrote:
       | Hey Noel! There is always Neovim :)
       | 
       | - A former VS Code enjoyer
        
       | agentifysh wrote:
       | been working on something in three.js and ended up building an
       | editor inside it
       | 
       | its kinda insane how much i can get done with codex
       | 
       | half way through i realize i need a way to build levels and codex
       | suggests you need a editor, here's the PRD following the safety
       | harness and framework in your AGENTS.md and I come back to get
       | coffee and its done....
       | 
       | also have a appreciation for how much game engines do for you,
       | every step of the way I want to add a simple feature and realize
       | we are not using a game engine so those have to built as well
        
       | holoduke wrote:
       | A bit off topic. But I think that if the speed of today's LLMs
       | would be a factor 1000 faster, we would need no general purpose
       | engines or frameworks to build a game. One could prompt a
       | complete custom game including all the parts that make the game.
       | Engine. Physics, assets. Sounds, level design everything.
       | Capabilities of for example opus is enough to achieve this. Its
       | only slow.
        
       | jharohit wrote:
       | 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!
       | 
       | https://rohitjha.com/labs/flynns-arcade
        
       ___________________________________________________________________
       (page generated 2026-03-02 23:01 UTC)