08-31-2020, 08:46 PM
C language is still prevalent nowadays because it's the "lingua franca" of programming languages. It can target everything, from tiny microcontrollers with few kilobytes of memory, to huge supercomputers. It's the systems language in which foundational core components are written: operating systems, device drivers, graphics libraries, protocol stacks, virtual machines and interpreters of other languages... Everything can be built in C, however it's not the right tool for everything. It doesn't get in the middle, so you need to be really careful about what you're doing. It's easy to break things messing with pointers, buffer overflows and mismatching data types. It's a powerful yet dangerous tool, as you have a gun that can shoot your own feet. Yes' there's C++ too, but its implementation of OOP is quite cumbersome, and being unmanaged makes it vulnerable to the same problems as plain C.
"Modern" languages have appeared that are more suitable for end application development, that hide system complexities managing them themselves and avoiding entirely these kind of dangers. I say "modern" because they-re not so new: Python is nearly 30 years old, Java is about 25. But they haven't replaced C because these languages aren't suitable to create system components. Their runtimes require an underlying OS, a virtual machine, a JIT compiler... They require big infrastructure programmed in C, and were created for a different task: end applications.
Programming paradigm is not the problem. C is a procedural and modular language. It provides mechanisms to create independent and reusable components, with good separation of external interface and internal implementation. You can create unstructured spaghetti code in pure OOP languages, too. OOP is well suited to model a wide range of problems, but it's not the right tool for everything, either. OOP can be abused to create endless chains of inheritance and method overwriting that are hard to follow and easy to break, especially when you're trying to "force" a solution to fit inside a OOP paradigm when the real-world problem doesn't.
However, we're here talking about building games, and games are a field very well suited to OOP. You have lists of "entities" with common attributes, that then specialize in more specific types of entities (subclasses). Games can be programmed without OOP support (and traditionally have been), but you end modelling something that resembles the kind of subclassed objects that OOP natively provide. That's why the main Tilengine library is built in pure C (portable system component accessible from many high level languages) but bindings for application languages (Python and C#) are already modelled in OOP.
"Modern" languages have appeared that are more suitable for end application development, that hide system complexities managing them themselves and avoiding entirely these kind of dangers. I say "modern" because they-re not so new: Python is nearly 30 years old, Java is about 25. But they haven't replaced C because these languages aren't suitable to create system components. Their runtimes require an underlying OS, a virtual machine, a JIT compiler... They require big infrastructure programmed in C, and were created for a different task: end applications.
Programming paradigm is not the problem. C is a procedural and modular language. It provides mechanisms to create independent and reusable components, with good separation of external interface and internal implementation. You can create unstructured spaghetti code in pure OOP languages, too. OOP is well suited to model a wide range of problems, but it's not the right tool for everything, either. OOP can be abused to create endless chains of inheritance and method overwriting that are hard to follow and easy to break, especially when you're trying to "force" a solution to fit inside a OOP paradigm when the real-world problem doesn't.
However, we're here talking about building games, and games are a field very well suited to OOP. You have lists of "entities" with common attributes, that then specialize in more specific types of entities (subclasses). Games can be programmed without OOP support (and traditionally have been), but you end modelling something that resembles the kind of subclassed objects that OOP natively provide. That's why the main Tilengine library is built in pure C (portable system component accessible from many high level languages) but bindings for application languages (Python and C#) are already modelled in OOP.