QuoteClosing thoughts

QuoteWe've been using Rust on basically all of our games since mid 2021. This was when BITGUN initially started as a Godot/GDScript only project, and as we ran into issues with Godot's pathfinding (both performance and functionality wise) I looked into alternatives [..]

Quote[..] the article isn't written from a point of ignorance or not trying the correct approach. The #1 argument I hear people say when someone points out issues with Rust as a language is, jokingly, "you just don't have enough experience to appreciate this". We repeatedly tried both more dynamic and fully static approaches to doing things. We tried pure ECS, and we also tried no ECS.

I don't know if I'm correct about what I want, but very few points here have at all contradicted what I think I want.
In particular, I suppose I don't think that this person did ever try the correct approach, because the game that they produced looks like it was made by a Unity dev. This is not meant to be derogatory, it has a kind of vibe about it. It doesn't strike me as the kind of game I'd seek to make with something like Rust, and I can see where trying to design a game like this full of casual rules exceptions and stuff would run into problems.

QuotePositives of Rust

i will take this section with a grain of salt but maybe it will be useful!

- nice compiler (i know this already, yes it is quite nice)
- it is performant (cool, truly good to know!)
- enums are nicely implemented (yes so are a bunch of other things, it's a nice language for programmers)
- weird backhanded compliment about a feature i know nothing about, skip
- traits (see comment on enums)

hmm

'orphan rule' ... this is something about rust crates, i.e. the ecosystem ... i don't know if i have the capacity to care about ecosystem woes

compile times ... i care about this a lot! no clear information, i'll have to try it for myself

people are excited about Rust, there's hype ... i don't care, this might be useful to someone who has been touched by Rust hype, i have not. ah, more about the ecosystem, e.g. there's no good 2D physics library! i don't mind. i'm going to be making weird little systems, i grew up in a time when physics engines were not good. when i use Godot's physics engine i feel a bit filthy and i constantly expect it to break. i will never outgrow this feeling, i suspect.

... something about global state, too complicated for my sleepy brain right now to read
... something about crashes and 'dynamic borrow checking', is this a real thing
... skip skip skip, sleepy brain, forgive me tomorrow

"the problem with rust is nobody has written a nice library to solve a complicated problem that i don't want to solve myself"... ok i just have to sanity check, what engines did this person say they've used

QuoteWe've released a few games across Rust, Godot, Unity, and Unreal Engine, and [..]

OH, THEY'RE COMING FROM ONLY HAVING USED THOSE ENGINES, AND BEVY/RUST???

next three points are complaints about specific GUI implementations in the ecosystem. sure, whatever. i like Godot's system. i also like HTML and CSS. most other GUI systems are crap and all i need is to draw some text to the screen anyway.

QuoteWhat I'd want instead is to have a very pretty GUI, with lots of custom sprites, animations, vector shapes, particles, effects, flashes, etc. I want my button to wiggle when it's clicked, I want my text to animate as it's hovered, I want to be able to use a custom shader and distort it with a noise texture. I want particles to fly around when a character box is selected.

so just, like, do those things???

I'm not going to go bullet by bullet anymore, I don't think it's worth it. Clear formatting isn't worth it, anyway. Let's see.

"Procedural macros" ok ok ... "using reflection in C# is extremely easy, and if performance is of no concern (which it often isn't in cases where reflection is used) it can be a very quick and useful option for building tools or debugging. Rust doesn't offer anything of the sort" ... well I do like tools and debugging, in theory! In theory. Somehow I've managed to make games with bad tools and debugging habits. Maybe it has created an obsessive need for completely understanding a structure. But debugging has always been kind of a nightmare. This sounds so dumb but why not just make a game that you don't have to debug that much??? Huh???

...

"Hot reloading is more important for iteration speed than people give it credit for"

I AM NOT CONVINCED THAT THE TOMORROW CORPORATION TECH DEMO ACTUALLY REPRESENTS SOMETHING
USEFUL FOR ME. I don't work with others well. I just want to understand the thing I'm building -- and I can get to the finish line that way.

"Debugging with immediate mode drawing/geometry. This is probably my favorite use case, especially around debugging character controllers and physics, where I might enter an unexpected/buggy state, and with hot reloading I can simply add a line few lines to draw the relevant values in-game to see what's happening without having to reproduce the issue again."

Yeah, this is legit. One of the biggest issues I had with trying to break out of Godot a while back was how difficult it was to get the onscreen representation of something to work. Being able to visually wiggle a thing around to get it into the right spot or to go at the right speed... really useful. A killer feature, compared to bare code.

I'd rather have a good tool than hot reloading. Hot reloading is a crappy cheap half-measure. Sometimes you need a crappy cheap half-measure but I don't like 'em.

QuoteMaking a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that

Again, this seems like it sums up previous points... holy hell, I hate the way this article is laid out. Truly genuinely awful. Impossible to parse.

I just want to say that the problem being described is not a technological problem. Nobody is forcing you to prototype in Rust, it's a game engine not a prototyping tool. These are allowed to be separate things. As a designer, you may choose to prototype in the same engine in which you program your game, but that is a choice. Hmm. I need to get this through to myself somehow.

QuoteECS solves the wrong kind problem

Not a useful header. OK, so what's the content of this section? What is 'the wrong kind of problem'?

Quotemany times people use ECS because it solves the particular problem of "where do I put my objects", without really using it for composition, and without really needing its performance

OK, interesting. I skimmed the previous chunk of this section, but I saw there was some stuff about performance. I, too, do not really need performance. But composition? What's that?

... back

QuoteECS as dynamic composition, allowing combinations of components to be stored and queried and modified together without having to be tied in a single type.

OK, what's the benefit of this, why might I care...

QuoteI've been in countless arguments where someone tried to convince me how I absolutely should be separating Position and Health out of my objects, and how my code is spaghetti if I'm not doing that.

Oh, I've encountered this, haha. Yes, LogLog, we're on the same side of this argument here. I also like "fat components."

Quotegenerational arenas generational arenas generational arenas

I don't have a clue what generational arenas are. TODO: What are generational arenas?

QuoteGeneralized systems don't lead to fun gameplay

OK... Immediate response: fun systems can be generalized, though.

QuoteHere's a few things that I think create good games, that are going directly or indirectly against generalized ECS approaches:

A lot of these are things that don't quite gel with how I've designed some of my games, like Probability 0, Starseed Pilgrim... but  since moving to Godot I have made a lot more games that leverage this particular strength of Godot. But for the most part these are things I kinda don't like? I won't get into it.

I'll bring this one up though because I'm not sure what's being described:

Quote- VFX that are not based on having lots of same-y particles, but time synchronized events (e.g. multiple different emitters firing on a hand-designed schedule) working across all the game's systems.

Oh, okay, this is just talking about a thing that needs a timeline. Not really my jam.

QuoteA good example game here would be The Binding of Isaac, which is a very simple roguelike with hundreds of upgrades that modify the game in very involved, interactive and deeply complex ways.

Hmmmmmm. I disliked BoI and I think this might be part of why? Hmmmmmmmm.

When I designed SSP I wanted "La-Mulana but it follows an underlying logic." I like an underlying logic. It's fine if that's not what you want to make, though.

QuoteRust is the type of language where wanting to do a new type of upgrade might lead you down a path of refactoring all of the systems, and many would even say "that's great, now my code is much better and can accommodate so many more things!!!". It sounds like a very convincing argument [..]

Actually it really does not sound like a very convincing argument at all!
This sounds like hell. Don't... don't do this. Or, I should say, I don't want to do this, I want to lay out a big block, a big canonical system, and say "This is the game," and then carve pieces out of it.

I still think about the one side chamber in PZERO. It felt like I was breaking a rule. I was breaking a rule. It was significant to me because I set rules up ahead of time and then the game was allowed to live and breathe within those rules.

Making games not like that seems like an exercise in madness now that I'm thinking clearly about it.

QuoteA more flexible language would allow the game developer to immediately implement the new feature in a hacky way, and then play the game, test it and see if the feature is actually fun, and potentially do a bunch of these iterations in a short amount of time.

See above.

Oh, the author links this talk about game design as search. Good talk, I recommend it.

Game design as search. Hmm. I'm beginning to wonder.

QuoteIndirection only solves some problems, and always at the cost of dev ergonomics

I don't really get what Indirection is, but this point can really be lumped in with the last point, to form a "Rust is slow at iterating crazy new stuff" point.

My recent experience with organizational game dev has been that I actually hate trying crazy new stuff? I don't know how else to describe this. I like creating extensible systems and then working within them, extending them in ways that fit with everything else. Rust is sounding more and more like my jam. This raises a small red flag for me:

QuoteWhat would be 3 lines of code in C# suddenly becomes 30 lines of Rust split into two places.

... but it's not tangible enough for me to really understand, and the Rust counter-argument as presented by the author is that maybe you shouldn't be trying to do this thing (see below) if it's making your code all crazy:

QuoteThe most canonical example here is something like: "while I'm iterating over this query I want to check a component on this other thing and touch a bunch of related systems" (spawn particles, play audio, etc.).

I'm tempted to stop reading, because I think this author is coming from a very different place than I am... hmm. I do value making little game prototypes in a rapid engine, and I've done it a lot over a long period of time. But where am I now? Starseed Pilgrim was not a game that involved a lot of rapid prototyping, for instance. I set up a system and worked out its problems. There was not too much prototyping. I designed some behaviours on paper, and I implemented them.

summary of points 1-2. "Rust forces you to refactor a lot if your code is bad." ok.

QuoteRust being great at big refactorings solves a largely self-inflicted issues with the borrow checker

It's very often said that one of Rust's greatest strengths is ease of refactoring. This is most definitely true, and I have had many experiences where I could fearlessly refactor significant parts of the codebase, with everything working afterwards. Everything works as advertised?

A-ha. I see, I finally understand the structure of this article. I say 'finally' -- it didn't take too long, only two headers in out of... however many. But the construction of the article is not very good, which is to say, it could be a lot better; I had to infer a whole structure that could have been described to me instead.

---

ACTUALLY, LOOKING AHEAD, NEVERMIND. THE HEADERS JUST SUCK AND ARE CONFUSING. Some of them are the writer speaking, and others are strawman-esque quotes, and it is extremely unclear which is which. No wonder the article is so damn confusing to parse at a glance.

QuoteIn Rust, sometimes just doing a thing is not possible, because the thing you might need to do is not available in the place where you're doing the thing, and you end up being made to refactor by the compiler, even if you know the code is mostly throwaway.

OK: this does sound annoying. Rust: 1, LogLog: 1

It might be fine. I'm not sure. I'm thinking about how annoying it is to crawl through the node tree in Godot, how messy and awful it feels, and how much of a struggle it is to climb through it to the place where I want to be.

Or, actually, it's quite fast, but it feels gross. It's messy. Hmm. I'll still give LL the point.

Quotethe borrow checker forces a refactor at the most inconvenient times [..] I've often found that being unable to just move on for now and solve my problem and fix it later was what was truly hurting my ability to write good code.

This sounds crazy but my brain right now is like, yeah, I actually want this??? Not this specific problem: the borrow checker is actually quite annoying. But I am terrible at coming back to deal with quick fixes. They accumulate and make a project unlivable. Rust: 1, LogLog: 0

Quotetrying to make enough money to fund our development with it. [..] I'm looking at things from the perspective of "I want to make a game in 3-12 months maximum and release it so that people can play it and I can make some money from it.". This is not written from a perspective of "I want to learn Rust and gamedev seems fun", which even though is a valid goal, is not in any way aligned with what we want, which is doing gamedev in a commercially viable and self-sufficient way.

OK, I'm really going to be laser focused on whether this article actually addresses how difficulty developing in Bevy connects with making money. I'm suspicious.

OK, so, this article is a 95 minute read, and I cannot really do a 95 minute read without a system for chewing through it. So here's my system. I'm going to whine about everything that seems wrong.