So, I wanted to share a little bit about the background of this project. If I had a blog, I guess I'd put this there. But this place will do just as nicely, I think.
I have been a games programmer for a long time - wrote my first little game in 1983, you know the story, it's a common one. Got a job as a programmer in the games industry in 1999, and like many of my colleagues at the time, I was messing around with writing my own 3D engine in my spare time (remember, this was before Unity, when an engine license would cost you an arm and a leg). And just like many of the others, I never really got to the point of actually building a game on it - it was just a constant messing around with the tech.
Fast forward to 2007 - I was working for an independent mid-size studio, and we got a small contract to make a game for the, then booming, casual games market - the online portals, like bigfish etc. This was to be a simple 2D game, so we were given this in-house engine made by the publisher. It... didn't impress. It was slow, bloated, used a ton of middleware that didn't exactly gel in a natural way. So I started thinking that there must be a better way to do this. Not for the game at hand, that was on too tight a schedule, but just generally solving it better.
So while I was working on that game, I put my hobby 3D engine aside, and started working on a new 2D engine specifically tailored to small/simple games, where speed of development was important, but not at the expense of basic efficiency. I also made a point to not add any feature unless I was implementing a game (or prototype) that actually needed it, as I didn't want to end up with something big and bloated.
I quickly realized that this was a lot more fun than the old 3D engine I had been working on, in different forms, over the years. So I spent more time on this, but also more focus on actually making games with it, taking part in some game jams and such. I made a bunch of little game embryos and experiments, and kept growing the engine as needed. I called it Pixie, as it was meant to be small, lightweight and cute. I released all the source code as public domain from the start - I just wanted to use this engine for my games, not own the code.
As with any monolithic code base where you grow it over time, it gets a bit rigid after a while. It's not as easy to change something without affecting, or breaking, something else. Not knowing a better way at the time, I had implemented it as straight up by-the-book OOP - interfaces, inheritance, the whole lot. Which I still think is ok for certain parts of a system, if used responsibly, especially in the high-level gameplay code. But it is not really helpful to religiously carry it all the way down into the lowest, platform-interfacing layers of the engine, like I had done.
One thing that I found particularly annoying, was that whenever I wanted to work on something which didn't align with the Pixie way of doing things, there were very few options available to me - I either had to adapt the project to fit engine restrictions, or reimplement a lot of the stuff I had already implemented for Pixie. Or, use some other library/framework altogether. Every part of Pixie had dependencies on every other part, and there was no way to re-use just part of the code for a stand-alone project. I'm exaggerating a bit - it wasn't all *that* bad. It wasn't like I hadn't tried to be sensible about dependencies and such - but it sure felt like that most of the time.
Sometime around 2011-2012, while I was still happily making little games in Pixie, I had started to toy with the idea of doing an extensive refactoring, to make it a lot more modular, and also to move some parts of it away from OOP. Around this time, data oriented design was making waves in the industry, and this made me re-think my coding style on many levels, and got me questioning a lot of the commonly accepted "facts" about OOP. A vision started to form, on how I wanted to rework my old Pixie codebase into something more current to my evolved tastes.
Then at the start of 2013, I ended up working for one of the big publishers, for one of their big game studios in Sweden. And for the first time, my contract had an incredibly strict non-compete clause which left no room for doing *anything* game or programming related in your spare time. I lasted about a year and a half at that place - and I am surprised I lasted that long, for many reasons. But a big one was that I missed my hobby - making little games and working on my engine. So I finally left the games industry, after 15 years, and got a "real" programming job instead.
First thing I did with my new-found freedom, was start making a game again (http://gamejolt.com/games/extrication/62070
). I found the ShareCart1000 game jam (a running jam, (http://www.sharecart1000.com
) which had a couple of restrictions - one was a very limited save game format, and the other was a color palette of only 16 fixed colors. Not having made a palettized game in years (decades even), I was surprised by how much fun I had with it, and realized that this was what I wanted to do more of - palette-based retro-style games.
So, in 2015 I started to, little by little, refactor my engine. To streamline everything, make it as modular as possible (or at least practical). By now, I had found the wonderful stb libraries (https://github.com/nothings/stb
), and there are many things to like (and mimic) about them. One is the distribution aspect. With a single header library, there's only one file to move around - declarations, implementations and documentation is all rolled into one. Another thing is build configuration. No more wasted time trying to figure out how to set up make files or generate projects to build a lib. You just include it and go. A third benefit is configuration - being able to modify the librarys behavior through #defines (eg. giving a custom allocation function).
The plan I've been working to since, is to refactor all the core components of my Pixie engine into stand-alone stb-style single header libraries, and then write one "pixie.h" single header library containing glue-code and helper code to tie all my libs together into an engine/framework of similar ease-of-use as my old Pixie engine.
Over the next few posts, I will present some of the core libraries that has come out of this process, in the hope that they might be useful for others as well. The pixie.h engine lib itself, which we will get to eventually, will perhaps not be as useful, as I have intentionally made it very tailored to the games I want to make - low-res, palettized retro styled games. I have, however, kept the other libraries more generic.