Live data from Hacker News

Making video games (without an engine) in 2025

noelberry.ca

101–110 of 257 posts

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

#101
post #73
post #47

Earlier quoted context omitted.

On the contrary, lots of people enjoy the reinventing the wheel part as a means of avoiding all the tricky creative choices and risk of actually shipping a completed game.

This happens absolutely everywhere. Many B2B SaaS products could have been a single T-SQL script in MSSQL or some other paid/non-OSS/evil capitalist equivalent. I think a lot of developers lean on ideological angles to deflect rational criticism of their lack of progress and direction. Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as…

> Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.

If your game idea fits well into the structure of these engines: perhaps.

But I can tell you that lot of ideas that I have for games ("games" is to be understood in a somewhat more broader sense) don't fit these structures well. So I am very certain that for the game ideas that I have in mind, writing an own game engine would very likely be the better choice.

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

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

From a starting point of having dabbled in making 2D games in the past it took me a few days of working through tutorials and documentation for producing assets to be the bottleneck in building a game in Unreal. In Godot I was at the point of being able to make terrible games within a few hours. The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engi…

> The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engine from scratch quicker than they can implement a game with an existing engine is deluding themselves.

If the game fits a rather "standardized" template, this is likely true. But the more you move away from these "mainstream structures", the less true the second part of your claim becomes.

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

#104

Earlier quoted context omitted.

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.

Sometimes you have to do business with counterparties you don't trust. It's not mature or practical to take an "all-or-nothing" approach while the engine has virtually no competition for many classes of games.

Building a business fully depending on a party you don't trust sounds kinda delusional.

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

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

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

#106

That was a great post. I had no idea modern .NET had hot-reloading built-in like that. From my experience programming games, that's the biggest time saver you can ask for. Does it work well (or at all) with Godot/C#? A few years ago, a notorious developer in the GameMaker community wrote a tool that added live reloading to it, and immediately it got widely adopted by big projects. In terms of prototyping, I think an…

> That was a great post. I had no idea modern .NET had hot-reloading built-in like that.

I fully concur, that was a great post. And on full time Linux, just incredible. Definitely it's given me the itch to try a few new things :)

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

#107
Game engine is an art tool in the same way like Blender or Photoshop are. You have to learn its tips and tricks the same way artists do. Usually programmers consider anything that does not have a dedicated UI as fatal flaw hence all the bias towards big engines.

For example, you want to make and thumbnail picture of a 3d model/character. My first thought as a programmer on "correct" approach to that in UE was like well I need to setup a separate world with brand new lightning and have some renderer features off. The perfect "hack" for this is to have a separate "dressing room" under the level where the model teleports into and then back during single frame. Hundreds of such nuances can be only learned.

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

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

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 specialized tools, FOSS or otherwise.

Although come to think of it, you could probably do most of that in Blender, so maybe such an thing already exists.

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

#109
post #39
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…

I have recently done an engine rewrite for my sequel game and I very much agree with this. In my postmortem[1], I wrote: > Most people think of a “game engine” as code that is shipped with the game executable. However, that’s only half of it. The other half, which I’d argue is more significant, is the code that is not shipped with the game - level editors, content pipelines, debugging/profiling tools, development wor…

So that’s where Chris Robert’s billion dollar went.

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

#110
there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.
Post reply on HN