Sometimes you spend forever designing your house of cards to be rebust only to find the bricks were beside you all along
I’ve spent the last 5 years designing my C++ library Shock. It’s basically designed to let me create a number of games I’ve always wanted to make with a massive amount of code re-use and a number of other niceties thrown in.
I’ve been experimenting with Python and it’s opened my eyes to the flexibility of modern programming languages. I think it’s what I should be developing in.
I’ve coded C++ since uni. It’s what I do for a living. But the irony is, I hate C++. It’s not just that I work with it all the time and have had bad experiences, C++ is truly horrible. And the sad thing is, it’s so pervasive that we can’t shake it.
Most serious game related libraries (3D engines, Physics, Audio, Input) are all implemented in C++ and a few in C. This is understandable, most of these need to be fast as they use a lot of mathematical calculations.
But it seems this is causing a flow on effect. Game engines and game logic are still primarily implemented in C++. It’s difficult to find a decent game engine or library thats implemented outside of C++.
I have a few ideas as to why this is.
- The programmers producing mature code now, are from the days of C++ being “the language”.
- The engines have only just matured.
- Scripting languages are still seen as too slow.
- Most systems aren’t well designed and can’t be modularised.
I think I can safely say that all AAA games released are in C++ these days. I doubt many AAA games would touch a scripting language for anything but mission scripting or animation systems. Why? Because they’re too slow.
The irony is that’s the same thing they said about C++ 10 years ago. Back then games were all in C because C++ was too slow.
CPU’s have made tremendous gains in terms of processing power and so has computer architecture, with more and more work being pushed to parallel computation on GPUs or multiple CPUs.
The worst case for using a scripting language is that the game needs to be slightly less detailed, either graphically, physically or just simply in the number of objects being processed during any one frame.
C++ is a mess. It truly is. And it should be relegated to low level systems programmimg where things like registers and controlling memory allocations are required. But we don’t really need that for games. If you’re worried about fragmentation then you can always knock up a memory pool later on when you start optimising. And if performance is an issue, bind your code to some C/C++ or what-not and go to town with it.
This leaves me in a predicament. I’ve designed and written Shock over a long period. It’s like a child to me. But C++ is old news and to continue down that path really is a very slow death march. But in 2 hours in Python (without even knowing the language properly), I got to the same point in development as I was with my C++. My library just finished abstracting the platform and providing enough framework to begin developing my game systems, so it’s essentially the same as a quick install of Python.
So, do I continue my C++ death march and not waste the time I spent developing it? Or move to another language?
And what about my C++ library? Do I throw away that code? Open source it? Or develop in the background for a more complex game that requires more speed from my code (which Cython could probably do anyway)?
For the time being, Shock will be on the back burner. I’m going to develop in Python for a while. I’m considering open sourcing the Shock C++ library, but I’m not sure yet. And even if I did, I’m not sure how much interest there would be.