We invite you to read an article on how C++ is used in modern game development and why the industry is still not ready to move away from it. The author explores how C++ works at different levels of...
Rust is a poor language for Game dev. Games and a borrow checker don’t work together. You will end up using unsafe mode most of the time.
Making a game revolves around doing the hackiest shit and making something cool work. Every function has side effects and variables will need to be modified in multiple places in the same frame.
Don’t get me wrong I like Rust but I need a language I can abuse, not the other way around, when I am making a game.
Rust is a fantastic language for game dev. It just requires you to think completely differently if you want to have a good time. You can totally write the traditional game loop or my preference ECS (bevy as one example). ECS still let’s you do the crazy mutations without having to worry about ownership. Each system can focus on the components they care about and you can specify the order they run. If you want to be reckless and mutate global state, then you need to explicitly decide between things like RwLock<T> and RefCell<T> for example. I’m not saying everyone should drop whatever they prefer to instead use rust. It’s ok to stick with what you know or enjoy. Good games are agnostic to the tools used to make them. I just don’t think Rust deserves to be dismissed the way your statement does.
Every function has side effects and variables will need to be modified in multiple places in the same frame
We try to avoid exactly that, because it is what caused us man-years of bug-hunting and bug-fixing over our past projects. Our end-goal (that is still very far away…) would be to have the state from the previous frame and the user inputs, do only pure computations based on this data, and write out a new state before rendering the current frame.
We do use C++ though (because Unreal, and console platforms), what makes this extra hard, because C++ is a language for writing bugs, not for writing software.
And you added analytics, achievements, and auto-save to these projects? That ideal falls apart really fast after adding one of those features. Const functions still exist but this crap will infect your Blueprints.
As said, we try to. Not that we managed to reach this ideal in any existing project yet. We did manage to get Auto-Save implemented without affecting the “purity” of computations, but as you said, achievements and analytics are a PITA. I think those are possible with pure computations too, but we did not yet manage to build the game architecture in a way that makes that work. Yet.
I’m currently on a research project to investigate how much of a game we can move into pure Embedded Domain Specific Languages. So, basically a set of gameplay scripting languages that enforce the “everything that happens during the frame is pure” constraint. Buuut, again, this project is still at its early stages, and under very strict budget constraints, so I cannot say yet if the outcome will be a feasible architecture or not…
That is super cool that you got auto-save and auto-load to work with pure functions. It is technically an IO operation but with data structures and enums you can guarantee the same functionality as something stored in the heap.
The actual writing of course isn’t pure. Loading isn’t either, but we only support loading on level transition, so we can supply the data already when constructing the game state. Saving is done by gathering all the data that should be saved in a struct, what is pure and happens at a well defined point in the frame, where the game state is known to be consistent (-> I think it’s after all systems have been updated), and then this struct is written out to a file.
I would still prefer Rust over C++ even in GamrDev.
Rust is a poor language for Game dev. Games and a borrow checker don’t work together. You will end up using unsafe mode most of the time. Making a game revolves around doing the hackiest shit and making something cool work. Every function has side effects and variables will need to be modified in multiple places in the same frame. Don’t get me wrong I like Rust but I need a language I can abuse, not the other way around, when I am making a game.
Rust is a fantastic language for game dev. It just requires you to think completely differently if you want to have a good time. You can totally write the traditional game loop or my preference ECS (bevy as one example). ECS still let’s you do the crazy mutations without having to worry about ownership. Each system can focus on the components they care about and you can specify the order they run. If you want to be reckless and mutate global state, then you need to explicitly decide between things like
RwLock<T>andRefCell<T>for example. I’m not saying everyone should drop whatever they prefer to instead use rust. It’s ok to stick with what you know or enjoy. Good games are agnostic to the tools used to make them. I just don’t think Rust deserves to be dismissed the way your statement does.We try to avoid exactly that, because it is what caused us man-years of bug-hunting and bug-fixing over our past projects. Our end-goal (that is still very far away…) would be to have the state from the previous frame and the user inputs, do only pure computations based on this data, and write out a new state before rendering the current frame.
We do use C++ though (because Unreal, and console platforms), what makes this extra hard, because C++ is a language for writing bugs, not for writing software.
And you added analytics, achievements, and auto-save to these projects? That ideal falls apart really fast after adding one of those features. Const functions still exist but this crap will infect your Blueprints.
As said, we try to. Not that we managed to reach this ideal in any existing project yet. We did manage to get Auto-Save implemented without affecting the “purity” of computations, but as you said, achievements and analytics are a PITA. I think those are possible with pure computations too, but we did not yet manage to build the game architecture in a way that makes that work. Yet.
I’m currently on a research project to investigate how much of a game we can move into pure Embedded Domain Specific Languages. So, basically a set of gameplay scripting languages that enforce the “everything that happens during the frame is pure” constraint. Buuut, again, this project is still at its early stages, and under very strict budget constraints, so I cannot say yet if the outcome will be a feasible architecture or not…
That is super cool that you got auto-save and auto-load to work with pure functions. It is technically an IO operation but with data structures and enums you can guarantee the same functionality as something stored in the heap.
The actual writing of course isn’t pure. Loading isn’t either, but we only support loading on level transition, so we can supply the data already when constructing the game state. Saving is done by gathering all the data that should be saved in a struct, what is pure and happens at a well defined point in the frame, where the game state is known to be consistent (-> I think it’s after all systems have been updated), and then this struct is written out to a file.