luaKmua

I'm not used to seeing informed takes on the games industry on Hacker news, but then I looked up to see your name. Love your stuff, your website was mind opening when I was in college.

Indeed an urban legend. Sid Meier himself debunked in his memoir, which is a pretty great read.

Hey there, always appreciate a dialog

Per the separation, I think this was far more common both in older unity games, and also professional settings.

For games shipping on mono on steam, that statistic isn't surprising to me given the amount of indie games on there and Unity's prevalence in that environment. My post in general can be read in a professional setting (ie, career game devs). The IL injection is a totally reasonable consideration, but does (currently) lock you out of platforms where AoT is a requirement. You can also support mods/DLC via addressables, and there has been improvement of modding tools for il2cpp, however you're correct it's not nearly as easy.

Going to completely disagree that Burst and HPC# are unnecessary and messy. This is for a few reasons. The restrictions that HPC# enforce essentially are the same you already have if you want to write performant C# code as you just simply use Unity's allocators for your memory up front and then operate on those. Depending on how you do this, you either can eliminate your per frame allocations, or likely eliminate some of the fragmentation you were referring to. Modern .Net is fast, of course, but it's not burst compiled HPC# fast. There are so many things that the compiler and LLVM can do based on those assumptions. Agreed C# strings are always a pain if you actually need to interpolate things at runtime. We always try to avoid these as much as we can, and intern common ones.

The fragmentation you mention on after large operations is (in my experience) indicative of save/load systems, or possibly level init code that do tons of allocations causing that to froth up. That or tons of reflection stuff, which is also usually nono for runtime perf code. The memory profiler used to have a helpful fragmentation view for that, but Unity removed it unfortunately.

In general when game development comes up here I tend not to engage as professional gamedev is so different than what other people tend to deal with that it's hard to even get on the same page, but seeing as how this one is very directly dealing with my expertise I'll chime in.

There are few things off with the this post that essentially sound as someone more green when it comes to Unity development (no problem, we all start somewhere).

1. The stated approach of separating the simulation and presentation layers isn't all that uncommon, in fact it was the primary way of achieving performance in the past (though, you usually used C++, not C#).

2. Most games don't ship on the mono backend, but instead on il2cpp (it's hard to gauge how feasible that'd be from this post as it lacks details).

3. In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC#, especially with what appears to be happening in the in sample here as the job system will help tremendously.

4. Profiling the editor is always a fools errand, it's so much slower than even a debug build for obvious reasons.

Long story short, Unity devs are excited for the mentioned update, but it's for accessing modern language features, not particularly for any performance gains. Also, I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime, or even sidestep entirely with unmanaged memory and DOTS.

I'm shocked I had to scroll this far down before I saw accessibility mentioned.

I would also recommend that one. Those two were the foundation for my graphics knowledge when I was learning.

I'm a little surprised no one has recommended the Frank Luna books. They're great introductory books. I used the DX9/DX10 books during my education when writing my game engines. I haven't read the DX12 book, but DX9/10/11 were basically the same structure only updated for the new APIs.

https://www.amazon.com/Introduction-3D-Game-Programming-Dire...

Pedantry aside, let's restate as "present the core thoughts" to the user, which still implies value. I agree that most of google front page results are SEO garbage these days, but that's a separate issue from claiming that are summary of a piece of information removes the original of its value. I'd even argue that it transfers it from one entity to the other in this case.

That line of thinking makes no sense. If the "content" had no value, why would google go through the effort of scraping it and presenting it to the user?

No love for Unity here, their licensing debacle was horrendous, but I've seen no indications that DOTS is responsible for CS2 perf issues. Everything I've seen points to other things lacking in the engine (a decent LODing system for example), general optimization issues that'd be present in any game shipped too early, and inefficiencies in the rendering pipeline.

At their heart, that's what pixel/fragment shaders are. They're calculations for determining what color a pixel should be.

A really basic one returning red for every pixel would make a red screen. The most common use would be rendering a textured mesh and determining how lighting should effect it (is it skin? A metal surface?).

Then you can look at crazy things like https://www.shadertoy.com/ which are all purely made in pixel shaders (also that site is run by the creator of the Human Shader)

Competitive games have a variety of ways for players to express their skills. I'm not going to comment on whether or not it's good design, but it is clearly the intended design and that's the important differentiating factor. Competitive games are always going to benefit some players who are good at some specific aspects of them inherently by their nature.

Speaking as a league player and a game developer, the audio cues are 100% cheating and also explicitly against Riot's ToS as stated here: https://support-leagueoflegends.riotgames.com/hc/en-us/artic...

The relevant excerpt: "Exposing information that’s intentionally obfuscated (cooldowns or timers)"

As for all of the other match data mining, that's par for the course in competitive games these days.

FWIW, I get long-term satisfaction from playing a couple of video games that I've become deeply knowledgeable and skillful in. I have a community of friends in each and the process of improving and having a good match is the fun part, rather than the simple act of playing itself. Think of it like becoming really good at chess for the deep games.

Having done work in a variety of contexts from Game Engine development to working in Unity, what you are describing is only true for the most trivial of projects. Larger projects (especially AAA) have so much customization of the engines and pushing of their boundaries that they require just as much technical expertise as engine development for many of the required tasks.

There are advantages and disadvantages for using these engines. They soften the "getting started" part of game dev for newer people, but for complicated projects it tends to be kicking the can down the road for dealing with deeper issues.

You'd be hard pressed to squeeze good perf out Unity while fully using the HDRP and not understanding the ins and outs of the pipeline.