Archive for the ‘Feedback’ tag

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.


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.

Posted: August 12th, 2010
at 11:53am by Vlad

Tagged with , , ,

Categories: Postmortems

Comments: No comments

Game Design Perspectives

I have several motivations to write this blog post. I knew I wanted to call it game design perspectives because it is about game design and perspectives about it but I didn’t really know how to put it. So I decided to put up an image and made a search on my favorite free image plugin. I searched for “perspective” and found this one: perfect.

When I coded my first game I had no idea what game design was. Some years ago, right before starting up Vortix with Marco and Diogo I had no coding knowledge whatsoever so I focused on game design. Problem with game design back then was that everyone wanted to be a game designer… it was the game designer wanabe boom period.

Back then (and it wasn’t that long ago) every guy that played games and wrote two paragraphs of a Tolkien ripoff considered himself a game designer, me included. Many of them didn’t make it up to the professional stage. Looking back, the only ones I know that got into the game development industry are either artists or engineers. The only game design wanabe that managed to pull it was me… and I’m more a programmer than a designer nowadays.

The perspective back then, the passion, was about the game. We all steped our of the dream and learnt that game design is about decision making, getting feedback and more decision making. All game designers, wanabe or not, had only one goal: the game! Like the two crossed railway lines, game design is all about crossing left and right sides of the brain. See the whole while addressing the details. Be able to analyse data and crunch numbers while being able to… well… feel…

It is sad to observe that on a market such as the flash game space the perspective is that a designer’s objective is to make a game that is sponsorable. I find this not only sad, but wrong.

Squize commented on a blog post of his that:

(…) it’s all about the creative process now, so I’d rather push myself and fall short than work to someone else’s design. (…)

Julian from LongAnimalGames mentioned today in the FGL Chat that he considered more interesting the psychology of players than game development itself.

It is a trend I find in many high profile developers. They care about business and particulary money when hiring, when selling, when paying, when discussing deals. Money doesn’t get in the way of design and they have other interests… the creativity, the psychology, the technical expertise and others. It is interesting that these are the ones that make the great, memorable and amazingly sponsorable games. I know one exception… that simply confirms the rule.

Like them we are not against the commercial or business side of all this and we take it very seriously, but game design is about the decisions, the rules, the player, the big shiny paradigms. Production, marketing, whatever, that’s the business part, our job as designers is to reach as many players as possible. We might argue that the bottom-line, that’s what will make the game sponsorable, but it is not the motivation when making game design decisions. Money is a unnecessary distraction while designing.

Posted: August 10th, 2010
at 12:46am by Vlad

Tagged with , , , ,

Categories: Caught our Attention

Comments: 1 comment

Brain Melt

I’ve been writing and re-writing a lot of code lately. Somewhere between the work to be done and the work I want to see done, there are dozens of thoughts and discoveries that are worth sharing. Some are puzzling, others are simply brain melting.


A long time goal: behaviors! What is it? How does it work? Well… imagine you write this line of code in a Bold Pixel Engine entity:


And from that moment on, the entity will always rotate to the mouse position. That’s a behavior.

Imagine that you could say that instead of facing you’d want it to rotate to the mouse position at a given speed, or with a tween, or that you want it to evade another entity or to find the path to a certain point. Now imagine that behaviors could applied to time… that you could tell your engine time would slow down so you could see all in slow motion…

Well… I wrote two behaviors and it works like a charm!

Flash Player is somewhat smart

I’ve noticed that if you copyPixels() or draw() outside the target bitmapData area, it won’t render anything. Having thousands of objects outside the rectangle area is absolutely meaningless, even if you apply a transformation matrix and draw.

I thought about the possibility of creating a camera object… suddenly this possibility became obviously closer since there will be no need to verify if an object is supposed to be rendered, Flash Player does that for me, I just have to pass the right rectangle… awesome! or at least I’m thinking it will be!


