Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

Post reply on HN
Print view View original

431–440 of 996 posts

Re: Leaving Rust gamedev after 3 years

#431

Post by zamalek »

littlestymaar wrote: post #282
zamalek wrote: post #269

Earlier quoted context omitted.

Absolutely. Async/await typically improves headroom (scalability) at the cost of latency and throughput. It may also make code easier to reason about.

> at the cost of latency and throughput. Compared to what? Doing epoll manually?

A reactor has to move the pending task to some type of work queue. The task has to pulled off the work queue. The work queue is oblivious as to the priority of your tasks. Tasks aren't as expensive as context switching, but they aren't free either: e.g. likely to ruin CPU caches. Less code is fewer instructions is less time.

If you care enough, you generally should be able to outdo the reactor and state machines. Whether you should care enough is debatable.

Re: Leaving Rust gamedev after 3 years

#432

Post by TillE »

meheleventyone wrote: post #360
pcwalton wrote: post #354

Earlier quoted context omitted.

There are a few successful games like Tunnet [1] written in Bevy. [1]: https://store.steampowered.com/app/2286390/Tunnet/

Looks cool and well received but at ~300ish reviews hardly a shining beacon if we extrapolate sales from that. But I'll say that's a good start.

Speaking as a Godot supporter, I don't think sales numbers of shipped games are relevant to anyone except the game's developer.

When evaluating a newer technology, the key question is: are there any major non-obvious roadblocks? A finished game (with presumably decent performance) tells you that if there are problems, they're solvable. That's the data.

Re: Leaving Rust gamedev after 3 years

#433

Post by taeric »

alkonaut wrote: post #401
taeric wrote: post #382

Earlier quoted context omitted.

I think the point is that there are few "code related" dead ends in game code with good game play that can't be dealt with using enough effort. There are plenty of "game play related" dead ends that no amount of clean code can help out. To that end, whatever can help you explore the game play the fastest is what you want.

Quick iteration perhaps isn't the biggest strength of C++ either. Rust does have some friction when it comes to "I'll try this with a dirty impl and if it flies, then I cam make a clean one later". I guess if that friction is worth it will depend on how much faster you get on other things, e.g. refactoring without spending a lot of effort worrying about introducing hard-to-spot bugs like races, or - worse - having to…

This is fair. Always curious to see why so much effort is used to move a game's codebase into a single language codebase. Seems far more useful to move the core of a game's engine to an interpreter loop and build on top of that, with all of the affordances one usually gets from that.

Re: Leaving Rust gamedev after 3 years

#434

Post by celdon25 »

hi-v-rocknroll wrote: post #386
celdon25 wrote: post #301

Earlier quoted context omitted.

Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.

Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case. * So fast, they really don't need HCR.

I haven't tried it yet but I've wondered if Elixir might be a good choice for a game server with many concurrent players.

Re: Leaving Rust gamedev after 3 years

#435

Post by renox »

WalterBright wrote: post #43

> Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that I found this to be true of C after many, many years coding in C. I noticed that the first selection of data layout stayed throughout the life of the code (with a lot of tweaks, additions, etc.). But didn't really think that much about it. Until I started writing code in D. It was easy to change the data…

In the same idea in Eiffel in a.b, b can be either a member or a function to allow easy replacement.

On the opposite other languages want to have no hidden function call, no hidden pointer dereferencing..

Re: Leaving Rust gamedev after 3 years

#436

Post by dj_mc_merlin »

chris37879 wrote: post #385
internetter wrote: post #359

Earlier quoted context omitted.

That's a thing?

Absolutely! Any sort of multiplayer game needs a source of authority if you want to prevent cheats like a hacked client lying about its position, and a really good way to do that is load the geometry of your level and run physics checks server side at a lower frequency than once per frame. Godot and Unity both support headless builds for exactly this reason, it's basically the whole game engine, minus the renderer, a…

That is not server side rendering. Per your own comment:

> minus the renderer

(Otherwise you are completely correct.)

Closest I can think of is server side ragdolls that are rendered the same on all screens and similar stuff.

Re: Leaving Rust gamedev after 3 years

#437

Post by andersa »

Animats wrote: post #137

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. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.

The main reason is that you can't ship that Rust code on PS5 in a sensible manner. People have tried, got useless toys to compile, but in the end even Embark gave up. I remember seeing something from them that they had moved Rust to server-only.

Re: Leaving Rust gamedev after 3 years

#439

Post by otterley »

jvanderbot wrote: post #422
astrange wrote: post #388

Earlier quoted context omitted.

Async/await isn't related to threading (although many users and implementations confuse them); it's a way of transforming a function into a suspendable state machine.

I know. But threading, and earlier processes, were less scalable but potentially faster ways of handling concurrent requests.

It's also much easier to reason about, since scheduling is no longer your problem and you can just write sequential code.

Re: Leaving Rust gamedev after 3 years

#440

Post by BaculumMeumEst »

astrange wrote: post #395
Xeamek wrote: post #262

Earlier quoted context omitted.

He is actively developing his new game in parallel to creating the language. Not to mention smaller projects like 'Braid- anniversary edition'.

Isn't the traditional advice that if you try to write both a game engine and a game that you'll get neither?

Then it's a good thing not everyone listens to traditional advice.
Post reply on HN