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

Bevy: A data-driven game engine and app framework built in Rust

bevyengine.org

Post reply on HN
Print view View original

61–70 of 108 posts

Re: Bevy: A data-driven game engine and app framework built in Rust

#61

Post by pjmlp »

aspaceman wrote: post #46
throw_m239339 wrote: post #29

Purely a question. So why would I use rust instead of C++ or C# to develop games? what are the potential advantages of that.

For some, theoretically it's easier to train new Rust developers than it is to fix the bugs of new C/C++ programmers. Folks are trying to move the cost to training and dev bringup time instead of bug-fixing time. Rust has other more technical advantages. But if you want to know why management is choosing it, it's because getting good C/C++ developers is a painful process nowadays.

Getting good developers is painful process no matter what, usually those are the ones that don't answer headhunters, search for their own gigs via their own contact network, and don't get to change jobs just for a couple of more coins.

Re: Bevy: A data-driven game engine and app framework built in Rust

#63

Post by ashtonkem »

adamnemecek wrote: post #55
PrototypeNM1 wrote: post #45

Earlier quoted context omitted.

> * It has an easy-to-use package manager, and I'm not sure where C++ is on that front. In the inescapable hell of n+1 competing standards.

You mean that every langauge has its own package manager?

I think they mean that C++ isn’t one thing, it varies a lot by the specific compiler and version you’re using.

Re: Bevy: A data-driven game engine and app framework built in Rust

#64

Post by meheleventyone »

adamnemecek wrote: post #41
meheleventyone wrote: post #34

Earlier quoted context omitted.

There’s not a particularly thrilling benchmark here: https://bevyengine.org/news/introducing-bevy/ Basically an ECS is not really a secret easy pattern to cache coherent data access. This benchmark shows its fast for the easy cases but says nothing about typical game requirements.

ECS has been used relatively heavily in game dev since like late 90's.

So? That has nothing to do with the performance of an implementation which is what I commented on. Data oriented design is about managing data organisation to match access patterns in order to best exploit the hardware cache. That requires more design than simply using the ECS pattern. Which is why a lot of generic engines introduce other concepts like Grouping and Archetypes to try to alleviate this. And even if you do use a generic ECS engine with performance sensitive features it’s still perfectly feasible to end up thrashing.

Also as a claim I also find this highly doubtful particularly as I’ve been working as a game developer for many years and not really seen it used on a single project in that time. There’s a reason why there are dozens of hobby implementations but no full scale games written using them.

Re: Bevy: A data-driven game engine and app framework built in Rust

#65

Post by sourceless »

This might be the killer app that finally gets me to use Rust. I've tried so many engine libs/frameworks in so many languages now, and none of them look nearly as complete and ergonomic as this.

I don't really want to have to write my own 3d renderer or ECS because the engine's one is bad or nonexistent... this really scratches an itch for me.

Clojure take note...

Re: Bevy: A data-driven game engine and app framework built in Rust

#66

Post by ShinTakuya »

adamnemecek wrote: post #55
PrototypeNM1 wrote: post #45

Earlier quoted context omitted.

> * It has an easy-to-use package manager, and I'm not sure where C++ is on that front. In the inescapable hell of n+1 competing standards.

You mean that every langauge has its own package manager?

I think they mean that people keep coming along and saying "the existing N competing standards suck, let's make a new one everyone can use" and now there's N+1 competing standards.

A reference to this xkcd https://xkcd.com/927/

Re: Bevy: A data-driven game engine and app framework built in Rust

#67

Post by ShinTakuya »

ShinTakuya wrote: post #66
adamnemecek wrote: post #55

Earlier quoted context omitted.

You mean that every langauge has its own package manager?

I think they mean that people keep coming along and saying "the existing N competing standards suck, let's make a new one everyone can use" and now there's N+1 competing standards. A reference to this xkcd https://xkcd.com/927/

To clarify, for C++ specifically.

Re: Bevy: A data-driven game engine and app framework built in Rust

#68

Post by prox »

sourceless wrote: post #65

This might be the killer app that finally gets me to use Rust. I've tried so many engine libs/frameworks in so many languages now, and none of them look nearly as complete and ergonomic as this. I don't really want to have to write my own 3d renderer or ECS because the engine's one is bad or nonexistent... this really scratches an itch for me. Clojure take note...

Not only that, but the way it is written draws you in. It tells you its scope, function and methodology right from the start. I kept reading but I know little of Rust.

Re: Bevy: A data-driven game engine and app framework built in Rust

#69

Post by 6d65 »

It's funny, I've been doing something similar in Rust. A GUI framework that renders to Vulkan, and at the bottom is an ECS system(multiple systems) for rendering, layout, animation. But this one is very far ahead and looks very polished.

Congrats to the author on great work.

Re: Bevy: A data-driven game engine and app framework built in Rust

#70

Post by meheleventyone »

Thaxll wrote: post #54
vvanders wrote: post #48

Earlier quoted context omitted.

On a console every 1mb of binary is one less mb for assets. We ran LTCG on every game I shipped.

When your game is 125GB it does not really matters if your dll is 20MB instead of 30, it was the case 15 years ago now it's a much different story.

It does a bit when you have 8GB of shared memory between the graphics card, OS and your game. Download size isn't the only memory constraint affected by binary size.
Post reply on HN