I really needed a rest a couple of nights ago… so nothing better than writing some new functionalities! My goal was to write filters to apply in layers. After noticing that most flash filters need a BlurFilter applied on top of it, I decided to make it simple and just work with one BlurFilter and one ColorTransform in each layer.

BlurFilter is a huge performance killer, so I played around with only applying the filter to whatever the area the filter needed to be applied to and it works great! The bigger the area, the bigger the performance impact that’s for sure!

ColorTransform seems to have no impact. I’m betting that the pixel color is calculated directly when drawing… if this is true… it’s quite smart!

All in all and since I didn’t want to use any other filters for performance issues, I noticed that with just a little tiny bit of patience, blur and color transform can do most of the cute effects we might need, from shadows to glows to motion blur.

Brain melting the possibilities

A camera with behaviors, like moving to an area with tweening. Flames coming out of a structure and then exploding in thousands of particles flying around with fire trails. Zillions of projectiles flying around in a huge map… wow… this weekend really caused a brain melt.

Need to finish the tutorials to Bold Pixel Engine v1 because v2 is already shaping.

Posted: February 16th, 2010
at 1:00pm by Vlad

Tagged with , , , , ,

Categories: The code of VGS

Comments: 2 comments

Encyclopedia of Players

Disclaimer: this post, unlike most of this blog, does not have the intention to present information or discuss any particular item. It is a fun motivated post, one that should be taken lightly, with a smile and nothing else.

Most if not all flash game developers have read comments about their games that triggered some feeling. Many times we fail to see the positive side and focus on the negative side. We are taking content to an audience and nowadays that means that either we like it or not, that audience will voice an opinion. Is is much easier to take the strong opinions with a smile and I hope this helps giving you that smile. :)

The 100m athlete

His only motivation is to be the first. He wants to, he has a lot of competition, but sooner or later he will be fast enough to be able to write:


and he won’t rest until he is banned! That’s his gold medal!

The obvious

It could be better.

O’rly? It could, I admit, but how? It’s like saying that it is a game, isn’t it?

The nonsense

This type of player is really unpredictable. We never know what’s his next comment. It can be something like:

LOL OMG it’s yeah!

to something really strange like:

Loved the game! 1/5 because I don’t like the name!

We never know what to expect… by the way, this last quote… true story. :)

The sober policeman

This player plays a lot of flash games. He knows the portals, he knows the developers, he knows if a game was uploaded by someone that is not the rightful owner. What can I say? The sober policeman is a real helpful player in many ways.

The drunk policeman

Ok… I only wrote the previous one so I could write this one. :) This player plays a lot of flash games but all games that look alike were stolen! What was the stolen game you may ask? Easy! The first game of the same genre he played. He also assumes that a sponsored game uploaded by the developer was, without a trace of doubt, stolen by the developer.

Games with stolen IPs are ok though, as long as he is a fan, like a Mario clone or something that remotely looks like Zelda… with Zelda graphics…

The analyst aka flash game journalist

This is a real, typical comment from this player type:

It feels… restricted. As far as I can tell, it is perfectly unclear as to how money is being earned. It just hands it to you at the end of the level. Similarly, there is almost no indication as to whether you are hitting something, unless it dies. Having scrollwheel weapon change is bit odd, considering that most people will be playing tihs in a browser.

I honestly love these guys (and gals)! They usualy know what they are saying, they write well, take the developer hardwork into consideration. They pinpoint problems the game has and they do so in an elegant way. Bottom line, they are really helpful.

The needy

Needs upgrades…

Needs badges…

Needs ketchup…

Needs more levels…

<insert your favorite need here>

Now that I think about it, usualy it’s not the game that needs it. It was designed like that so, that’s what it is for better or worse. Who needs something is the player.

The nice guy

I don’t like this game. It’s boring! I have better things to do than to waste 5 minutes of my life playing it. But since you used red in the logo and my dog is running after his tail, I’ll give it an 8.

Thanks mate, very helpful!

The complacent father of all developers

Really funny… he assumes that ALL developers are 13 years old. It’s really easy to spot! If you make one mistake, serious or not, he will say something like

