Live data from Hacker News

Making video games (without an engine) in 2025

noelberry.ca

191–200 of 257 posts

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

#191
post #147

Earlier quoted context omitted.

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…

There's the Local Lua Debugger [0]. I don't know how it compares to decoda, but I experimented a bit with this debugger last weekend and it seems nice enough - well integrated into VS Code. --- [0]: https://github.com/tomblind/local-lua-debugger-vscode

The magic of Decoda is that you can download the debugger and immediately start debugging your existing program with no modifications. No libraries. No sockets. No changes at all.

Decoda uses your PDB to locate the Lua C library within your .exe and the Win32 API CreateRemoteThread to inject the code into your process to hook the Lua API.

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

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

When I was a game dev I spent way more time on tools than on the engine. Those days of small teams are gone now, so at least in a professional setting you are likely to be able to concentrate on the engine while some other person has to build the editors.

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

#193
post #178

Earlier quoted context omitted.

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

> If you have any animations you're going to want to blend them.

Yes, if 3d skeletal animation is a central feature of your game it’s not a big deal to spend time making a good system that works for you.

> you're probably going to want to use IK

Plenty of 3D games with 3d animation don’t have IK

> for procedural animation.

Wow your game has 3d procedural animation! That better be the main feature right?

The reason I’m so skeptical is a feature has cost whether it’s written in the engine you use or not. You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.

For most games, spending time tweaking rigs for IK is not going to make your product better.

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

#194

Earlier quoted context omitted.

Blatantly false dichotomy.

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

Or those features can be nice-to-haves that are worth it if they're not too much effort, such as if, say, I don't know, an engine handles them for you. Come on, real life rarely justifies such easy, simple decisions. And polish can matter a lot for games.

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

#195

Earlier quoted context omitted.

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

Or those features can be nice-to-haves that are worth it if they're not too much effort, such as if, say, I don't know, an engine handles them for you. Come on, real life rarely justifies such easy, simple decisions. And polish can matter a lot for games.

Sure I’m expressing a value judgment, a design preference - not an eternal truth. And the principle is I want to spent the effort on the most important features in which case it’s not a big deal to write them. Your best features become better than if they were cobbled together in Unity.

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

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

Word! i've done some ground-up 2D games with no engine library. So i hand-rolled resources, frame rate, collision, simple physics, etc. One has no graphics assets. Another other does.

https://github.com/raould/pn0gstr0m https://github.com/raould/sheepgate

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

#197
Game dev here, building a game using the "engine-only" version of PlayCanvas (a 3d engine). Asset loading, rendering, physics, object management, update loops, raycasting is all handled by the engine (js). My code is everything else, including a low-tech drag and drop scene editor.

I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have.

I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).

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

#198

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.

Statistically speaking, 99% of game devs won't ever make a game like that. And if they do, they will probably know ahead of time they are making it.

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

#199

I use Lua & Love2D to make games with a similar ethos. Being able to set my own constraints is fun, and that's what game dev is about for me. As soon as something stops being fun, I know I'm doing it wrong and there must be a better way. My game YOYOZO is a tiny 39KB but made it to Ars Technica's "Best Games of 2023" list alongside heavyweights like Super Mario Wonder and Tears of the Kingdom! https://news.ycombinato…

Congratulations man, great work.

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

#200
post #5

I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot ! But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that. I've got huge amounts of respect for people d…

The one thing that perplexes me is that there are some annoying warts of Godot that make developing a game in it different than making a game yourself and nobody thinks "hey wouldn't it be easier to make Godot work in this way, than to do everything from scratch?" The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, e…

I mean, you can do Godot this way - just make your player a scene with Node2D or 3D as the root instead of a PlayerCharacter and have it respond to input
Post reply on HN