Live data from Hacker News

Making video games (without an engine) in 2025

noelberry.ca

201–210 of 257 posts

Re: Making video games (without an engine) in 2025

#201

Earlier quoted context omitted.

I am not familiar with Unreal, but Unity is much faster than programming from scratch, easily 10x or more. One obvious example is physics behavior, which you can add to your game in under a minute, but with your own engine you'd need a day or two to properly integrate an external library. All the internal state visualization that Noel's showing off here is already built in by default in Unity. It has nice tools to dr…

At this point using any engine instead of unity is better. Unity has demonstrated time and again that they cannot be trusted and that you cannot build a game (or business) around them.

Do you have any developer retrospectives around this? Plenty of my favorite games ever made were made with Unity, I wouldn't call those games failures by any means (Cities: Skylines, Overcooked are immediate examples)

Re: Making video games (without an engine) in 2025

#202

Earlier quoted context omitted.

Monorepo?

I hate that you're almost certainly right. It feels like there should be a good way to have a dotnet classlib in one repository, and use it from others, but it just doesn't feel like they fit together the way they should.

You can also see my workflow for patching godot engine so it's mergable on a rebased master or stable release.

> This project uses git-assembler to simplify merging patches on top of the latest stable release by allowing each patch to be in a separate branch, so they can all be merged into a fresh branch without complicating the revision history.

https://github.com/KeyboardDanni/godot-for-sidescrollers

I'm https://github.com/fire

Re: Making video games (without an engine) in 2025

#203

Earlier quoted context omitted.

Or those features can be nice-to-haves that are worth it if they're not too much effort, such as if, say, I don't know, an engine handles them for you. Come on, real life rarely justifies such easy, simple decisions. And polish can matter a lot for games.

Sure I’m expressing a value judgment, a design preference - not an eternal truth. And the principle is I want to spent the effort on the most important features in which case it’s not a big deal to write them. Your best features become better than if they were cobbled together in Unity.

That is, to be generous, a rather extreme and niche value judgement that corresponds to no utility I can think of. Real life has a spectrum of "important features" and a corresponding spectrum of justified effort. If that's your idea of artistic integrity, then you do you, but for anyone else it's probably nonsense.

Re: Making video games (without an engine) in 2025

#204
post #36
post #30

Earlier quoted context omitted.

I think reaching for the delusion card without considering people's preferences, experiences, expertise and philosophy is completely disingenuous and shows that you don't look at game development holistically. Yes, existing engines do a lot of lifting, especially in 3D rendering and physics. But what about games that don't have physics? Or have completely different physics than you would expect? You mentioned assets…

Here's the thing: you try to counter someone arguing against a patently false statement about development speed with a bunch of preferences and what-abouts that do not necessarily make your stance true anyway - for instance if my game attempts to emulate 4D, my own engine STILL needs to do everything else too, we're not talking dev time for 4D in, say, Godot vs 4D in foo engine, we're talking 4D in Godot vs 4D and gr…

My friend demo'ed 4d in Godot Engine funny enough. https://github.com/godot-dimensions/godot-4d

Re: Making video games (without an engine) in 2025

#205

Made me realize that most of the games I really enjoyed have their own custom engines (made for a single game or franchise): Starbound, Stardew Valley, Minecraft, Factorio, RollerCoaster Tycoon, Empire Earth, The Sims, Project Zomboid ... Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise. Like with most things: If you are new and have to learn everythin…

This... I don't think I've ever truly enjoyed a Unity game. Maybe KSP, but it runs like shit and isn't a good advertisement for that engine. Even Unreal Engine: I've only enjoyed Unreal itself.

There are definitely some Unity games I've really liked - the Ori games, Hollow Knight - but the engine has never been a positive of my experience with the game. They're full of jank and physics bugs, and in a weird hard to describe way kind of feel "alike". You know you're playing a Unity game, which is bizarre for a part of the game experience that's so low level.

Re: Making video games (without an engine) in 2025

#206
post #155

Earlier quoted context omitted.

Keep in mind that when writing your own "engine," you don't need it to be as general as possible to handle every possible kind of game. You just need it to handle your game. And there are plenty of libraries and frameworks that can be pulled in to handle things like UI, compression, etc. The OP uses imGUI which is an excellent, small UI library for making in-game editors. When choosing to go down that path you're not…

It is still a lot of work. And every external libary you do pull in, to ease some of the workload, is just waiting to go abandonend next year. So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working.

> So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working.

That makes no sense. A library being abandoned doesn't mean it suddenly stops working.

Re: Making video games (without an engine) in 2025

#207

So, does everything he said about C# sound about right? I have no real desire to use it, but I'm curious if his opinion was more or less accurate. Not looking for a flame war, just knowledge

Yes, C# has had low-level primitives since 1.0 and it has only gotten better in this regard. This means that it's worse than Java at things like devirtualizing calls, but you can write allocation-free hot loops in C# these days. It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings),…

> you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.

The OP talks about doing this for mobile platforms, but could I take e.g. the OP's source code (he co-wrote Celeste) and trivially compile an AOT native binary for x86_64, or would more work be required to make that possible?

(Interestingly, Celeste on Linux doesn't use the dotnet runtime, but instead a portable Mono runtime which I believe is based on MonoKickstart. [1])

[1] https://github.com/flibitijibibo/MonoKickstart

Re: Making video games (without an engine) in 2025

#208
post #20
post #9

Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor o…

>Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor…

> It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)

But did you actually need all of those things?

Re: Making video games (without an engine) in 2025

#210

Hate to be mean, but this guys last game was a complete failure after multiple years of development: https://www.exok.com/posts/2025-01-22-earthblade-final-updat...

That's not a failure, it was just never finished.

And more because of personal matters than anything technical. I'm not sure why this is relevant.

Post reply on HN