Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

531–540 of 996 posts

Re: Leaving Rust gamedev after 3 years

#531

Earlier quoted context omitted.

It was a few years back that the question came up to the developers of a Call of Duty title. "Is there still code from Quake 3 in COD?". They dodge around it by saying something like "we cannot deny this but e use the most appropriate tech where needed". While not confirmation, I wouldn't be surprised if there is a few nuggets of Q3 in that code base still doing some of the basics. That would be really cool if it is…

If that's the question... Let me assure you that there are decades-old pieces of code inside of, and used to assemble, many modern AAA games coming out of mature studios. The systems and tooling is typically carried forward. I don't think this is some big secret and you've intuited exactly the reason why: > game dev tools are about what can get the best results quickest rather than any sort of technical specifics. It…

Not surprised at all that this stuff sticks around. I find it very endearing actually. Ain't broke, don't fix it!

Re: Leaving Rust gamedev after 3 years

#532

Earlier quoted context omitted.

The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more. Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a…

C# is that language (see Godot, Stride, FNA, Monogame).

Not really, it was adopted. It originated from Microsoft as their post-J++ Java alternative for CLR for the purposes of making it easier to write banking server software and Windows apps.

Re: Leaving Rust gamedev after 3 years

#533

Earlier quoted context omitted.

It was a few years back that the question came up to the developers of a Call of Duty title. "Is there still code from Quake 3 in COD?". They dodge around it by saying something like "we cannot deny this but e use the most appropriate tech where needed". While not confirmation, I wouldn't be surprised if there is a few nuggets of Q3 in that code base still doing some of the basics. That would be really cool if it is…

A lot of big projects have amazing longevity to their older architectural decisions. Unreal still has a lot of stuff in it people that used UE1 would recognize, I did most of my professional development on UE3 and a bunch of that is still pretty recognizable. Similarly Chrome is a product of the time it was first created. And looking into the Windows source is probably like staring into the stygian abyss. There is a…

I remember years back someone form Microsoft calling the windows code base "The Abyss" because of how much technical legacy there was in it.

I think it was Steve Gibson who said that the Windows code base had some very questionable things in it. For instance they had work experience high school students working on code that made it into the final build that was less than spectacular. Like how Windows used to stall when you put a CD in and wouldn't proceed until the disc spun up and started reading data.

Windows 11 probably would still do that but I don't know because I don't have a disc drive any more.

Re: Leaving Rust gamedev after 3 years

#534

As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…

As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.

Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate.

Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game.

---

EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.

Re: Leaving Rust gamedev after 3 years

#535
post #448

Earlier quoted context omitted.

Assuming you have no control over trait implementation, how would that work? To reuse the canonic example: // crate "types" pub struct Thing; // crate "traits" pub trait Action {} // crate "alpha_v0" impl traits::Action for types::Thing {} // crate "beta_v1" impl traits::Action for types::Thing {} // Doesn't exist for beta_v0 Say by transitive dependencies, alpha_v0 and beta_v0 are imported, and due to vulnerability,…

Yes, that's the downside of relaxing the orphan rule. That doesn't mean there has to be a way for the top-level crate to work around that, other than avoiding having both of those in its dependency tree. Ideally, people would tend to put trait implementations for a given pair of crates in a unique library crate, implement them in the obvious way, and provide that as a library for people to use.

You are being modest in explanation.

That's not a downside, that's dependency hell with Trait coherency landmines.

Re: Leaving Rust gamedev after 3 years

#536
post #221

That's a good article. He's right about many things. I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust. Notes: * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be writ…

> I'd expected some AAA title to be written in Rust by now. I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until…

Comparing the time it takes for a prog language to spread from the 80s to today is a bad vantage point. Stuff took much longer to bake back then -- but even so the point is moot, as other commentors pointed out, it took off roughly the same amount of time between 2015 and today.

Re: Leaving Rust gamedev after 3 years

#537
post #501

I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#. It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year. Also for ECS... one thing I tended to realize is that when developing a game…

> 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. That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation…

Agreed. Truly exponential economy makes late-game Total Annihilation/Supreme Commander/Beyond All Reason far more fun than Starcraft.

Starcraft late-game is hoarding resources and running out your opponent's patience while looking for a slip up.

Re: Leaving Rust gamedev after 3 years

#538
post #314

Earlier quoted context omitted.

Disagree the adoption of C++ was more about Moore's law than ecosystem, although having compilers that were beginning to not be completely rubbish also helped.

Also C++ could be adopted incrementally by C developers. You could use it as “C with classes”, or just use operator overloading to make vector math more tolerable, or whatever subset that you happened to like. So there’s really three forces at play in making C++ the standard: 1) The Microsoft ecosystem. They literally stopped supporting C by not adopting the C99 standard in their compiler. If you wanted any modern co…

Theoretically accessible describes the experience of trying to use D3D from C very well!

Was trying to use it with some kind of gcc for windows. The C++ part was still lacking some required features, so it was advised to use D3D from C instead C++. There were some helper macros, but overall I was glad when Microsoft started to release their Express (and later Community) Editions of Visual Studio.

Re: Leaving Rust gamedev after 3 years

#539

Earlier quoted context omitted.

C# is that language (see Godot, Stride, FNA, Monogame).

Not really, it was adopted. It originated from Microsoft as their post-J++ Java alternative for CLR for the purposes of making it easier to write banking server software and Windows apps.

Does it matter what it was 20 years ago? It is the go-to language for gamedev today and only keeps getting better at it.

Re: Leaving Rust gamedev after 3 years

#540

Earlier quoted context omitted.

> I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either. Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone someth…

"code blowing up because of this issues" I ran into these issues all the time with Java, C++, and Python projects. But it's just not the experience of running Go in production, which I've been doing for over 10 years now, across many projects with many devs. In practice, nil checks are just not very difficult to include everywhere. And experienced Go programmers don't use exceptions (panic/recover) almost ever.

What you said is:

1) Anecdotal

2) Based on faith that someone will not forget to do something instead of a well documented mechanism in the language that could block that from the start

Having nil/null to handle empty references is simply very bad design and there's decades of examples why. The correct way is using a two-value type like Option, Maybe, etc. so that the (possibility) of the value missing is actually encoded in the type system

Post reply on HN