Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making video games (without an engine) in 2025

noelberry.ca

Post reply on HN
Print view View original

111–120 of 257 posts

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

#111

Post by aleph_minus_one »

Llamamoe wrote: post #105
samiv wrote: post #18

After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.

> I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.

I see one problem (there very likely exist a lot of others) in the fact that a lot of frameworks and engines are "deep ecosystems" that take a lot of effort to get deeply into. Once inside the engine ecosystem, a lot of concepts are "very integrated/intertangled" (though not necessarily in the "best possible way").

So, a lot of implementation time will have to be invested for each individual supported engine so that the editor properly integrates with it.

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

#112

Post by flohofwoe »

zoky wrote: post #108
Llamamoe wrote: post #105

Earlier quoted context omitted.

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.

The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making. A 2D pixel-art platformer, a multiplayer FPS, a top-down strategy sim, and a puzzle game are all going to require completely different types of assets with unique design requirements. You’d need an all-singing-and-dancing tool that probably wouldn’t be as good at any one thing as the existing spe…

There's basically two paths:

(1) Build a generic and extensible UI tool which at the core is a 3D scene viewer, object outliner and an asset browser (similar to how VSCode is such a tool for 'mostly text data' for 3D scenes). Implement anything else as engine specific plugins - Blender can be that tool, but it would be important to do a complete UI overhaul to get the modelling and animation features out of the way.

(2) Integrate the editor UI right into your engine, which is quite trivial with Dear Imgui - the tricky part here is that game state data should either be organized for editing, or for runtime performance. Mixing both isn't a good idea (unless moddability is a priority).

About a decade ago I would probably have opted for option (1), nowadays I tend towards option (2).

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

#115

Post by corysama »

nkrisc wrote: post #77
xandrius wrote: post #42

Earlier quoted context omitted.

Yep, people forget one of the core notions of development which is not to prematurely optimise stuff. Especially something as complex as a game. Keep it super simple. Or that game will never come out.

Just the other day on reddit I saw someone asking about efficiently removing an item from an array for the game they’re working on. It became this whole CS debate and then someone asked how big the array is and how often do you remove items. The OP responded that it’s just a list of levels in their game, so not more than 20 items or so and is modified once every 5-10 minutes… So a day on their game wasted over effici…

I used to make 3D engines and asset pipelines professionally. High performance really is critical in both. So, I’d have to check myself frequently:

> If I optimize this, how much time is it going to save the whole world? What will be the sum of time saved by everyone who will ever run this code? Is that less than the time required of me to do the optimization? Then, don’t do it!

That question was relevant quite often.

The big optimizations though really mattered. And, required planning before initial implementation to set the system up to be optimizable.

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

#116

Post by agentultra »

samiv wrote: post #18

After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…

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 making, "an engine for all games." So there is a ton of work you're not doing.

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

#117

Post by whstl »

Llamamoe wrote: post #105
samiv wrote: post #18

After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.

As a "potential customer" for such thing:

I would really love something like it.

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

#118

Post by Const-me »

OnACoffeeBreak wrote: post #92

The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue. Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slo…

There’s a recent promising development relevant to the GC pause issue. It seems couple weeks ago some smart developer working for Microsoft has made a version of GC called “Satori” which pretty much solved these GC pauses for many real-world use cases.

An overview article: https://blog.applied-algorithms.tech/a-sub-millisecond-gc-fo...

Long discussion thread with many graphs with measurements: https://github.com/dotnet/runtime/discussions/115627

I don’t yet have hands-on experience with that Satori GC, though.

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

#119

Post by whstl »

zoky wrote: post #108
Llamamoe wrote: post #105

Earlier quoted context omitted.

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.

The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making. A 2D pixel-art platformer, a multiplayer FPS, a top-down strategy sim, and a puzzle game are all going to require completely different types of assets with unique design requirements. You’d need an all-singing-and-dancing tool that probably wouldn’t be as good at any one thing as the existing spe…

> The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making

Unity, Godot, Unreal, Defold and others kind of get away with it, by having editors that work for most game types.

But also: a tool doesn't have to cover all bases, especially a free/FOSS one.

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

#120

Post by jayd16 »

OnACoffeeBreak wrote: post #92

The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue. Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slo…

In a game like the author's where you just init/pool everything on load you can simply disable the garbage collector during gameplay.
Post reply on HN