Accidentally making a language, for an engine, for a game • Hacker News Board

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

#131

Post by maccard » Tue, Apr 05, 2022, 11:10 AM UTC

marginalia_nu wrote: post #119

Centigonal wrote: post #46

I don't know what it is about game development that really brings out the yak shaving in people. One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator. Well, it's been eight years, and development is still going strong! The developer is currently working on the String implementation for the programming language he invented[2], wh…

Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch. I'm having a lot of the same struggles working on my search engine. What I want to do with files is often somewhere between what the…

> Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game.

The vast majority of games don't need to be low level for performance. Practically nobody outside of massive AAA studios is writing architecture specific assembly for modern PCs or consoles (and even in those studios, there are very few people doing so). The majority of gameplay programmers are writing bog standard C++ that would be just as performant in C#, or in many cases a lot of the logic is written in a higher level scripting language that is orders of magnitude slower than the native C++, or even just writing all of the game code in something like C#.

> Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch.

Oh for sure, and there often are better ways to solve these problems. In my experience, one of the most common reasons for not doing things better is because the codebase is based on an engine from 20+ years ago when they _did_ have to avoid interfaces and virtual function calls for game performance, and you have "modern" systems that are built on top of those abstractions (in the same way that lots of modern networking libraries still leak details about concerns from the 80s/90s)

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

#132

Post by eternityforest » Tue, Apr 05, 2022, 11:14 AM UTC

marginalia_nu wrote: post #119

Centigonal wrote: post #46

I don't know what it is about game development that really brings out the yak shaving in people. One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator. Well, it's been eight years, and development is still going strong! The developer is currently working on the String implementation for the programming language he invented[2], wh…

Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch. I'm having a lot of the same struggles working on my search engine. What I want to do with files is often somewhere between what the…

Is that really true though? Aside from graphics and physics, which seems to be highly reusable, where's the performance critical stuff? Lots of engines seem to be mostly using scripting languages for everything a game developer needs to do.

I wonder if there's a DBMS out there somewhere that already does what you need? Seems like by the time you got to a scale where you would need custom stuff, you'd have money to redo it(Unless it's a foss thing meant to be big but not commercial, or to run on a server you're paying for yourself)

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

#133

Post by marginalia_nu » Tue, Apr 05, 2022, 11:15 AM UTC

maccard wrote: post #131

marginalia_nu wrote: post #119

Earlier quoted context omitted.

Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch. I'm having a lot of the same struggles working on my search engine. What I want to do with files is often somewhere between what the…

> Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. The vast majority of games don't need to be low level for performance. Practically nobody outside of massive AAA studios is writing architecture specific assembly for modern PCs or consoles (and even in those studios, there are very few people doing so).…

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.

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

#134

Post by SeasonalEnnui » Tue, Apr 05, 2022, 11:16 AM UTC

For any comparison to C# (it being slower or having GC pauses), it probably doesn't take into account the latest advances (.NET 6). That's understandable given there isn't really incentive to gain a mastery in every language during a comparison.

With regards to C#/.NET 6, it is now easy to:

- Have zero-allocation code through the whole stack, making garbage collection zero/near-zero. [Span, Memory]

- Distribute platform specific all-in-one binaries with no unbundling/uncompression or need to install any runtime. [dotnet publish -r win-x64 -c Release -p:PublishSingleFile=true -p:PublishTrimmed=true]

- For hot-path optimisation (many available profiling tools), dive into new high-performance APIs such as CPU vector intrinsics, or native memory allocation (aligned or unaligned). [System.Runtime.Intrinsics.X86, System.Runtime.InteropServices.NativeMemory]

- For faster startup times: AOT compilation. (Not necessarily faster at runtime in general; JIT has advantages there with being able to detect hot paths)

These are just the features I've used, there are doubtless many more. In the future .NET 7, it will be possible to disable runtime marshalling so interop calls to C DLLs have no overhead (along with a compile-time analyzer to throw errors if the types you're using are not compatible, aka 'blittable').

Credit to Vale - it appears to be addressing all these things so there's certainly an interesting future ahead.

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

#135

Post by marginalia_nu » Tue, Apr 05, 2022, 11:16 AM UTC

eternityforest wrote: post #132

marginalia_nu wrote: post #119

Earlier quoted context omitted.

Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch. I'm having a lot of the same struggles working on my search engine. What I want to do with files is often somewhere between what the…