The mute button is not working! I don’t expect that you 13 year olds can do a proper game.

or (and this is just hilarious) if you do something that he doesn’t like, it is not a mistake, bug or problem, he just doesn’t like that…

You 13 year olds still have a lot to learn. Ice towers also deal damage, not just slow down.

The uber game designer

This is probably the only type of player that I really don’t like and that annoys the hell out of me, but there are so few of them that their presence is rarely noted, thankfuly. This is someone that took a couple of hours to create something that remotely looks like a game and that from that moment on feels he has all the know-how to trash every single game that he doesn’t like.

He usualy shares pearls of wisdom such has:

This game sucks! Collision detection fails more than 50% of the time!

These pearls of wisdom usualy meet the following logic: the game in question does not have collisions, or even if it had, how does he know that it is more than 50% of the time? It’s funny because it’s true.

The spell checker

The typical spell checker is usually also a complacent father of all developers. But there’s a weird breed of spell checkers… I can’t really explain how they are, so here’s a comment…

LOL u dont now how 2 spel aphrodisiac

and last but not least… The follower

The follower is cute in a way. Followers simply follow an opinion that is from someone else. For instance if a uber game designer says that the game has a problem with collision detection, even if the game doesn’t have CD at all, he will just state that he also noticed that. A lot of followers follow spell checkers, I don’t know why. Followers are good if you have a good game and bad if you have a bad game.

Hope you like it!

Like I said, this post is for fun and kicks, don’t think too much about it. Many comments are really good and helpful and we have to look at pointless comments as part of it.

Posted: August 7th, 2009
at 12:00am by Vlad

Tagged with , , ,

Categories: Funny Facts

Comments: 21 comments

A flash game must have…

A lot of info spread through the web about what flash games must have or not. Here’s our take on it:

…a mute button

Although everyone will scream their hearts out that a mute button is a must have, I beg to differ. Since Atomik Kaos that we changed the mute button (or key) for an entry screen that asks if the player wants sound and music. We did it because it personally annoyed me to enter games with bad audio and music and have to wait until the place where the developer decided to put the damn mute button.

We received a lot of feedback praising such a decision and one rant about it because the sponsor intro sounds played because the decision screen was after the sponsor intro… that one negative feedback completely forgot that even with a mute button, it would hear the sound way before the usual mute button showed up.

…saved data

Some games need saved games, others don’t. But saving data is more important than just saving your game state. You can present the player with a lot more stuff if you get used to gather statistics.

I won’t go to long with this since it’s very game specific but you can do some very nice things, such as present end-level or game-over statistics that will keep the player going.

…right mouse button context menu

Someone mentioned this in the FGL chat. I personally only took it off twice, both times by request. I understand that it is something that I’ll probably address now that I’m conscious of it, but I never felt or received any feedback about it for our games.

…the right instructions

Don’t throw all the instructions at once at your player. As he progresses through the game, give him the info he needs for that task.

Often instructions are loads and loads of text that no one reads. Everyone did that mistake at least once.

…pause on lost focus

Some games have it, others don’t. For the download market it was a feature that every portal asks for, in the flash market I honestly prefer not to do it.

This is quite easy to explain. Most flash games take a small area of the whole web page where they are embedded. Usually and unless the mouse is the input of the game, the mouse is taken off the game because it’s pointless to be there and it is just covering something.

In my opinion, catch and pause the lost focus event only if your game is time dependant and the mouse is the player’s input to the game. Appart from that it can be pretty frustrating.

…user input customization

Some developers do it. Most don’t. Give the user the option to configure keyboard input that feels most natural to them. You can then leverage the ’save data’ feature to store those preferences locally. Thanks to Phil Peron for pointing it out.

Nothing else occurs right now, so feel free to pop up something I might have forgot and I’ll write it here! :)

Later folks,


Posted: July 7th, 2009
at 10:14pm by Vlad

Tagged with , , ,

Categories: The design of VGS

Comments: 6 comments

« Older Entries