On Saturday, 1 July 2017 at 21:00:14 UTC, Ecstatic Coder wrote:
Whatever the object oriented language you use, you can keep
exactly the same global game architecture, using more or less
the same classes for your game subsystems and gameplay elements.
Therefore, as an old game industry veteran, I confirm what you
already know, which is that it's all about memory allocation,
access and deallocation when comparing a game made in C++, D or
Rust.
I'm not saying that other matters are not important, but many
game development directors apply Bertrand Meyer's architectural
advices (design by contract with pre/post condition assertions,
etc) since the early nineties, so there is not much difference
between a C++ game and a D/Rust game in this area.
So all that remains in the end are just concurrency and
memory-related features, like immutable data, array memory
slicing, automatic array bound and null pointer checking,
object destruction and deallocation through variable scope and
garbage collection, etc.
This of course includes interfacing with C/C++, i.e. managing
the memory and lifecycle of C/C++ structs/objects from D or
Rust.
With D, my biggest concern was about avoiding the application
thread to freeze during a GC, while C++ and Rust can completely
ignore this problem.
IMHO just these last points could already explain why Rust and
C++ still remain preferred to D for game development...
That's a good statement which I found very often recently. Maybe
I should change my main focus from architecture to
software-engineering per se...
Maybe an comparison between different software-products (one in
an insecure and one in a secure programming language) to show
the difference and potential vulnerabilities.
