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

rg3d: Rust 3D game engine with an FPS demo game and scene editor

github.com

Post reply on HN
Print view View original

121–130 of 143 posts

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#121

Post by sprafa »

Aeolun wrote: post #120
marta_morena_25 wrote: post #98

Earlier quoted context omitted.

Not really... All great game engines were spawned out of AAA titles. You should never try to build an engine without a set of games that stretch its limits in all directions, otherwise something will always go wrong. There isn't a single person alive who can manage the complexity of a game engine. As soon as you start splitting things up, you run into problems of distributed development. Getting this right without ea…

Did Unity come out of a game?

https://techcrunch.com/2019/10/17/how-unity-built-the-worlds...

Seems like it. Still the tons of games that are and have been MADE with Unity over time have led it to become what it is now.

"Unity was founded in Copenhagen by Nicholas Francis, Joachim Ante, and David Helgason. Its story began on an OpenGL forum in May 2002, where Francis posted a call for collaborators on an open source shader-compiler (graphics tool) for the niche population of Mac-based game developers like himself. It was Ante, then a high school student in Berlin, who responded.

Ante complemented Francis’ focus on graphics and gameplay with an intuitive sense for back-end architecture. Because the game he was working on with another team wasn’t going anywhere, they collaborated on the shader part-time while each pursued their own game engine projects, but decided to combine forces upon meeting in-person. In a sprint to merge the codebases of their engines, they camped out in Helgason’s apartment for several days while he was out of town. The plan was to start a game studio grounded in robust tech infrastructure that could be licensed as well."

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#122

Post by bananaboy »

Aeolun wrote: post #120
marta_morena_25 wrote: post #98

Earlier quoted context omitted.

Not really... All great game engines were spawned out of AAA titles. You should never try to build an engine without a set of games that stretch its limits in all directions, otherwise something will always go wrong. There isn't a single person alive who can manage the complexity of a game engine. As soon as you start splitting things up, you run into problems of distributed development. Getting this right without ea…

Did Unity come out of a game?

Sort of - the original developers made a game which failed commercially and they decided to sell their tools instead. But the engine has changed a lot since those days, and Unity's lack of real dog fooding is a common complaint from people who use it professionally. Unity don't see the problems that only come up when you try to ship a real game in a team, on console or mobile in particular.

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#123

Post by adamnemecek »

badsectoracula wrote: post #118
adamnemecek wrote: post #90

Earlier quoted context omitted.

How would it not help? Someone might see this and realize that Rust is a viable game dev option and adopt it for their next game. In my experience, Rust is relatively fast on recompilation, possibly faster than C++. Rust is a much younger language so you have to wait.

Anyone who has enough knowledge to build a game engine like rg3d also has enough knowledge to be able to judge if Rust is capable of building an engine like rg3d even if they haven't built an engine in Rust themselves. If after reading abour Rust a programmer cannot figure out if Rust can be used to make a game engine then that programmer is incapable of making a game engine in the first place so in the grand scheme…

OK they do, so what.

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#124

Post by smusamashah »

mrDIMAS wrote: post #47
meheleventyone wrote: post #31

Wow, this is a lovely, pragmatic, no nonsense game engine! And it has a non-trivial example project and an editor! This is such a breath of fresh air for game engine announcements. I don't know if mrDIMAS is on HN but big congrats to him for this great project.

Thanks a lot for the kind words!

Is there 2d drawing support, line drawing and other 2d shapes, bezeir curves?

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#126

Post by shaklee3 »

echelon wrote: post #53
Thaxll wrote: post #30

Earlier quoted context omitted.

I don't see why Rust would be cleaner than modern C++ codebase.

C++ is incredibly verbose (STL) and carries a lot of baggage and mental overhead. Rust has improved ergonomics in nearly every area except lifetime handling, which is a concern you want to think about and make explicit. I predict in ten years the gravitas for new projects will have shifted entirely to Rust. C++ is just too much of a burden to write and verify. C++ will still have plenty of healthy projects, but I thi…

They have about the same amount of verboseness in my experience.

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#127

Post by eggy »

keldaris wrote: post #83
swalsh wrote: post #3

What I love about this engine, is that I can really easily read the code and reason what it does. I'd guess that given an hour or so of study I would feel reasonably confident in trying to modify it.

