Right now I'm heavy into C++, especially C++17, but mostly due to the current project I'm working on (tools engineer @ gamedev)
20 years ago, my first project was being part of 4 people team porting Metal Gear Solid from PS1 (PSX) to PC. This is when I saw how good written "C" code could be done. Even if it had only japanese comments in the code (understandable).
The pure and simple structure, where most of the functions had TCL-like interface:
int ACT_Work( int argc, sometype* argv )
{
// bit of argc/argv parsing
Do_Work()
}
then above was exposed to a TCL-like scripting language, used for setting up level objects... We are talking about 500-600kb of memory used by the main executable + 300-400kb of 'overlay' memory where "shared, e.g. dll/so-like" code gets replaced depending on what objects needs to be in the game (Mentioned "overlay" as this was very well established practice back in the DOS days).
Things really were plain and simple. API-s too. It was so easy to grasp what's going on.
Then again, since this was running on what looks like really limited machine, it had to do only such and such. No fancy animation controllers, advanced physics, collision, etc. etc.
at some point, especially if it's a content creation tool (think Maya, or any Autodesk product, Houdini, etc.) then you need to be able to handle tons of "nodes", "entities", meta-data, etc. - but when it comes to a game, even nowadays - pre-cooking gets you there, and quick deserializing - either piecewise, or whole sections, and then pointer fixup.
Point is, is your game, and engine meant to be content creation tool too?
e.g. "C" is still valid choice, if your data is well organized, known, and no additional heavy modifications are need - e.g. you don't change much - mostly load "pre-cooked " data, play it, keep few (okay dozen, maybe hundreth, even thousand) variables around and that's it.
Once you get to the point of needing various tweaks, modifications, changes, more advanced UI, etc. - you may need better suited language, because malloc/free won't cut it for you.
20 years ago, my first project was being part of 4 people team porting Metal Gear Solid from PS1 (PSX) to PC. This is when I saw how good written "C" code could be done. Even if it had only japanese comments in the code (understandable).
The pure and simple structure, where most of the functions had TCL-like interface:
int ACT_Work( int argc, sometype* argv ) { // bit of argc/argv parsing Do_Work() }
then above was exposed to a TCL-like scripting language, used for setting up level objects... We are talking about 500-600kb of memory used by the main executable + 300-400kb of 'overlay' memory where "shared, e.g. dll/so-like" code gets replaced depending on what objects needs to be in the game (Mentioned "overlay" as this was very well established practice back in the DOS days).
Things really were plain and simple. API-s too. It was so easy to grasp what's going on.
Then again, since this was running on what looks like really limited machine, it had to do only such and such. No fancy animation controllers, advanced physics, collision, etc. etc.
at some point, especially if it's a content creation tool (think Maya, or any Autodesk product, Houdini, etc.) then you need to be able to handle tons of "nodes", "entities", meta-data, etc. - but when it comes to a game, even nowadays - pre-cooking gets you there, and quick deserializing - either piecewise, or whole sections, and then pointer fixup.
Point is, is your game, and engine meant to be content creation tool too?