Bold Pixel Engine v1 Post Mortem

I guess it’s pretty strange to have a post mortem of something that is not a game, but Bold Pixel Engine, in its first version was a fantastic learning experience, but it had a overwhelming amount of failures also. To sort my thoughts I checked the tag of the engine in our blog and read some of the stuff that happened as time passed. This led me to write this post mortem, on one hand to know exactly what is right about it, on the other hand to learn from our own mistakes.

A bit of historical perspective

Bold Pixel Engine started with our first flash game because of a simple music management class. Back then, both me and Diogo were coding and I remember (and I admit I deeply miss) our discussions about code standards and organization. I’m a bit of a dictator when it comes to have stuff organized, credits to Marco that has used the word “dictator” more than once and with a large amount of reason and giggles.

Soon our bunch of classes were our own internal library and I even posted some of my own experience while organizing that library. Some of the most important definitions of Bold Pixel where then starting to emerge. July 27th 2009 we announced Bold Pixel Engine was alive.

I was quite excited about it!

The turning page from internal library to public engine was the blit engine. We had so much help from many amazing developers that we would not keep it for ourselves. We wanted to share, we wanted to hear what others had to say and that’s what we did. After two games under his belt and a lot of opinions, the engine was publicly available and his version 1 life was pretty much that until the version 2 turning point a couple of months ago… but I’ll get to that eventually.

What went right!

The learning process was amazing code wise. After Diogo left I really had to raise my standards and get to work and the engine allowed that. Coding such a piece of technology made me contradict myself several times and pushed me forward. I’m absolutely convinced that I am a much better ActionScript programmer now than I was before and I feel I learnt little from the games but a lot from the engine because I forced myself to respect the principles I wanted to see applied to it.

And speaking of principles, these stay true from the first line of code until today and are something that really went right. And these are:

Convention over configuration: Bold Pixel Engine is written assuming some conventions. For example, if the programmer tells the Scene Manager to create a new scene, the previous one and all dialogs will be removed, which makes a lot of sense but maybe it makes less sense to say that all scenes have their pivot point at 0,0. This means that scenes and dialogs are simply added to the display list and that’s it, nothing to configure since there is a convention.

Ease of Use: This goes hand in hand with convention over configuration. If there’s something that really makes my head hurt is to look at the code needed to make something happen in libraries like Flixel and Box2D. I appreciate the effort put in these libraries and the flexibility and power provided but I believe that if we have to configure every single tiny detail the code becomes cryptic and extremely difficult to debug. I don’t mind loosing flexibility because I will create more mechanisms that will help me achieve my goals as time goes by.

Modularity: There is only one dependency in Bold Pixel Engine, which is the Manager class. If you want a single loop or to manage scenes and dialogs, you need to start it up. Apart from that Bold Pixel Engine started modular and will stay modular. The reasoning behind this were two questions I made once:

1. What if I don’t want to use the blit engine?
2. What if I want to add something that will wreck dependencies?

The answer to that was that I wanted it to be flexible, meaning, I can use whatever I want with only one dependency and that’s it. I don’t want the engine to behave like an engine. I want it to be a toolkit at my disposal. I even had a laugh about this.

What went wrong…

First and worst aspect of thing that went wrong was that I did too much stuff that we didn’t need that was requested and I didn’t do it with the same dedication I did the rest. That will never happen again. I’m convinced I got carried away by the kindness of a lot of devs, but we can’t have the engine restricted to the needs of others, which was something I said it wouldn’t happen from start. But what it really makes me feel bad about it was that other devs got involved in the project and this collided with either our work or their work making it a bad solution for everyone.

The second thing that went wrong was that I overcomplicated somethings because I felt it made sense. For instance there is a Scene Manager and a Input Manager and a Manager. All of these managers depend of a Display Object and/or its stage. While it sounds easier to manage code and it looks more tidy and clean, having a gazilion classes doesn’t make it easier to code with. I found myself looking through the classes to find what I wanted… that doesn’t sound like a good thing, right? I mean, I coded it!

And last but not least, I think I really rushed things. The idea behind the public releases of the engine were that we would make two games between each release, which we actually did with v1, but as soon as I had the mechanics ready and all the engine’s juicy code was on a actual project, I went head over heels with it. It lacked documentation, it lacked cross-testing (so, just because I did two games, I should have tried against the two games again) and most important it lacked a critical look and a some honest and critical analysis.

Conclusions

Great experience and I really appreciate all the kind words that I got from developers. I think the really cool thing that most developers got from it was the ease of use, probably the YouTube channel with some nice overview on it. I could’ve written a post trying to sell the idea that we are overwhelmed with joy and l33tness, but I would be failing to be honest. I truly believe that BPE v1 is a great piece of software, but I was naive in the approach and maybe over-friendly in the “pleasing my fellow devs” department.

We have a game going with v2 and I think I sorted my doubts about what is going to happen with the engine. Many things that were wrong with v1 are already gone and there is a lot of stuff that isn’t even started, like moving the Music class which started all this into the current version.

There’s a lot to be said about v2, but this is a hell of a long post mortem and I’ll write about that soon.