Well…after a week or so of effort my first attempt at a pure C video game using SDL2 and its affiliate libraries is going pretty well. It has sprites in it although only single textures for the moment as it’s early days with it.
Open Game Art
What a great site, Open Game Art has proven to be. And in particular I would like to thank “Kenney”, whose resource pack has quite literally inspired me to pen three pages of game concept based around his work.
Free game art: KENNY
One day I hope to ping him by email and let him know how useful his work has been but not yet…I mean, I have to finish it first!
The game so far
It has a name, not the one shown in the picture here, but a much cooler one that I am keeping under wraps for when it’s finished. The dream is to get it into the Steam market place just so I can tick that particular to-do item off after so long.
It’s a traditional vertical space shoot-em-up but, being from the 80’s, I remember good old noisy games like Arcadia, Defender, Robotron et al. and so I want to make this is visually stunning and orally offensive as I can! :)
Is that of peaceful unstressed progress. I am determined to write as much C code as it takes to create really nice little features.
TDD with CMocka
In a previous post about C and TDD I mentioned cmocka. So far I have not written many tests, mainly for the game grid management (alien layout) and the tween library. But that’s the point…I TDD when I feel that the code may be prone to errors or needs to be nailed into place and the actual game play evolves out of stable components. The first time the tween library “worked” it felt awesome! And secure.
Non-allocation of memory
As far as possible I will never use malloc/calloc. As I said before I am developing a technique for this game that means I will minimise segfault opportunities by:
- static arrays
- assert(); everywhere
I have a star-field that has three types of stars, small, medium and large. There is a secret key that switches them between conventional dots and alternative star textures just because I needed some practice! I will leave that in, it looks ugly as hell but very Christmassy ;) LMAO
I ported some code from here and then built a while tweening engine around it which is proving to be awesomely useful. The “spawning” effect of the player ship is a tween on the ships alpha value, the aliens have random alpha and motion tweens to get them into position, it’s all just clicking into place and i can’t wait to do some more as time permits.
Source for my tweening code: warrenm/AHEasing
As part of my “tweening engine” I have built in the ability for the tween to call a user supplied function when the tween completes. I also will extend this later (if i need to) so that the different stages of the tween can be service as well in case that is useful. By passing a reference to the tween being processed and the application state, the callback can literally do anything it wants to anything it has access to.
Today I did the first pass on the player missiles hitting the aliens and it works! The aliens just vanish and when they are all gone, the next wave spawns. There is a lot of work to be done yet:
- proper clean up of wave state (hit counts etc)
- proper planning of the wave advancement strategy, boss levels etc.
I decided to keep it simple and to that end I have the worlds smallest Makefile that I found somewhere on Stack Overflow, I’ve tweaked it slightly here and there but it’s proving very useful. I have some previous posts here about using
I constantly switch between emacs, vscode, nano and…Scite/Scintilla editor. The latter has turn out to be a surprisingly nice little editor. It’s been around for a very very long time but I always thought it was irritating but I took some time to learn how to configure it and now I use it a lot of the time. Nice work chaps.
Didn’t need one much yet! However on the few occasions I did need to see what was going on I just keep going back to my old friend “DDD”, not domain driven development but "", still IMHO one of the simplest but useful debuggers out there.
GNU Debugger: “DDD”
I have started using this to “improve” compilation times, although my XPS 13 i7 8-core little powerhouse is pretty fast, it always helps to know you are being as efficient as you can.
It lives here: ccache.dev
Back to the hack….