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.
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.
This is really weird to write… because… Atomik Kaos, the original, was a bit of an accident. The whole design was ad-hoc without any kind of formalism. Each token was designed as it was needed.
So what worked and what didn’t mechanics wise?
1. The twist to the chain reaction genre: let’s face it, it’s a genre where A LOT can be done. Most games are about either angles or position of the game tokens. Atomik Kaos picked up in both angles and position. Angles by putting that variable attached to each token type; position by randomizing each token in the level.
2. Variety: here’s something that often lacks to these games. As far as I can remember only Starshine offers some variety. A bunch of special tokens were created for this game. They couldn’t be played directly but rather activated by the chains.
3. Goals: Each level had a different goal. Either destroying everything, destroying part of something, not destroying more than an amount and others. Sometimes it was just a matter of words and the rules underneath were the same.
1. Black Holes are special atoms that suck up chain reaction particles. People just hated it and my guess is that it was not for the negative impact, as there are more negative tokens, but because it was not absolutely obvious how the black holes were sucking the particles.
2. Randomness and luck factor: I don’t believe that Atomik Kaos is a luck based game, quite the opposite. Problem is I’m not my audience and I played it a lot, something most if not all players won’t do. So the random factor of the game became a luck factor for the players and this worked as a downside of the game since on one hand it was frustrating, on the other hand it made the game too easy.
Tech Wars was our first flash game and taught us a lot of lessons. Our objective with it was to step in the flash game market showing attitude and quality and do we have a story to tell.
What went right…
We had no technology, no reusable code, no past experience in flash. Only our previous game development experience, an idea and the will so several things went right!
- Tech Wars was finished in about 8 weeks from nothing to completion which was a very interesting timing for a first project.
- From a project point of view it was a very rewarding experience since it showed that our workflow was adaptable to this new development environment.
- We closed our first sponsorship deal with it which, from a pure business point of view is great since it was our first game.
What went wrong…
Our expectations regarding the ins and outs of the flash market really took a beating with Tech Wars. We are convinced that reputation as a lot to do with this business and Tech Wars, when compared to the our most recent games proves exactly that.
Not only that, but our view design wise was flawed and that “injured” the game from a commercial and design perspective.
- Sponsorship deal was way lower than we expected but also presented us the opportunity to get in touch with a very hard working site owner that passed us a lot of useful information.
- The game is just too fast. Laser acts as a instant damage weapon and missiles, when fully upgraded are just too fast and go too far for a fire-and-forget weapon. Both weapons remove the aim and fire mechanic. From the three weapons available, only the rockets are the “typical” video game weapon.
- The game spread not for the quality of it but by the effort of the sponsor. Naturally we prefer to see our games spreading by merit and not by someone else’s effort.
What we learnt…
We learnt that no matter who you think you are, how good you think you are, a new market is always a challenge. We had (and have) to compete with the most imaginative game designers that exist: creative young people with a lot to win and little to loose.
We also learnt that new mechanics are not good until proven and we let it out before it was proven.
Last but not least, we learnt that a good game -and we do believe that Tech Wars is a good game and a good IP regardless of the difficulties- may not be a good entertainment product and that’s what computer games are today: not funny products but entertainment products.