Yeah, in general with large and Powerful libraries or frameworks, I find that pure API documentation, even if very thorough and well explained on an individual function or data structure level, is just simply not enough. I also want a reference manual type experience, where that API reference is integrated with explanations of the reasoning behind how the framework was designed, and how to actually think about using it, and examples of many common things you might want to do that integrate well together. The gold standard for this in my opinion is the opengl Red Book.
This, and the fact that correctness and safety and stability aren't quite as important in game development, or even game engine development, as they are in other fields where rust is applicable, is why I purposefully happily use the powerful, futureful, well established, copiously documented C or C++ libraries I need, instead of tge Rust alternatives, for almost everything. It works extremely well for me because I get to leverage the power and amazing ecosystem around things like dear imgui or sdl2 or opengl or physx, while being able to use rust, which grants me essentially a cleaner, even more modern version of C++ with all of the features I love from ocaml, in a way that restricts any weird crash or memory safety errors to the places where I interface with the lower level libraries, and sometimes not even there, depending on how high level the bindings are. It's honestly pretty nice for me.
I don't think that's the case. N=1, but I'm usually a quite staunch, and occasionally incendiary, proponent of Rust, because the arguments against it / criticisms of it I usually see seem fundamentally misguided or even disingenuous to me — whereas in this thread, I've been only agreeing, because the criticisms are fair (I agree Rust isn't built for, and is quite bad at, prototyping, fast iteration, flexible code, etc), if I think a bit overblown (I think many of the patterns the author complains about being forced to use like command lists and generational arenas are very good). That could be the difference you're seeing, IMO.
Why would it? Haskell's a super nimble language in my experience. If you commit to high-level constructs it's like a Ruby but with a compiler that catches so many errors and enables type-safe metaprogramming.
And it has an amazing bytecode interpreter that you could use in dev for super fast iteration + hot reloading.
I do that now in my Haskell engine :) but I'm only starting to build all the bog standard gamedev engine stuff. Would be nice to build on an engine that just provides good infra without caring about logic.
I agree with OpenGL being retro — that's why I'm using it too ;)
It's the only stable, copiously documented, low level (so less assumptions, not a game engine or even library) graphics API that's still usable by humans and relatively ergonomic. It dying out would be a tragedy — I've really loved learning OpenGL 4.6 tbh. Hopefully Zink keeps it available into the future!
People will complain no matter what title you choose—but I think the page's <title> element, "Fyrox - A feature-rich game engine built in Rust", is pretty good
> The dominant conclusion of that other threat, at least as far as I've seen, is one that I concur with — namely, that Rust is absolutely not good for writing game logic, but is probably quite good for writing game engines, and this engine seems like a step towards making that distinction, since it doesn't work like a framework, where you write your game logic in Rust and compile it with the game engine into a single static binary, you instead have the game engine be a separate executable that you then load your game logic as plugins into. The plugins are still currently written in rust, but I'm sure you can see how that could change.
But to each your own! I'd certainly recommend Godot or Unreal over any Rust engine every day of the week as well, just like I use SDL2, OpenGL, and imGUI over pure Rust solutions even in my own Rust game engine work.
The dominant conclusion of that other thread, at least as far as I've seen, is one that I concur with — namely, that Rust is absolutely not good for writing game logic, but is probably quite good for writing game engines, and this engine seems like a step towards making that distinction, since it doesn't work like a framework, where you write your game logic in Rust and compile it with the game engine into a single static binary, you instead have the game engine be a separate executable that you then load your game logic as plugins into. The plugins are still currently written in rust, but I'm sure you can see how that could change.
The vast majority of the reactions from Rust devs to that article - from core language people to random devs like myself - is general agreement. It's understandable why the overzealous-Rust-dev stereotype exists, but I would feel comfortable saying it's really not on display for this saga.
The article was incredibly well written and composed, and if you[0] haven't read it, I highly encourage doing so. I really hope it helps push for improvements at all ends of the spectrum.
I'm the original poster, and yeah, I read the recent much bigger post about rust game development, and it linked to this engine, so I followed the link and checked this engine out, and it seemed really cool and like at least partially and actually relevant solution to the problems being discussed in the other thread, as well as criminally underrated in comparison to the hype around bevy, or even amethyst, so I decided to post it. I would have done so even if I wasn't getting any points from it! :D
> I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.
That's why, the first time I saw Bevy and Amathyst, I had an immediate "they're doing it wront$ reaction. IMHO, to be a true game engine in the modern sense, instead of merely a game framework, your engine needs to be a precompiled, standalone executable in a systems language that picks up, loads, and executes game scripts, data files, and assets that are totally separate from the engine itself and written in higher level languages. You don't want to be writing everything in a rigid systems language and especially don't want to have to compile your game logic and your engine together and then link them as if the engine were a library. That's why I'm (very slowly) feeling out what a proper game engine in Rust might be like with https://github.com/alexispurslane/embryo-engine. It will take me some time, since I have to learn real time computer graphics and a lot about game engines, but I've got the books, I've made a lot of progress in learning them, and the engine design and architecture is coming together very well in my big black notebook, so if you're interested, give the repo a watch ;)
I'm debating between embeddable common lisp (to satisfy my hacker impulses) or C# for the scripting language. I have figured out, I think, how I'll embed C# in Rust down to some pretty detailed steps, involving a two stage process, but .NET is so heavy I'm worried if it'll be worth it. I'd love input!
