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

451–460 of 996 posts

Re: Leaving Rust gamedev after 3 years

#451

Post by Aerroon »

LarsDu88 wrote: post #79

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…

>but few games will actually leverage this effectively for fun gameplay

In my opinion this is a result of big mobs having poor performance. When players get to choose they seem to like having more mobs thrown at them.

This can also be limiting for interactable objects.

Re: Leaving Rust gamedev after 3 years

#452

Post by georgeecollins »

djmips wrote: post #234
danbolt wrote: post #108

Earlier quoted context omitted.

When all you have is a hammer, everything looks like a nail. When all you have is programming expertise, all your game production obstacles look like programming problems. I think everyone in games has met an “engine person” who spends a lot of time iterating on tech, but never quite getting to the creative expression that got them in the game. I think part of it comes a bit from mythologizing breakthrough games like…

Well said, I am weary of all the 'game' programmers that just fetishize working on the tech and particularly rendering.

People like to program on tasks that aren't given to them, to practice their craft in a less restricted form than professional life usually allows. So they make things for themselves and its natural that those things are what they are familiar with and enjoy. So you often meet the programmer, almost never from the game industry, who wants to make his or her own game engine. It's about as likely to be a productive endeavor as making your own spreadsheet program.

Re: Leaving Rust gamedev after 3 years

#453

Post by kagakuninja »

hot_gril wrote: post #420
jacobgorm wrote: post #414

Earlier quoted context omitted.

C++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.

Yeah, OOP makes sense for games. The language will matter a bit for which one takes off, but anything will work given enough support. Like, Python doesn't inherently make a lot of sense for data processing or AI, but it's good enough.

OOP kind of goes out the window when people start using entity component systems. Of course, like the author, I'm not sure I'll need ECS since I'm not building a AAA game.

Re: Leaving Rust gamedev after 3 years

#454

Post by eftychis »

I respectfully disagree with the author's title choice.

My first impression is, of course, that the issue is there is no production Game or GUI framework around.

The author seems to complain mainly about the choices of frameworks and how bad or opinionated they are. I agree. Even Egui is too opinionated, but it makes sense on some level.

It is no problem to use bindings to some software written in C++. Rust was created to solve this exact problem: rewrite big projects that were written in C++, by slow mutation in Rust.

Honestly, I would add further that until the Unreal Engine uses Rust, we should not expect widespread Rust adoption. It will likely start with a company creating its own really custom game engine, the game becoming a bestseller, and it will spread iteratively over the years from there. Or maybe there will be a better option beyond Rust at that point.

This is the status quo: https://www.youtube.com/shorts/_zwKHgtQpc8 Let us be realistic.

Beyond that: One should see Rust as writing C with someone watching over you to remind you that you need to know the writer for each memory value. It picks up work off you. Or it should. If it doesn't, yes that is a problem, and we/you are doing it wrong.

But yes, if you are doing something that the borrow checker complains about, in other languages, either that semantic difference would have been hidden, or you would be paying for it later.

There, the author makes a point that he wants the code to work now. That is possible, and you can hotwire bad code in Rust, too. But I am sure that code is why we end up with games like Jedi Survivor.

There is no fundamental inability of Rust to do the things the author demands. If you want dynamic loading, use https://crates.io/crates/libloading (And you don't need to use the library). Do you want a global state? I will disagree with you, but take a look at, e.g., how the Dioxus project is doing it. Again I think that is always a terrible mistake, and people are thinking really of using an arena or a registry really.

Re: Leaving Rust gamedev after 3 years

#455

Post by fooker »

Wazako wrote: post #408
fooker wrote: post #173

Earlier quoted context omitted.

Perhaps the more appropriate advice is : Use the right tool for the job. Use C++ for writing a high performance library or a database engine. Use Go or Java for writing a server. Use C for writing a kernel module. Use shell scripts for automation. Use python for trying out ML ideas or heavier duty scripts. Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right…

