I have some recent experience with doing game programming in C and while I think the experience was overall positive, I'm not sure that I would do it again unless my aim was portability.
I found that when my project grew to a certain size, I started running into many cases where I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance. This pattern is totally 100% possible to roll yourself in C, but requires a bunch of boilerplate each time and I found that every time the implementation came out slightly differently, or that I had to go back and rewrite a bunch of code because I needed one more layer of flexibility than I anticipated.
I also really wish templates were in the language. Maybe not to the C++ level of flexibility, but at some point, you're going to need a dynamically allocating array or hashmap of a specific type, and your choices are either going to be *void or some macro thing that makes your eyes cross.
Also, build tools in 2019 are still kind of bad. I use CMake and try to do things "the right way", and I still run into trouble occasionally, mostly surrounding external dependencies and generation of files outside the scope of the C compiler. It's a shavable yak, but it's still a yak.
Still, the lack of mental overhead and the much faster compilation times compare favorably to C++. But if portability wasn't a goal, I'd seriously consider an alternative like D, Zig, or Nim next time.
>I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance.
Inheritance is an anti-pattern, you can accomplish the same with composition.
>you're going to need a dynamically allocating array or hashmap of a specific type, and your choices are either going to be void or some macro thing that makes your eyes cross.
I don't understand, why would you need a *void for a specific type? If you meant heterogeneous types, you can use a typedef union.
In all my gamedev I've found that the best structure was how Lua does meta-tables.
You can then use that simple mechanism to implement inheritance, component based design, message passing or whatever structure makes the most sense for your game design. I'm personally tend to lean towards component based for reusability and performance but that's by no means a hard-and-fast rule.
interesting, i'd suggest you to follow the blog, iv'e already implemented something like a dynamic array in the first post and will have to implement some other "modern" things in the near future, it's awesome what you can do in C89
I found that when my project grew to a certain size, I started running into many cases where I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance. This pattern is totally 100% possible to roll yourself in C, but requires a bunch of boilerplate each time and I found that every time the implementation came out slightly differently, or that I had to go back and rewrite a bunch of code because I needed one more layer of flexibility than I anticipated.
I also really wish templates were in the language. Maybe not to the C++ level of flexibility, but at some point, you're going to need a dynamically allocating array or hashmap of a specific type, and your choices are either going to be *void or some macro thing that makes your eyes cross.
Also, build tools in 2019 are still kind of bad. I use CMake and try to do things "the right way", and I still run into trouble occasionally, mostly surrounding external dependencies and generation of files outside the scope of the C compiler. It's a shavable yak, but it's still a yak.
Still, the lack of mental overhead and the much faster compilation times compare favorably to C++. But if portability wasn't a goal, I'd seriously consider an alternative like D, Zig, or Nim next time.