The same is also true of the author's previous engine [1], written in C99. Would love to get the author's take on the costs and benefits of switching to Rust on the basis of what's effectively a reasonably sized real world case study, at least as far as individual projects go. [1] https://github.com/mrDIMAS/DmitrysEngine

Thanks for the link! I am going to look more into rg3d, but the C99 engine is interesting to me, because I use Raylib[0] for my C gamedev explorations. I will never fully leave C, because I will be dead before C is fully, or largely, displaced by the likes of Rust or another PL. I have also been playing with Zig, and there is a Tetris demo done by Andrew Kelley the creator of Zig, but no game engine I know of yet [1,2].

[0] https://www.raylib.com/

[1] https://ziglang.org/

[2] https://github.com/andrewrk/tetris/blob/master/build.zig

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#128

Post by [deleted] »

kettlecorn wrote: post #45
brundolf wrote: post #40

Earlier quoted context omitted.

The graphics code would have to be ported to WebGL, and then there might be an extra hurdle getting WASM to talk to WebGL directly. But it's doable, yes.

Rust with WebGL is pretty seamless today. I wrote a game for a gamejam using Rust, Wasm, and WebGL without any engine: https://kettlecorn.itch.io/wonder It makes use of ‘glow’, a Rust library that lets you write regular OpenGL code that runs across desktop, mobile, and web: https://github.com/grovesNL/glow

[deleted]

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#129

Post by Rusky »

pjmlp wrote: post #99
Rusky wrote: post #80

Earlier quoted context omitted.

Ranges don't really exist yet.

Then I wonder how I am using them.

Probably by using a third-party library, with a pre-concepts-based implementation which is heavy on compile times. Unlike Rust, where they're built in and don't really have that cost.

The context here is comparison between Rust and C++, for a side project begun over a year ago. Citing pre-standard C++ features with partial/experimental third party implementations doesn't really make the difference you seem to think, in that context.

Re: rg3d: Rust 3D game engine with an FPS demo game and scene editor

#130

Post by Jweb_Guru »

pjmlp wrote: post #107
Jweb_Guru wrote: post #104

Earlier quoted context omitted.

I am well aware of your opinions on this matter. None of what you just said has anything to do with Frama-C. You can't throw that out there as a Rust alternative (which, as I noted, it is not, or at least not a complete one) and then compare how easy "vanilla C++" is compared to Rust (like I said, I disagree with you on that, but it's not even relevant here). The truth is that for people who care about safety (as I k…

Almost fully agree, just the ergonomics are fully there and while static analysis tools aren't fully there, nor ever will, as you well point out, the likes of Google and Microsoft seem quite minded to bring Rust into C++, despite their ongoing adoption of Rust. As the latest posts from Visual C++ seem to imply, https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... https://cppcon2020.sched.com/event/e7C0/int…

Microsoft, sure--nobody has worked harder than they have to try to make C++ safer. And there are other big companies seriously investing in making C++ safer (e.g. Facebook, bad as they are otherwise).

But I've also talked to many of the researchers actually working on these projects--they'll freely tell you how hard the task is and how impossible it is to really apply Rust's straightforward solutions to the massive existing legacy of C++ code. And let's be honest--if your tool requires people to rewrite everything anyway, they might as well choose Rust, so it's not acceptable for your tool to only work on modern stuff, or require annotations everywhere you use std::string_view, etc.

And I should be very clear that this is quite specific to C and C++. Ada, for example, has been able to adopt solutions from Rust with ease, and even add some interesting improvements, because the safe subset of their language was conservative and the borrow checker allows them to extend it. So I'm not saying other languages cannot copy Rust, it's very much specific to unsafe by design languages like C++.

They're trying to make their existing codebases safer, and I think that's great, but unless there's a massive breakthrough in the next few years these aren't going to be general purpose solutions and they are definitely not going to be close to sound. For example, pretty much everything I'm aware of for C++ that tries to do memory safety, punts on thread safety, because it's just virtually impossible with all the other stuff going on; many of them punt on recursive function calls, and a bunch don't even do anything but very basic interprocedural analysis, focusing all their energy on "local" intraprocedural bugs that are much easier to catch. The tools would just be too noisy to be useful otherwise.

As for Google... they resisted investing in static analysis tools for years and I don't take them seriously at all when they talk about this sort of thing.

Post reply on HN