Is that really true though? Aside from graphics and physics, which seems to be highly reusable, where's the performance critical stuff? Lots of engines seem to be mostly using scripting languages for everything a game developer needs to do. I wonder if there's a DBMS out there somewhere that already does what you need? Seems like by the time you got to a scale where you would need custom stuff, you'd have money to re…

Sure. What about simulation? Like I mentioned Factorio in your neighboring comment. It does things with a custom engine that you simply can't do using "highly reusable" systems.

Existing engines are great as long as you want your game to look and behave like every other game written in the same engine. It's gotten to a point where a careful observer can tell which engine a game is written in just by looking at it and feeling how much input lag and framerate variance it has.

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

#136

Post by huseyinkeles » Tue, Apr 05, 2022, 11:18 AM UTC

moonchrome wrote: post #85

Centigonal wrote: post #46

I don't know what it is about game development that really brings out the yak shaving in people. One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator. Well, it's been eight years, and development is still going strong! The developer is currently working on the String implementation for the programming language he invented[2], wh…

>I don't know what it is about game development that really brings out the yak shaving in people. People get into game development because they want to have fun programming. Getting projects done involves a lot of things that are not fun, so it usually goes nowhere because the incentives are misaligned. I've noticed this in many hobby professions - eg. hobby woodworkers spending more time on creating workbenches/tool…

In my first year of 3D printing, I printed mostly parts about upgrading and modding my 3D printer.

But the good thing is it also made me get used to the whole process of refining a 3D print and after a year I barely started to print functional&useful things.

So yeah, I don't see a problem with this approach :)

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

#137

Post by pjmlp » Tue, Apr 05, 2022, 11:19 AM UTC

SeasonalEnnui wrote: post #134

For any comparison to C# (it being slower or having GC pauses), it probably doesn't take into account the latest advances (.NET 6). That's understandable given there isn't really incentive to gain a mastery in every language during a comparison. With regards to C#/.NET 6, it is now easy to: - Have zero-allocation code through the whole stack, making garbage collection zero/near-zero. [Span , Memory ] - Distribute pla…

I think many of these complaints tend to be focused on the aging Mono runtime experience used by Unity pre-DOTS, or classical pre-.NET Framework 4.5.

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

#138

Post by eternityforest » Tue, Apr 05, 2022, 11:19 AM UTC

selfmodruntime wrote: post #100

meheleventyone wrote: post #73

Earlier quoted context omitted.

I’d go an order of complexity above again. The real comparison is to the browser, particularly for general purpose engines like Unreal and Unity. I’d hazard most game engine teams are bigger than most browser teams.

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.

Web frameworks are nowhere near as complicated as browsers

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

#139

Post by Aeolun » Tue, Apr 05, 2022, 11:21 AM UTC

boredtofears wrote: post #61

Townley wrote: post #19

It's interesting that this phenomenon is much more prevalent in game development, as opposed to (for example) web development: some people build their own web development frameworks, but it seems like every game dev tries to make an engine at some point. My theory why: good web frameworks consider developer experience to be of paramount importance, and invest heavily into examples, documentation, and API improvements…

Making a game is at least an order of magnitude harder than making a website. Web apps are constrained by the protocols upon which their built (mostly the lifecycle of HTTP requests). Games are gigantic state machines that also require complicated rendering cycles. Unity and godot et el ARE good developer experiences in that they remove much of the complicated stuff even if the abstractions they use require them to b…

This is only true if you talk about the average website, and the average game. Because there is a lot of wordpress spam.

I can practically guarantee that any given AAA game is less complicated than the horrible morass of complicated system requirements a multinational company can invent for their internal systems.

Mostly because it’s designed to approximate reality, which is complex.

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

#140

Post by Agentlien » Tue, Apr 05, 2022, 11:21 AM UTC

maccard wrote: post #129

Agentlien wrote: post #122

Earlier quoted context omitted.

In essence I agree that the big engines very seldom get in the way and should be good enough for almost any project. However, 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. To take a fairly recent Unity example I worked on a game using the Universal…

> 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 making a game for the end user experience before and it always strikes me as a case of not understanding the capabilities of your tools. I just wished, more for others who come across this than people with our experience, to add that some modification of the tools is to be expected.

> That example doesn't effect the "user experience" of the game either

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