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

Accidentally making a language, for an engine, for a game

verdagon.dev

Post reply on HN
Print view View original

161–170 of 232 posts

Re: Accidentally making a language, for an engine, for a game

#161

Post by remus »

WJW wrote: post #108
selfmodruntime wrote: post #100

Earlier quoted context omitted.

I disagree. Modern web browsers are the most complicated pieces of technology we have today. The amount of work that goes into sandboxing and security alone probably eclipses the complexity of game engines.

That seems very optimistic when compared to some of the bigger engineering projects we have going as humanity. Aircraft carriers and nuclear submarines as a whole system (including the multiple computer networks and their software) are much more complex than browsers, to say nothing of one-offs like the ISS (lots of cutting edge hardware but also full of software) and the systems controlling modern factories. Browser…

I think it's kind of hard to quantify complexity in a way that compares nicely across domains. For example, a lot of the complexity in a browser comes from needing to service ~billions of users across thousands of devices using loosely implemented standards. This is quite a different problem to building an aircraft carrier, where you're going to run in to hard engineering and physics problems but you only have to target ~10k well trained users.

Re: Accidentally making a language, for an engine, for a game

#162

Post by AnIdiotOnTheNet »

maccard wrote: post #146
marginalia_nu wrote: post #133

Earlier quoted context omitted.

Depends entirely on what you want to do. Use a bog standard engine, and you get Satisfactory. If you build your own, you can have Factorio. The former will never reach the sort of simulation complexity the latter can even on modest hardware.

> The former will never reach the sort of simulation complexity the latter can even on modest hardware. You're comparing games rather than engines here. There is no reason at all that you can't write your simulation logic in vanilla bare bones C++ as factorio has done, and still get the benefit of using an existing engine. You get all the neat (and hard) things like serialisation, multiplatform support, networking, a…

But you'll always be fighting the engine, because these kinds of "one size fits all" engines are complex enough to be essentially another operating system above the one you'd otherwise be dealing with. As long as your desires are well aligned with the abstractions it presents it will probably save you time, but the more you drift from that the less time it will save you and eventually there's a point where dealing with it costs more time than it saves.

For the level of performance the Factorio devs want it makes sense they'd opt for maximum control over everything rather than fighting someone else's implementations.

Re: Accidentally making a language, for an engine, for a game

#163

Post by maccard »

Agentlien wrote: post #140
maccard wrote: post #129

Earlier quoted context omitted.

> I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features. Agreed wholeheartedly, and this is part of game development. Sometimes that comes in the shape of adding features that are straight up unfinished, other times it comes in bugfixes/workarounds. I hope m…

It was absolutely a tiny amount of effort in comparison to developing your own fully featured render pipeline. As is anything I've had to do. That is, after all, the point of using a commercial engine. It does the heavy lifting, I just need to tweak it. > I hope my original message didn't come across as "there is no work involved in using a preexisting engine!" Absolutely not. I've come across the argument about maki…

> Let me finish by saying that it's true, unless you count your game having stable frame rate on weaker platforms as part of the user experience. ;)

While this is true, it's also not a "given" from a custom engine and needs to be planned for. It's a big ask for a team to reimplement their renderer as a forward renderer, but it's a checkbox in UE4 (plus reimplementing all the materials etc).

Re: Accidentally making a language, for an engine, for a game

#164

Post by AnIdiotOnTheNet »

maccard wrote: post #159
marginalia_nu wrote: post #152

Earlier quoted context omitted.

The problem is you can't deal with the number of entities factorio regularly does on a stock engine. They just aren't made to deal with hundreds of millions of stateful and non-trivially interacting entities. That's not what game engines are built optimized for.