Use Rust if crashes or memory bugs are not an option. For everything wasm, Rust is much more pleasant with good libraries than the competition.

Wasm seems more convincing to me than the magical 'no crashes or bugs' promise.

Here's my wasm use case: tell me how I can use Rust.

I have a command line tool written in C that ..say.. takes strings and outputs strings.

How would I go about making a usable REPL out of this in Rust and wasm without rewriting the tool?

Re: Leaving Rust gamedev after 3 years

#456

Post by Ygg2 »

TheRoque wrote: post #441
pcwalton wrote: post #279

Earlier quoted context omitted.

Exactly. Bevy has the advantage of being built using the "right way" from the start. This makes an enormous difference in the ease of hacking on rendering code. Ironically, the main thing holding Bevy back is the bickering at the W3C. WebGPU is still not widely supported, so we have to support WebGL 2 (with reduced functionality in some cases), and that adds a lot of complexity.

> Bevy has the advantage of being built using the "right way" from the start I think the article is precisely criticizing this type of comment... You make people believe that Bevy is some kind of safe bet for the future, that it took inspiration from the greatest to build even better foundations for a game engine... And it seems common in the Rust community: make audacious unverifiable claims to enroll other "believe…

Well, there are two types of game engines from what I've seen:

- One where most things are done out of the box, and you can mostly GUI visual code to success - these are your Unreals, your Unitys and Godots.

- Second, where most things need to be built piecemeal, and many things are missing, and need to be built - Bevy falls into this category, along with stuff like PyGame and what not.

I mean, Bevy is a fine engine for small things, but I can't admit I've seen any indie game of more renown succeed with it. OTOH, doesn't mean you can't make it, but it's definitely more effort.

Re: Leaving Rust gamedev after 3 years

#458

Post by TheRoque »

Ygg2 wrote: post #456
TheRoque wrote: post #441

Earlier quoted context omitted.

> Bevy has the advantage of being built using the "right way" from the start I think the article is precisely criticizing this type of comment... You make people believe that Bevy is some kind of safe bet for the future, that it took inspiration from the greatest to build even better foundations for a game engine... And it seems common in the Rust community: make audacious unverifiable claims to enroll other "believe…

Well, there are two types of game engines from what I've seen: - One where most things are done out of the box, and you can mostly GUI visual code to success - these are your Unreals, your Unitys and Godots. - Second, where most things need to be built piecemeal, and many things are missing, and need to be built - Bevy falls into this category, along with stuff like PyGame and what not. I mean, Bevy is a fine engine…

Well, I don't call the second ones "game engines", I call them game libraries, or game frameworks. RayLib also is a nice one. But they don't claim to be "engines" (or at least, they are mostly described with the aforementioned terms)

Re: Leaving Rust gamedev after 3 years

#459

Post by 0x457 »

astrange wrote: post #393
meinersbur wrote: post #338

Earlier quoted context omitted.

My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.

Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually. https://en.wikipedia.org/wiki/Crash-only_software https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...

A crash of an actor in BEAM is incomparable to a crash of a video game.

Re: Leaving Rust gamedev after 3 years

#460

Post by jpardy »

alcover wrote: post #369
bdw5204 wrote: post #24

My impression of Rust is that it's a very opinionated language that wants everybody to program in a specific way that emphasizes memory safety above everything. That's a good idea, I think, for the systems programming use cases that it was intended for. I don't see that as a particularly useful thing to value for game development. The part in the article about the Rust borrow checker constantly forcing refactors soun…

> I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection. I agree so much that I've been working on this for a whole year. There is a sweet spot : non-GC, with pointers (but bounded), i…

For me, this is Odin-Lang, it doesn't meet all the requirements you have listed, but it's ergonomic, fast, and comes with extensive core and vendor libraries. It's all just fun and reasonable.

https://odin-lang.org/

Post reply on HN