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...
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.
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.