Leaving Rust gamedev after 3 years

> at the cost of latency and throughput.

Compared to what?

Doing epoll manually?

Clearly he needs a framework for making games in Rust instead of iterating through rust primitives.

> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.

Ah... Starcraft. It's 200 supply per player (hero units take 0 supply, zerglings are 0.5, and the supply cost goes up to 8 for battlecruisers for example). The limit is enforced when building a unit from a building. Map triggers can grant units and you can exceed the 200 supply limit.

The technical unit limit for the map was 1700, and was later in fact extended to 3400 by Blizzard. The EUD emulator (part of the official SC Remastered) allows for online custom games to be played without any third party tools on the player's part. Certain limits like sprites can be bypassed with this tool (for map makers) https://github.com/phu54321/euddraft/blob/master/plugins/unl...

EUD started out as a buffer overflow exploit which allowed custom maps to patch the game client's code. It was later fixed by blizzard but re-implemented as an emulator (with some restrictions).

These are definitely things that enhance gameplay for custom scenarios. https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a battlecruiser shooting nukes)

Absolutely agree. I think people saw that a lot of games are written in C++ and got confused into thinking that the right thing to do is to build your entire game in a systems language. The fact that we have games written entirely in C++ is mostly just due to the enormous amount of inertia that game engines have, and the fact that many of them have origins that go back decades to a time when the programming language landscape and broader development ecosystem were completely different.

And now, the most popular generally available game engines right now are: Unity - C++ in the engine, C# for game code Godot - C++ in the engine code, GDScript or C# for game code Unreal - C++ in the engine code, somewhat mangled C++ for game code BUT with also one of the most capable and widely used visual programming setups I have ever seen

I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.

I've been writing Rust professionally (and predominantly) for ~5+ years now, with brief detours in game dev. I'll defer to others who are dedicated game devs, but overall I think this article is well written and a healthy thing for Rust overall. We need this kind of breakdown if things are going to continue to improve.

I'd say I only have two somewhat arbitrary comments on this piece:

> Rust on the other hand often feels like when you talk to a teenager about their preference about anything. What comes out are often very strong opinions and not a lot of nuance.

This is a rabbit hole of a topic so I don't want to go too deep into it, but this isn't a Rust-specific issue (though it may be a current Rust issue). I've seen this same pattern play out across so many languages over the years, from Lisp to Rust to everything in between.

A very unscientific and definitely not charitable way I've thought about this over the years is that programming, by nature, is an OCD person's dream. We wind up with a pretty large chunk of people who seemingly move language to language in the hype cycles in search of some weird nirvana level that is likely just unobtainable. I feel like Rust has slowly started shedding this as the community has grown/matured and some people have moved on to the next hype cycle but I often find myself wishing it'd happen faster.

I write Rust because when I sleep at night, I just don't get woken up by being paged for nearly as many weird edge cases. The Rust I write often has a litany of compromises because I want to just get shit done and move on with my life, and the remaining guarantees are still good enough. The number of times I've had to tell people to leave it be is definitely higher than it should be.

> I know that just by saying "global state" I'm immediately triggering many people who have strong opinions on this being wrong. I feel this is one of those things where the Rust community has created a really harmful and unpractical rules to put on projects/people.

This isn't really a Rust-specific thing, though I can't fault the author for including it. People have been beating the drum of "no globals" for as long as I can remember... and simultaneously, as long as I can remember, game devs have come out of the woodwork to politely explain that the programming they do is often under very different constraints.

I still periodically use global state for things because it's just faster at points, and no, I've never cared if people get annoyed by it.

Anyway, here's to hoping this leads to positives for the community.