Just because you're using unreal doesn't mean you need to have one actor per entity (for example). Using [0] as an example, there's no reason you can't implement a cache optimized simulation algorithm in C++ and pass the results out to UE4 instead of whatever layer factorio is using. To be fair, factorio is a pretty good example of when the existing options offer limited value (lock step networking, _very_ simplistic…

Using Unity for a 2D side scroller is like using a sledgehammer to swat a fly. 2D side scrollers don't really need much in the way of an 'engine'.

Re: Accidentally making a language, for an engine, for a game

#165

Post by Agentlien »

marginalia_nu wrote: post #152
maccard wrote: post #146

Earlier quoted context omitted.

> The former will never reach the sort of simulation complexity the latter can even on modest hardware. You're comparing games rather than engines here. There is no reason at all that you can't write your simulation logic in vanilla bare bones C++ as factorio has done, and still get the benefit of using an existing engine. You get all the neat (and hard) things like serialisation, multiplatform support, networking, a…

The problem is you can't deal with the number of entities factorio regularly does on a stock engine. They just aren't made to deal with hundreds of millions of stateful and non-trivially interacting entities. That's not what game engines are built optimized for.

I think you're underestimating what can be done with the industry standard engines. From a rendering perspective modern game engines can handle so much stuff that it will fill your screen entirely. Just look at UE5's Nanite which supports ridiculously massive scenes and splits the frame into roughly pixel-sized triangles to render at interactive frame rates.

If you do end up in a situations where you have more objects than is suitable for even these systems to simulate you don't need to throw the baby out with the bath water. Create your own managers running whatever simulation you wish without tying the units directly to the most obvious game engine entities, with whatever scheduling you need to make the updates work with the compute budget you have. Use the engine entities to represent whatever higher level object makes the code manageable and easy to work with.

Then you can surely leverage the game engine for input handling, rendering, and a lot of your logic, just writing your own code for whatever challenges are unique to your game and where the standard approach for that engine is unsuitable.

Re: Accidentally making a language, for an engine, for a game

#166

Post by Agentlien »

maccard wrote: post #163
Agentlien wrote: post #140

Earlier quoted context omitted.

It was absolutely a tiny amount of effort in comparison to developing your own fully featured render pipeline. As is anything I've had to do. That is, after all, the point of using a commercial engine. It does the heavy lifting, I just need to tweak it. > I hope my original message didn't come across as "there is no work involved in using a preexisting engine!" Absolutely not. I've come across the argument about maki…

> Let me finish by saying that it's true, unless you count your game having stable frame rate on weaker platforms as part of the user experience. ;) While this is true, it's also not a "given" from a custom engine and needs to be planned for. It's a big ask for a team to reimplement their renderer as a forward renderer, but it's a checkbox in UE4 (plus reimplementing all the materials etc).

I certainly agree. I'm really not arguing for writing your own engine as anything other than an excellent learning exercise. I've written my own engines and renderers (both forward and deferred) and I'm more than happy to rely on whatever engine we happen to be using at work to solve most hairy issues for me.

Re: Accidentally making a language, for an engine, for a game

#168

Post by cmrdporcupine »

Being distracted building tooling and frameworks is one of the harder things I find with personal projects.

In paid $work, there is a) an imposed direction and usually a schedule from a customer b) often a team of people to distribute work to, and to help keep one disciplined.

Example: I'm writing a VST synthesizer, virtual instrument, as a personal project in my time off between jobs. Maybe I'll make it commercial someday, not sure. I became increasingly frustrated with the half-assed portable GUI toolkit bundled with the VST3 SDK ("VSTGUI"). There's a complete lack of decent cross platform UI options that will work in this context (QT won't do it here, for reasons.)

I realized that there's already a cross platform UI option with millions of man hours put into it: the web. So I have spent the last three or four weeks writing a bridge to embed Edge-Chromium, WebKit, etc. Have that working on Win32, at least (still have to do the work for Linux & Mac, but ok).

Then on to actually making the UI in this platform. Now I'm learning npm, webpack, TypeScript.

Need a nice little HTML/CSS knob for my UI. Most are bundled in a giant framework I don't want. Oh, here's one in pure JS. But, hm. I think I'll refactor this into Typescript. Now it's forked, just for me.

Ok, well, yes I have that mostly working. Some warts, but basically is very similar to the "native" (VSTGUI) UI I had before. But now I want to write a graphical envelope editor. Off to learn HTML Canvas drawing.

Many parts of this whole process could themselves be spun off into separate projects, that I could spend years maintaining, on their own.

And so it goes. The Yak is pretty shaved at this point.

Re: Accidentally making a language, for an engine, for a game

#169

Post by maccard »

AnIdiotOnTheNet wrote: post #164
maccard wrote: post #159

Earlier quoted context omitted.

Just because you're using unreal doesn't mean you need to have one actor per entity (for example). Using [0] as an example, there's no reason you can't implement a cache optimized simulation algorithm in C++ and pass the results out to UE4 instead of whatever layer factorio is using. To be fair, factorio is a pretty good example of when the existing options offer limited value (lock step networking, _very_ simplistic…

Using Unity for a 2D side scroller is like using a sledgehammer to swat a fly. 2D side scrollers don't really need much in the way of an 'engine'.

Reimplementing all of the features that unity provides for you is time spent on "just" adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations, when you could have been building a game. I can spend a month building a bare bones C++ engine that gives me all of the above and start into my game, or I can download unity, start with all of those features and spend a month working on my game.

Re: Accidentally making a language, for an engine, for a game

#170

Post by AnIdiotOnTheNet »

maccard wrote: post #169
AnIdiotOnTheNet wrote: post #164

Earlier quoted context omitted.

Using Unity for a 2D side scroller is like using a sledgehammer to swat a fly. 2D side scrollers don't really need much in the way of an 'engine'.

Reimplementing all of the features that unity provides for you is time spent on "just" adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations, when you could have been building a game. I can spend a month building a bare bones C++ engine that gives me all of the above…

Sure, and then deal with leaky abstractions and fighting the engine wherever its abstractions don't give you what you want.

> adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations

None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be. And there's value in having complete control over your product and understanding how every part of it works. You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.

I'm not saying it's the wrong choice to use a bespoke engine, indeed many games that are made with bespoke engines would not have been made otherwise and I'm grateful that such things exist and enable those games to be made, I'm just saying it's not necessarily a bad idea to make your own engine. Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.

Post reply on HN