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

71–80 of 257 posts

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

#71

Post by zerr »

Agingcoder wrote: post #38
zerr wrote: post #32

I believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.

This is what happened to me a long time ago - I used to write software 3D engines, then 3D cards (3DFX in particular) happened. I remember losing interest at that time ( I eventually figured out that there was still work to do but still…) Now that I’m quite a bit older, I have come to appreciate the game part a lot more - it’s maybe less techie, but it’s actually also why people make games. When I play with my kids t…

That always has been my Achilles' heel - I don't play games, I think that it's a waste of time. So just enjoying the tech side of it.

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

#72

Post by Jyaif »

kgeist wrote: post #20
_m6gi wrote: 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…

> Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.

Not necessarily. You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).

I wrote about it in https://www.jfgeyelin.com/2021/02/a-general-state-rollback-t...

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

#73

Post by bob1029 »

pjc50 wrote: post #47
billfruit wrote: post #8

Earlier quoted context omitted.

Also using an engine allows us to make progress on the project itself, rather than sinking major time into building infrastructure. Reinventing the wheel isn't that fun for most people.

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 many customers as possible.

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

#74

Post by rishflab »

danielbarla wrote: post #12
rishflab wrote: post #3

Earlier quoted context omitted.

animation blending isn't that bad. If you have a two poses represented as lists of quaternions and positions, all you have to do slerp between the quaternions and lerp between the positions. FABRIK IK algo is a ~100 loc function.

Agreed, though getting to that point of understanding is what takes time. Also, there are literally dozens of similar topics where a solo dev should be happy to take any help they can get, IMHO. I'm sure audio is similarly easy, as is input, pathfinding, AI decision trees, physics, etc, etc.

physics is not easy. its pretty challenging and has unending scope.

audio can also have unending scope if you want to do physically simulated Spatial Audio.

Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping.

rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory.

The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.

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

#76

Post by brulard »

ms-menardi wrote: post #50
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.

some games require a certain level of scale and for those games you should optimize in the pre-planning stage.

I think you are missing the point. The larger the scale is, the more things may be optimized and the more you need to be careful to focus on the important "3%". That said, it doesn't hurt to analyse in advance which parts might be critical and steer the architecture based on those observations.

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

#77

Post by nkrisc »

xandrius wrote: post #42
jeffhuys wrote: post #35

Earlier quoted context omitted.

Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)

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 efficiently removing an item from an array of 20 items every 5-10 minutes.

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

#78

Post by ido »

chickenzzzzu wrote: post #60
ido wrote: post #37

Earlier quoted context omitted.

I'm in the same demographic (less successful than Noel, but I have made my living from game dev for the last 15 years, a lot if from my own indie games). I've used multiple engines throughout that time as they seem to have a lifespan before either tech or business reasons obsolete them (e.g. my first commercial release was made with Flash). My only regret were the times I tried to roll my own, I would have saved a lo…

Face it, you just don't know how to do it and are trying to convince yourself that you don't need to learn how to

Lots of things I don’t know how to do and can spend time learning, many will be better use of that time and effort than reimplementing a game engine from scratch vs using middleware.

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

#80

Post by pwitvoet »

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…

Writing an editor from scratch is a lot of work. That's one reason why I would use an existing editor whenever possible. For example, TrenchBroom (Quake editor) + func_godot seems to be getting more popular among Godot users, and Tiled looks pretty good for 2D games. For game data management I've seen CastleDB (never used it though), which now seems to be integrated into Hide, a full-blown 3D editor.

Either way, once you get the tooling up and running, the next big step is actually designing a game and creating all the content. :)

Post reply on HN