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

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

#121

Post by orthoxerox » Tue, Apr 05, 2022, 10:31 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…

> I've noticed this in many hobby professions - eg. hobby woodworkers spending more time on creating workbenches/tools/jigs/sleds than actually building some projects

As a hobby woodworker, I was saved from this by circumstances: I couldn't build a workbench in the old shed, I couldn't build a new shed at the time, but I needed a new nighstand ASAP because my son needed a larger bed, so I had to make it on an old kitchen table in the old shed.

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

#122

Post by Agentlien » Tue, Apr 05, 2022, 10:32 AM UTC

maccard wrote: post #104

csande17 wrote: post #37

Earlier quoted context omitted.

For me, at least, I like to write my own engines to get the end-user experience I want. Every game engine comes with a million little decisions about how games should work by default, and writing my own engine lets me make those decisions for myself. In the same way, every React app eventually starts to look and act like the Reddit redesign, but many web developers consider that more of a benefit than a drawback.

> every React app eventually starts to look and act like the Reddit redesign, Not every unreal engine game starts to look and behave like gears of war. If you drop a bunch of asset packs from the store it's going to look like every other asset flip out there, but so will your game engine if you use the same assets. > , I like to write my own engines to get the end-user experience I want. My day job is working in unre…

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 Render Pipeline (URP) and found myself having to implement some things I just couldn't understand were missing. For instance, URP supports a depth prepass for opaque objects but still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass.

Just binding the already generated one instead allows you to get a lot of free depth culling and in my mind is one of the main reason to use a depth pass. But in URP it was apparently used exclusively to feed depth information to shaders.

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

#123

Post by Agentlien » Tue, Apr 05, 2022, 10:39 AM UTC

selfmodruntime wrote: post #99

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…

Both industry leaders and indie programmers have used Unity and Unreal to make finished games. Large studios may opt to create their own engines at one point or another, but even with all their resources, these custom engines don't always work out. An example of this would be the frostbite engine, of which multiple devs at EA reported that it was an absolute nightmare to work with. Turns out, if you need developers t…

I worked with Frostbite for five years. The engine is very capable. It's also developed in a vacuum with very little exposure to actual game development.

It's used to create fancy new features and show them off in tiny toy projects. Then it's handed off to developers to make actual games and the issues begin.

The biggest issue with Frostbite was always that its developers treated it like an ever revolving set of cool new projects. There was always some fancy new system meant to replace the old one in just a few years and never any fixes for the shipped and still broken systems.

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

#124

Post by EdwardDiego » Tue, Apr 05, 2022, 10:40 AM UTC

verdagon wrote: post #2

Always a pleasant surprise to be scrolling through HN and seeing one of my articles on the front page! For anyone interested in how that code would get zero memory safety overhead without the classic borrow checker, a big part of it is because of the "region borrow checker" [0]. There are some other factors (iso regions, hybrid-generational-memory, etc.) but region borrow checking is the big one. [0] https://verdagon…

Is this blog entry out of date? Or is this still a WIP?

> Note that hybrid-generational-memory is not implemented yet, it's still just a design.

From https://verdagon.dev/blog/hybrid-generational-memory

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

#125

Post by orthoxerox » Tue, Apr 05, 2022, 10:40 AM UTC

pjmlp wrote: post #75

gary_0 wrote: post #64

Earlier quoted context omitted.

C# is very fast on average, but due to its runtime/GC it won't give you the consistent performance you need for game engine internals, which is what they meant by "slow".

Unless we are talking about Assembly, all languages have runtimes. As for the GC, it can be turned on in critical code paths, C# supports manual and stack memory allocation. Profilers exist, many console games have been shipped in C#, besides Unity, there are Xenko, FNA and MonoGame custom builds for game consoles. Compare the demo on the blog with, https://store.steampowered.com/app/236090/Dust_An_Elysian_Ta... http…

There's also Terraria, which is the 15th best-selling game of all time. Written in C# (XNA).

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

#126

Post by jhanschoo » Tue, Apr 05, 2022, 10:46 AM UTC

tikkabhuna wrote: post #120

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 methodology has fascinated me recently. With the Battlefield 2042 debacle, its interesting to compare it to what I know (financial trading platforms). With trading platforms, they last for years, decades maybe. They're created with some ideas around how to manage performance and to support evolving requirements. Developers know this thing is going to be around for a long time, so its treated as such.…

> Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Much seems to be from scratch.

I think this should be qualified. The audience and creative workers demand new assets for new titles, but gameplay concepts and codebase seem to move at a slower pace, though live services seem to be distinct systems and not expected to live long, of course.

On one extreme, you have EA's sports titles, where new releases have just incremental updates.

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

#127

Post by linspace » Tue, Apr 05, 2022, 10:46 AM UTC

arduinomancer wrote: post #15

I don’t get why are programmers so obsessed with the tools they use for the job? More than any profession

Aren't computers tool themselves? It's only natural people interested in computers are interested in tool making

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

#128

Post by mijoharas » Tue, Apr 05, 2022, 10:56 AM UTC

verdagon wrote: post #2

Always a pleasant surprise to be scrolling through HN and seeing one of my articles on the front page! For anyone interested in how that code would get zero memory safety overhead without the classic borrow checker, a big part of it is because of the "region borrow checker" [0]. There are some other factors (iso regions, hybrid-generational-memory, etc.) but region borrow checking is the big one. [0] https://verdagon…

fyi, your links on that page to hybrid generational memory seem incorrect (i.e. 7 in the sidebar, but I think there was another).

I'd not heard of vale, but after reading around a little looks very interesting. Nice job!

[0] https://verdagon.dev/blog/hybrid-generational-memory

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

#129

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

Agentlien wrote: post #122

maccard wrote: post #104

Earlier quoted context omitted.

> every React app eventually starts to look and act like the Reddit redesign, Not every unreal engine game starts to look and behave like gears of war. If you drop a bunch of asset packs from the store it's going to look like every other asset flip out there, but so will your game engine if you use the same assets. > , I like to write my own engines to get the end-user experience I want. My day job is working in unre…

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 my original message didn't come across as "there is no work involved in using a preexisting engine!"

> To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass.

Presumably implementing that was _far_ less work than writing a URP yourself, and that's before you take into account the benefit of the art/design pipelines being able to use the render pipeline for the X months it would take you to write one yourself.

That example doesn't effect the "user experience" of the game either (which is what the GP comment claimed they wrote their own engines for), but that's not to say it's not worth doing!

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

#130

Post by adampk » Tue, Apr 05, 2022, 11:09 AM UTC

tikkabhuna wrote: post #120

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 methodology has fascinated me recently. With the Battlefield 2042 debacle, its interesting to compare it to what I know (financial trading platforms). With trading platforms, they last for years, decades maybe. They're created with some ideas around how to manage performance and to support evolving requirements. Developers know this thing is going to be around for a long time, so its treated as such.…

If you don’t mind a digression for someone who needs help…

What is the architecture pattern of a trading platform?

I am looking to build a system that is able to: - receive 1000s incoming streams of data - save the data - make data available to live subscribers

The closest analogous system I can think of is bond/stock/commodity/etc price subscriptions for traders.

I feel like this many in - many out data stream architecture should be solved by now and I rather not start from scratch in architecture and technology choices.

I can’t find the right phrase to even google to get started.