Live data from Hacker News

Making Video Games in 2025 (without an engine)

noelberry.ca

151–160 of 225 posts

Re: Making Video Games in 2025 (without an engine)

#151
post #95

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 ni…

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.

> 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.

Re: Making Video Games in 2025 (without an engine)

#152

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 ni…

.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 touchi…

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.

Re: Making Video Games in 2025 (without an engine)

#153
post #46

Earlier quoted context omitted.

[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.

Re: Making Video Games in 2025 (without an engine)

#154
post #68

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.

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.

How are you handling NAT traversal?

Re: Making Video Games in 2025 (without an engine)

#155

Earlier quoted context omitted.

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.

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

Re: Making Video Games in 2025 (without an engine)

#156
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/

Re: Making Video Games in 2025 (without an engine)

#157
post #75

Earlier quoted context omitted.

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,…

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 bec…

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.

Re: Making Video Games in 2025 (without an engine)

#158
post #92

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…

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…

YAGNI still undefeated in 2026

Re: Making Video Games in 2025 (without an engine)

#159

Earlier quoted context omitted.

Genuine question re #1: does your text editor not already do that?

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

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

Re: Making Video Games in 2025 (without an engine)

#160
post #94

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 because fundamentally, they are the same. Different assets and scripts, same internals / foundation.
Post reply on HN