Archive for the ‘The design of VGS’ Category

Application Design vs Game Design Round 1

Hi everyone, Vlad here.

Let me start by saying that the title is a bit misleading. For starters it is not an actual bout but more a decision making process. It also gives the impression I’ll write more about this or that I have some kind of plan about this subject. I don’t, it just happens that I think I’ll travel this road again.

Game Design

The game design for this game states that:

1. The player’s objective is to reach the top of the “structure” (named just to make sense) where the action rolls;
2. The “structure” has several “floors” (again just for easier comprehension);
3. The player can fall to the previous “floor”;
4. It is guaranteed that the player will see at least three “floors”;

Application Design

One thing that I know for sure is that we will be blitting all graphics and that the player token has three different blit objects and two of those rotate thus negating copyPixels and putting the dreadful draw method to work.

Another thing I know is that each “floor” is a tilemap, also blitted and that each tile is 64×64.

And now the assumptions begin. How big is each “floor”? I have no idea but let’s say that a rather large “floor” has 50×50 tiles. If the player will see at least three floors and on later stages all “floors” are rather large we are talking about 7,500 tiles to be rendered with a astonishing number of 30,720,000 pixels to be copied… each frame.

The “floor” where the player is will only render the tiles on screen (88 max) but the other two lower “floors” can potentially be fully rendered given the camera specs. Even if all three “floors” only rendered tiles on screen (which won’t happen by design) there would still be 7,500 objects to manage and that’s tiles only since we need to add to this all the remaining entities: player, enemies, decorations, effects, etc, but to make it worse the bottom two levels will be zoomed and probably in full view which means not only that all their blit objects will be visible but also that at least 5,000 of those objects will use draw instead of copyPixels… Did the headache kicked in already or is it just pure performance insanity?


One of the great things about copyPixels is that it only renders the intersection between the target bitmapData rectangle and the source rectangle positioned at the destination point. What this means is that if we have 1,000 objects to render but only one actually has an intersecting rectangle, most of the processing time is running the array, vector or list and – more important and processor heavy – calling the functions that will in the end render.

The draw method also does this with a matrix… more on this later.

The solution was to write a BlitTileMap class that builds the tilemap in one big texture before it is used. While it uses much more RAM this class allows to address pretty much every problem stated earlier.

First and foremost the number of objects managed and therefor the performance lost with running their container (in our case, a linked list) and calling functions. From a potential 7,500+ we now have 3. The other issue that this addresses is the number of pixels it will render or try to render, from potentially 30,000,000+ to the worst case scenario of 1,050,000. And last but not least, considering the lower “floors” will be zoomed out, instead of using draw to render 5,000+ objects it will render… 2!

But the draw method also has a funny and helpful consequence. The smaller the scale, the faster draw executes which in terms of performance is relevant considering the zoom out will be achieved through scale. Less objects taking less time to render will be (I hope) quite a performance boost.

Did I just write all this? Wow!… Later!

Posted: January 25th, 2012
at 12:15am by Vlad

Tagged with , , ,

Categories: Dev Journal: Danger Zone,The code of VGS,The design of VGS

Comments: 2 comments

Hajime has a video

Hello, Marco here

Today I’ve been busy along with Pedro, putting together the final sound effects on the game so I could capture footage to create what will be the promotional video for Hajime, our next release. It’s been a huge trip. Not the smoothest but I have to say its been nothing but satisfying. Even Vlad, who has been working on other projects till very recently, was moved by the  VGS logo and splash screen. Something we haven’t seen in a long time, not with all the outsourcing development. It’s nice to be able to put our name one something again, but specially nice that its something we are so proud of.

So, with no further due, here it is, the Hajime video. I hope you enjoy it.

Take care,


Posted: September 22nd, 2010
at 10:58pm by Marco

Tagged with , ,

Categories: The design of VGS

Comments: 5 comments

Fun: The final achievement

A long time ago I read a thread on a gamedev forum where the opening poster asked what was ‘fun’ and how was it achievable in a way that would raise the ‘addiction’ factor. I found the question to be very interesting but the debate around it, considering that was a gamedev forum, extremely poor.

Most of the people that participated in the thread could not separate their development background from their playing background. Remember the Gamer != Game Designer post? It’s pretty much the same argument but on a later stage. Why is this important or relevant? Read on…

Copying formulas

I’m betting that a huge percentage of flash game developers/designers implement features in their games because they’ve seen it in sucessful games. If it is successful it is usually named: high-scores, achievements and so on are excellent examples of successful features.

Implementing it enhances a game, for sure, but does it increase the fun and entertainment value? I bet you’ll say YEAH! but can you explain why? We are just copying formulas, not really digging why we are doing it.


Well we keep doing it… When we do a certain game genre, we are categorizing our game. Again we are copying a formula but by doing it we are giving the player an opportunity to filter what he wants to play. Don’t take me wrong, this is more than fine. After all we do want players to play what they want or that will take the fun out of the experience. Why does it take the fun out of the experience?

Understanding the factors

By copying formulas we are adding factors such has re-playability  and by categorizing we channeling that value. Both work if the game has value on its own and most don’t! It does not matter how many success formulas you include or how you categorize your game if you ultimately fail to understand why is a game fun and entertaining.

Some developers simply copy entire games and it works for them. I think they are convinced they have achieved a higher state of game design knowledge… well… I’d love to see them do something new under a different name, just to see what would the reaction of their fans be.

On the other hand, developers that understand the factors that create a great experience do wonders, they create new genres, make the gamedev theorists and journalist come up with new terms and I’m under the impression they don’t even think about it. The mob simply follows their lead.

So what are the factors?

That’s up to each one of us to find out I guess. Being a Raph Koster fan I believe that factors reside in the purest of forms, in understanding how the brain processes the experience. My personal view on it is that if you apply that basic processing to a target audience, it will work. Our talent and experience only makes it work more or less, but it will work! That’s the basis of how I design.

I bet other developers will have other ideas, but this whole post is a “think out of the box” kind of thing. What I’m trying to express is that if you don’t think in terms of your own gamer clichets. Don’t think that you like multiplayer, or that a certain game was cool because it had swords. Think on what will the reaction be to something you create. Think what is the typical player of the game you are creating. Think on how you’ll reach him or her individually. Stereotype your player, not you as a player.

Posted: February 17th, 2010
at 10:45am by Vlad

Tagged with , ,

Categories: The design of VGS

Comments: 3 comments

Mental Note #1

Hi all…

Too much talking about Bold Pixel Engine! :) Time to move on a bit… for some unrelated reason I took a look at my personal blog that I left a long time ago.

I found a “Quotes” category there and gosh the ammount of mental notes there is overwhelming, mostly on game design. Things that were written a long time ago in some of the early game design books that live in many of the older developers shelfs. Some of the things that were written contradict many of the things that aspiring developers think, sometimes reading it can be cruel… doesn’t mean it is not true.

Today I bring you Chris Crawford, like others I might write here, one of my favorites.

Complete amateurs whose only relevant skill is programming undertake to design games with no further preparation than their own experience as game players. Those who overrate their own understanding undercut their own potential for learning.

Chris Crawford @ The Art of Computer Game Design

Posted: February 12th, 2010
at 11:18am by Vlad

Tagged with ,

Categories: The design of VGS

Comments: No 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