Earlier quoted context omitted.
Better cross platform, better build system, better packaging, simpler language, the list goes on.
> Better cross platform How many gaming consoles support rust?
Same number as how many support LLVM.
Why Rust Is the Future of Game Development
81–90 of 247 posts
Re: Why Rust Is the Future of Game Development
#82>Ownership based memory Is this not just ARC?
Fundamentally different. ARC involves reference counting, and so is a run-time strategy. Ownership in Rust is at compile-time, instead.
Now, it is true that languages that use ARC can do compile-time analysis to remove some refcount traffic, and that you can use run-time ownership tracking in Rust if you'd like.
The difference is what's built into the languages, what is the default vs what is not, and the kinds of patterns those tend to enable.
Re: Why Rust Is the Future of Game Development
#83Earlier quoted context omitted.
Better cross platform, better build system, better packaging, simpler language, the list goes on.
> Better cross platform How many gaming consoles support rust?
Rust code has successfully been compiled and ran on every one of the current generation of consoles, and many older consoles too.
Now, many studios would want it to be directly supported by the console developers themselves, and that's obviously not a thing right now... but there's no technical limitations here.
Re: Why Rust Is the Future of Game Development
#84For 95% of all game developer the future is a engine like Unreal or Unity and your scripting language of choice. The rest, triple A titles and engine developers may chose something else, but the inertia of C/C++ will make that a very long process.
The future - the next big game engine, being planned out or written right now, might be done in rust.
alot of critical parts of a game engine are already made in c or c++, and mono(the default stand for closs plataform for not engine user is not compatible whit rust)
Re: Why Rust Is the Future of Game Development
#85Let me tell you that the future of game development is in developing games, and any particular language has nothing to do with it. Does anyone care what language were any particular games that keep being replayed or remembered fondly? No. Never.
> Does anyone care what language were any particular games that keep being replayed or remembered fondly?
Roller Coaster Tycoon was in assembly.
Re: Why Rust Is the Future of Game Development
#86When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future. By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just…
GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.
Re: Why Rust Is the Future of Game Development
#87Earlier quoted context omitted.
It is the future of game development. I think that Rust makes it easier to build your own engine from public crates. In some sense blueprints are necessary because using CPP sucks. I can imagine that instead of Blueprints, Rust based engines will use some DSLs.
one te driver tend to be write in c or c++ make it mor reasonable to use the same langues, ogre3d for (c++), heaps( for haxe i love it compiled to c++), mono(for c#/ c++), raylib (c/c++), i dont know why you want spend at of time in make a engine that need some of this frameworks, whit weird interface to use rust
You won't be doing interop with these frameworks, if that's your point.
Re: Why Rust Is the Future of Game Development
#88Is it though? I feel like most people compare Rust to C++98 and if you do that, certainly Rust looks really good. The benefits of Rust compared to, say, C++17 are not as pronounced.
It's still quite easy to shoot oneself in the foot with modern C++: #include #include #include int main() { std::string_view v = std::string("xyz"); std::cout
OK i'll bite. What's wrong with this? It functions as expected or am I missing something.
Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance
Edit: Ignore me see below
Re: Why Rust Is the Future of Game Development
#89If you want to play a 3D, multiplayer, open source game written in Rust right now, check out Veloren: https://veloren.net/
Re: Why Rust Is the Future of Game Development
#90When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future. By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just…
GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.
>GC is a no-go, as it causes unacceptable frame-rate dips.
Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.