Live data from Hacker News

Making Video Games in 2025 (without an engine)

noelberry.ca

171–180 of 225 posts

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

#171
post #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 bur…

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

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

#172
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…

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.

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

#173

Earlier quoted context omitted.

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.

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.

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.

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

#174

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

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.

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

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

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

#176
post #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 bur…

Your screenshots look dangerous i.e. I'm constantly seeking some hiding aliens there

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

#177

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.

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

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

#178
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

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

#179
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 :)

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

#180

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…

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

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

Post reply on HN