Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

931–940 of 996 posts

Re: Leaving Rust gamedev after 3 years

#931

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

The problem is we would have a lot less games and the games we would get would not be as fun. Rust appears to have the following problems: 1) As the article pointed out, game developers are less productive in Rust. This is a huge problem. 2) Game budgets are not going to get bigger. This means that if Rust reduces productivity, games are going to be less polished, less fun, etc. if they are written in Rust. 3) Game q…

Uhh, no, the games we got 15 years ago and before were definitely just as fun.

Re: Leaving Rust gamedev after 3 years

#932

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

Hell no. Lots of these games take 5-7 years to make. You want to turn that into 10-14? I can live with the rare crash bugs.

IDK, seems to me like studios did just fine putting release-quality games out at release 15-20 years ago shrug

"rare" LOL

Re: Leaving Rust gamedev after 3 years

#933

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

It's a chicken-egg problem. You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). YMMV depending on the complexity of the game of course. But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in…

> You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all).

Just because they like to say that doesn't mean it's true. I've had access to see the list of known issues considered "critical" around release time for a few games. They know the bug exists, they just want to release it more than they want to fix it.

> But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users.

Which in no way invalidates the point that most modern games are absolutely unplayable for most users at release.

Oh yeah, and also that's why beta testing exists

Re: Leaving Rust gamedev after 3 years

#934

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

No, the game doesn’t take twice as long. It just gets abandoned half-finished. The world is full of half-finished games, it takes time and money to push to a finish.

Ah right that's why no games existed two decades ago.

Re: Leaving Rust gamedev after 3 years

#935

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

perfect is the enemy of good. You never release anything thats perfect. Perfect is impossible.

> "perfect"

> perfect

See the difference?

Re: Leaving Rust gamedev after 3 years

#936

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

> I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long I have recently completed Cyberpunk Phantom Liberty. The game crashed 4-5 times during 100-150 hours of gameplay. The crashes were pretty much painless because I quick save often. The game was amazing. The development of the game started in 2012, 12 years ago. I’m not sure you or most gamers would rather w…

> 4-5 times during 100-150 hours of gameplay

Great, thanks for proving my point! If you had played CP at release, how many times would it have crashed?

Do you really think it would have taken them another 12 years to get to the point they're at now if they hadn't released it 4 years ago? SMH

Re: Leaving Rust gamedev after 3 years

#937

Earlier quoted context omitted.

"I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it." 100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on…

It does in my domain of systems programming with async data handling. Tokio works like a dream - slipping into the background and just working so I can concentrate on the business logic.

I know this is a late reply to your post, but your wording prompted a question. I will preface by saying this is not some sort of semantic flamebait, it is also not supposed to be a gatekeeping exercise. You state your domain is systems programming, but then talk about the event loop and scheduler for your program as ancillary details and say that your concentration is on business logic. I tend to view systems programming as development of things that have no business logic, because that is the domain of application programming. Also, I tend to think that a defining feature of systems programming is development that can not just accept a default solution to something as impactful as an event loop/scheduler/executer, but have to focus deeply on those aspects of a program that are the crux of its actual computational operation and interactions between those parts.

In the context of games, the systems programming is the renderer, audio engine, physics calculations, and things like a task system and dispatcher/scheduler, etc. As compared to the actual application specifics of levels, art, dialogue, interactions, UI, etc which to me are not systems programming.

With that said, how do you define systems programming? I’m really interested in how various devs tend to view the ‘cut-off’ between systems and application development. Sometimes I’m pretty sure I am on the extreme end of disjointness of the two and non-accepting of any ‘business logic’ type development qualifying as systems programming.

TL;DR - What is your definition of systems programming and do you include things like ‘business logic’ within that definition?

Re: Leaving Rust gamedev after 3 years

#938
post #824

Earlier quoted context omitted.

Microsoft is rewriting quite a bit of their C# to Rust for performance reasons. Especially within their business line products. Rust have also become rather massive in the underlying tech in the telecommunications infra structure in several countries. So I’m not sure that your take is really so on point. Especially as far as comparing it with Go goes (heehee), at least not in terms of 3rd party libraries where most o…

Microsoft rewrote one, maybe two microservices as it was driven by a lead interested in using Rust and is rewriting parts of NT kernel (way more important).

It’s much more than that, even now they are continuously opening job postings with a focus on re-writing the 365 platform from C# to Rust.

Re: Leaving Rust gamedev after 3 years

#939
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…

We wrote this in C++ (and assembler), but used only the most obvious language features. We laid down the first code in '95 or '96:

https://www.youtube.com/watch?v=9UOYps_3eM0

Re: Leaving Rust gamedev after 3 years

#940
post #938

Earlier quoted context omitted.

Microsoft rewrote one, maybe two microservices as it was driven by a lead interested in using Rust and is rewriting parts of NT kernel (way more important).

It’s much more than that, even now they are continuously opening job postings with a focus on re-writing the 365 platform from C# to Rust.

It’s a bad habit to read too much into a single job posting.

(oh, I remember now, it’s the account traumatized by odata)

Post reply on HN