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

171–180 of 257 posts

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

#171

Post by munificent »

corysama wrote: post #133
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…

At the indie studio I used to work at, we had some folks with engine experience. So, we rolled our own 3D engine and asset pipeline from scratch. But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya. Textures from Photoshop. Audio as a pile of WAVs. Scripting in Lua. UI layout in XML. Changing the asset files wo…

> But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya.

I was the tools lead for "Superman Returns: The Videogame" (the PS2/X630 Superman game, no the N64 one). We did the same thing. All of Metropolis was essentially "modeled" in Maya with plug-ins handling importing and exporting between that and the in-game format.

It was an open world streaming game and it would have killed an artist's machine to try to load the entire city into Maya, so the plug-in would let an artist pick which chunks of the city to load, load them in, let them make changes, and save the results back out.

It worked out fairly well.

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

#172

Post by RyanOD »

As a "for fun" side project, I've started building clones of retro classics in Pygame as a way to help beginners gain knowledge of procedural game dev fundamentals.

Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.

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

#173

Post by monkeyelite »

jayd16 wrote: post #132
monkeyelite wrote: post #129

Earlier quoted context omitted.

> inverse kinematics and animation blending Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.

This is table stakes for any 3D animation, these days. Anim pop is embarrassing and almost certainly you'll want look IK let alone any of the more complex usage.

> This is table stakes for any 3D animation

You’re doing 3d skeletal animation for your indie game? How many skeletons and animations are you going to make?

And you don’t consider it a central feature?

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

#174

Post by monkeyelite »

andrewflnr wrote: post #134
monkeyelite wrote: post #129

Earlier quoted context omitted.

> inverse kinematics and animation blending Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.

Blatantly false dichotomy.

Or You simply aren’t ruthless enough about how much time you have on an indie project.

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

#175

Post by agentultra »

lukan wrote: post #155
agentultra wrote: post #116

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.

Definitely, it’s a trade off. Pulling in dubious dependencies can be a risk. Might be worth writing your own library or forking the dependency and vendoring it in your source.

There’s a spectrum of options here.

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

#176

Post by dopu »

aleph_minus_one wrote: post #101
bob1029 wrote: post #73

Earlier quoted context omitted.

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

I’m not doubting you, but the vast majority of ideas people have for games are largely derivative and could quite easily be implemented in Unity.

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

#177

Post by monkeyelite »

raincole wrote: post #144
monkeyelite wrote: post #129

Earlier quoted context omitted.

> inverse kinematics and animation blending Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.

It's just so wrong. These things are very standardized, and you often just want the common implementation that everyone is using. Writing these in most cases is like writing your own SHA256.

Is your indie game more complex than quake 3?

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

#178

Post by jayd16 »

monkeyelite wrote: post #173
jayd16 wrote: post #132

Earlier quoted context omitted.

This is table stakes for any 3D animation, these days. Anim pop is embarrassing and almost certainly you'll want look IK let alone any of the more complex usage.

> This is table stakes for any 3D animation You’re doing 3d skeletal animation for your indie game? How many skeletons and animations are you going to make? And you don’t consider it a central feature?

If you have any animations you're going to want to blend them. If you don't want to make a lot of animations you're probably going to want to use IK for procedural animation.

If you use an engine, you won't be forced to spend time and make it a defacto central feature (because you wont have time for other features). You'll just have access to it.

Evan a 2.5D platformer, a common indie genre, would want animation blending and foot IK without innovating on it.

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

#179

Post by whstl »

corysama wrote: post #133
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…

At the indie studio I used to work at, we had some folks with engine experience. So, we rolled our own 3D engine and asset pipeline from scratch. But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya. Textures from Photoshop. Audio as a pile of WAVs. Scripting in Lua. UI layout in XML. Changing the asset files wo…

This is so cool and clever!

Scott Bilas also documents doing something similar for Gabriel Knight 3, one of the “grandfathers” of data-driven engines and bit of an influence on ECS.

Instead of excel however it was comma-separated text files that shipped with the game. During development could edit the files locally and reload the data without recompiling.

Since we’re in a web heavy forum: An sql database and a web editor would also allow for a distributed workflow.

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

#180

Post by deepfriedrice »

tiniuclx wrote: post #84

That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste. I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features…

Oh wow - I wanted to build a game just like this not too long ago but never found the time. Wishlisted!
Post reply on HN