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

Making Video Games in 2025 (without an engine)

noelberry.ca

Post reply on HN
Print view View original

131–140 of 225 posts

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

#131

Post by zetanor »

Joel_Mckay wrote: post #89
flohofwoe wrote: post #43

Earlier quoted context omitted.

The big difference is that the big game engines have to cover all sorts of genres and scenarios, which often results in bloated "jack of all trades master of none" code compared to engine-layer code that's highly specialized for exactly one, or few very similar games.

If building a custom commercial game engine these days... A team is 100% focused on the wrong problem, as the game-play content is what sells. Customers only care about game-engines when broken or cheating. Godot, Unreal, CryEngine, and even Unity... all solve edge-cases most don't even know they will encounter. Trying something custom usually means teams simply run out of resources before a game ships, and is unlike…

>Customers only care about game-engines when broken or cheating

Most game engines are broken by default. Modern customers just aren't very discerning ("It's for the pigs. Pigs eat slop."). You can feel holes and rough edges in the vast majority of new releases, including AAA titles.

Unreal is the worst for this and Unreal-based games almost always have two things in common: a very particular, soft, sticky and unresponsive look & feel (often alleviated but never fully corrected by turning off some combination of motion blur, AA and VSync), as well as a UI that mishandles mouse pointers.

Unity devs seem to rely on a (more diverse but still quite) small pool of subsystems and renderers; possibly some mix of baseline and Asset Store components. This gives each Unity game a specific subset of flaws from a wider common pool. That is, you can tell that game A uses the same movement subsystem as games B and C (but not D), that game B uses the same UI subsystem as games C and D (but not A), and that game D uses the same rendering subsystem as games A and B (but not C).

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

#132

Post by ses1984 »

andsoitis wrote: post #98
socalgal2 wrote: post #54

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

> I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them. Solo? Or part of a team?

Can you name one solo dev AAA game let alone four?

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

#133

Post by meheleventyone »

rhdunn wrote: post #60
bandrami wrote: post #44

Earlier quoted context omitted.

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

Text editors/IDEs have simple autocomplete and the ability to do some expansion, e.g. a for loop with placeholders to fill in. Those work and are still useful. JetBrains also has local line-based LLM models for various languages. With the LLM-based autocomplete it a) generally autocompletes more code at once, and b) will often pick up on patterns in the existing code. E.g. if you have a similar method, list of print/…

The JetBrains local autocomplete is hilarious but occasionally useful. I find it really hit and miss in terms of when it will decide to autocomplete and whether it will exhastively complete all elements, miss some out or get itself into a loop over several.

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

#134

Post by ses1984 »

bandrami wrote: post #66
socalgal2 wrote: post #57

Earlier quoted context omitted.

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

I'm trying to think of a text editor that doesn't support customizable snippets and templates, and failing

Those two things aren’t the same at all, they’re so different it’s hard to believe you’re not being intentionally obtuse.

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

#135

Post by BearOso »

pjc50 wrote: post #45
abcde666777 wrote: post #8

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…

> Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple. Ironically one of the things that the Quake engine relies on is clever culling. Like Doom, the level is stored in a pre-computed binary space partition tree so th…

> Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple.

Not the best example. That snippet was in use at SGI for years and actually written by Gary Tarolli. Quake's optimization was mostly done by Michael Abrash.

The original id engines were also famously inflexible. They fit the mold of "developing an engine, not a game" to a T. What you saw them do was all they could do. Look at how much Half-Life needed to add to be viable. idtech3 also only broke out of its niche because Ritual and Infinity Ward heavily modified it and passed it around. There's a good reason the engine-based ecosystem is so prominent now.

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

#136

Post by JKCalhoun »

100% agree.

• There is overhead in learning how a specific game engine works.

• Often, due to a game engine API, it seems to herd you into writing the same game everyone else is writing with that engine.

I wanted just enough "game engine" to abstract away the pixel-buffer, windowing, user-events on the various target platforms and then do no more.

"I have been using SDL3 as it does everything I need as a cross-platform abstraction over the system - from windowing, to game controllers, to rendering."

And that is exactly where I landed as well. SDL3 [1] absolutely matched what I wanted. Then again, I enjoy writing sprite-based games. If you want to write a 1st-person shooter though I'm sure you will still want to go with one of the giant game engines.

(Actually it was SDL2 since it was two years ago I was exploring it: https://store.steampowered.com/app/2318420/Glypha_Vintage/)

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

#137

Post by rcxdude »

andai wrote: post #75
socalgal2 wrote: post #54

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…

And the thing usually is that what you want from your engine is the flexibility to be able to change things around easily so you can iterate and experiment on the game design itself. Sometimes a custom engine can give you that (especially if you're going off the beaten track) but often the tooling around the off-the-shelf engines is much better for it.

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

#138

Post by Joel_Mckay »

zetanor wrote: post #131
Joel_Mckay wrote: post #89

Earlier quoted context omitted.

If building a custom commercial game engine these days... A team is 100% focused on the wrong problem, as the game-play content is what sells. Customers only care about game-engines when broken or cheating. Godot, Unreal, CryEngine, and even Unity... all solve edge-cases most don't even know they will encounter. Trying something custom usually means teams simply run out of resources before a game ships, and is unlike…

>Customers only care about game-engines when broken or cheating Most game engines are broken by default. Modern customers just aren't very discerning ("It's for the pigs. Pigs eat slop."). You can feel holes and rough edges in the vast majority of new releases, including AAA titles. Unreal is the worst for this and Unreal-based games almost always have two things in common: a very particular, soft, sticky and unrespo…

In my humble opinion, the difference between good and great was often whether the Shaders and pre-Baked work was done well enough to go unnoticed.

Forcing devs to use a mid-grade GPU also tends to reduce chasing performance issues later. For example, high frame-generation artifacts users often perceive as "floats" or "wobbly". =3

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

#139

Post by bandrami »

ses1984 wrote: post #134
bandrami wrote: post #66

Earlier quoted context omitted.

I'm trying to think of a text editor that doesn't support customizable snippets and templates, and failing

Those two things aren’t the same at all, they’re so different it’s hard to believe you’re not being intentionally obtuse.

I mean, in the sense that customizable snippets are more flexible and can cover a wider variety of use-cases, I guess?

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

#140

Post by bandrami »

rhdunn wrote: post #120
bandrami wrote: post #67

Earlier quoted context omitted.

That sure sounds like you're describing customizable snippets, which AFAIK every major editor supports?

Customizable snipping is a feature editors support (which I mentioned as they are related/similar to what the AI is doing), but is different to the AI autocomplete behaviour. If I have a JSON structure, I can paste that into the file as a comment, e.g.: # {"foo": 1, "bar": "test", "baz"} @dataclass class FooBar: foo: and the AI will/can autocomplete/generate that to: @dataclass class FooBar: foo: int bar: str baz: in…

Right, it's a less-flexible paste macro you don't actually have control over. shrug
Post reply on HN