SDL gives you an API for 2D rendering, mostly limited to drawing boxes, lines, and bitmaps. OpenGL lets you program the graphics card for any use case, most commonly 3D graphics with room to add complex effects and post-processing. The SDL API is just nowhere near flexible enough for what I want to achieve.
Plus, Vulkan is not really "faster" than OpenGL. It just gives you a different API for programming the same graphics hardware, which in the hands of the right person can be used for writing code which is "faster".
The reason I kept the minimum OpenGL 3.3 requirement is because it is supported on the biggest range of platforms. OpenGL 4.xx features require some features from newer generation cards. Of course, with time this is becoming less and less relevant.
In some parts of the code, I did make use of OpenGL 4.xx features like glMultiDrawIndirect, but this is put behind a check to see if it's supported by the driver and added a slower fallback for OpenGL 3.3.
My initial idea was that I wanted a more "sexy" language for scripting. Python is a lot more popular and (arguably) more enjoyable to use than Lua. There's a lot of cool stuff like list comprehensions. Plus I had a selfish reason of just wanting to learn more Python and fool around with the CPython code.
Over the duration of the project, I really did learn to appreciate why Lua is embedded into games and Python isn't. Lua is really small and you have full control over everything. And you're eventually going to need that control when you implement features like reflection, pausing the game, etc. CPython is this big shared library that does its' own thing and you have a lot less control over. The parts where it just doesn't expose enough through its' API do do what you want is a real huge pain. I ended up writing a bunch of code to serialize all the internal data structures and this was a massive chore. Also you have a lot less control over CPython's performance and memory allocations.
I didn't really appreciate these things when I started the project so hence I went with Python. But since I ended up doing it, I guess you can still enjoy the benefits of it.
I guess the "shtick" of C is that it has a small and obvious feature set. The readability and style of programming follows from that. As you start adding more and more language features and constructs, you start getting all the other languages that were derived from C and you no longer have C.
During the development of the project, I had a thought that it would be nice to have a RAII/defer mechanism to get rid of repetitive code for freeing resources at the end of a function. But I'm not sure if that's really necessary since you can just put the 'free' calls at the end of the function and insert some labels between them in a kind of 'stack'. This perhaps is more in the spirit of the language - a bit more wordy, but having less voodoo done by the compiler.
Eh, I don't have a great justification why Python 2 should be used over Python 3. I made this choice like 3 years ago when I didn't know too much about Python. That's it. Since I wrote some code against the C API of the interpreter and made a whole bunch of scripts already, it's a massive chore to migrate. Classic story, I know. If I were to start a similar project today, I would attempt to use Python 3 first.
That being said, I did come across some discussions (ex: https://stackoverflow.com/questions/34724057/embed-python3-w...) where it is not possible to strip the standard library from Python 3. I think the use case of embedding strictly the interpreter without any "batteries" is not popular and thus has not been that well-maintained. I've not tested this in practice, however.
All the fundamental behaviours (movement, combat, resource harvesting) are implemented in C.
The engine uses Python as a scripting/config language. You can use it to hook into a lot of events pushed from the engine core (unit got selected, unit started movement, unit started harvesting, etc.) and customize or change the unit behaviours.
Over the long development cycle of the project, I've accumulated a nice little library of data structures, allocators, and utilities (mostly in src/lib). Between those and the low-level engine systems such as the task scheduler and event system which have a generic API for any other system to make use of, I believe I have good foundations in place to develop new engine systems relatively easily. Of course, this required the initial investment of laying these foundations.
Most error handling just consists of checking the return value of a call and propagating it up to the caller if necessary. Sometimes I also set an errno-like variable with an error message to check it in the top-level code. It's a bit wordy but obvious and sufficiently good for all my use cases.
I don't think C limits the size of the project. It's all about good organization and coming up with the right higher-level protocols/conventions. This, IMHO, is what allows or prevents the code size from scaling gracefully.
Plus, Vulkan is not really "faster" than OpenGL. It just gives you a different API for programming the same graphics hardware, which in the hands of the right person can be used for writing code which is "faster".