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

251–257 of 257 posts

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

#251

Post by jayd16 »

monkeyelite wrote: post #193
jayd16 wrote: post #178

Earlier quoted context omitted.

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

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

This is the entire point of using an engine. You can spend time on the content instead of coding features that aren't unique. Suddenly many types of content are far less costly.

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

#252

Post by corysama »

slippy wrote: post #249
corysama wrote: post #133

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…

Have you tried Luau - Roblox's open source compiled Lua with Types? Someone made a debugger for it that plugs into Visual Studio Code. https://github.com/luau-lang/luau/ https://github.com/sssooonnnggg/luau-debugger I'm working on an engine based in C++, Luau, and OpenGL - started almost 2 months ago. I aim for it to me MIT license open source, but it's too early for sharing. When it is, I do plan to post a show HN w…

I have not, but it looks great!

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

#253

Post by corysama »

jayd16 wrote: post #244
corysama wrote: post #133

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…

The usage of Excel is so hilariously cursed I can't stop thinking about it. Its just raw memory address look ups with extra steps. How did you merge the Excel file? Did you actually have source control on this? Ok maybe a sheet is fine for a state machine if you don't care about visualizing transitions... Why reference cells when you could have named functions in a source file that could actually parse the syntax? Th…

> visualizing transitions

In systems where we used this it was common to have 100+ states x 100+ events. Visualizing that would have been fun, but not useful.

One implementation had layerable sheets. So, you could define a base state sheet and multiple overlay sheet that the game could enable dynamically on major changes.

Within each event column there would be long, broken up runs of "do the same thing" for runs of states. So, you could define a chunk of code in a cell below the main table and reference it in the runs and it would show in the main table.

Almost all functions were trivial. 1 or 2 statements. "Modify a value. TransitionToState X". There would be hundreds of these little snippets in a sheet. Naming each one would double the complexity for no gain. Let alone having function signatures. They'd all be `void randomName(event)`. And, Lua's a dynamic language. You aren't going to get much error checking in an IDE. Better to just keep everything local to the sheet rather than flipping between Excel and VSCode.

And, in the implementation discussed above, most of the cells were full of numeric/string values or references to assets.

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

#254

Post by monkeyelite »

jayd16 wrote: post #251
monkeyelite wrote: post #193

Earlier quoted context omitted.

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

> 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. This is the entire point of using an engine. You can spend time on the content instead of coding features that aren't unique. Suddenly many types of content are far less costly.

I’m saying the real cost is the content.

It’s not hard to implement any of these features, you just don’t have time to do them all.

I agree an engine can be a good prototyping tool.

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

#255

Post by noduerme »

archagon wrote: post #228
noduerme wrote: post #53

I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat ... all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point... a fairly low level (for script) rendering library like…

Games are “dead” in the same way that music is “dead.”

I'm not saying there isn't a ton of brilliant creativity in the field. But there's no path to success in either of those fields. If there ever was, it was when spending 2 years perfecting a game or an album could separate you from the pack, if you were talented. To some extent, the work you did could stand up for itself, without everything being contingent on luck and how much you were willing to make yourself a social media tool. I didn't mean games and music are "dead" in the sense that no one is innovating. Lots of people are. I mean that for people who need to know that they aren't going to waste years building something beautiful that will be forgotten ten seconds later, indie games are no longer a lucrative area unless you have a fat bank account and can afford to waste a couple years of your life.

As a creative outlet, I'll always love making games that no one will ever play, but that's a hobby and not a job.

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

#256

Post by danielscrubs »

xandrius wrote: post #198
ms-menardi wrote: post #50

Earlier quoted context omitted.

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.

100% of hobby game devs do it as a hobby. The learning process is the fun part. Which is also why 99% give up on their game when they see more learning potential in another area.

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

#257

Post by interludead »

maccard wrote: post #98
interludead wrote: post #40

Earlier quoted context omitted.

If your vision is weird or niche, building a toolset around that from day one can be way more efficient in the long run

Games like Antichamber do non-euclidean space and rendering in Unreal (3). Enera (an upcoming action game) manages time rewinding (a la braid), in Unreal. Superhot is Unity, etc. The best tool is the one you know, even if your vision is weird or niche. At the end of the day, you can always ignore all the bits and pieces unity gives to you and just write custom logic in your MonoBehaviour scripts and use it as a platf…

I think my point was more that if your vision diverges heavily from the "normal" flow of those engines, sometimes it's just less friction to build your own
Post reply on HN