The math behind platform games

by Niels Brouwers 21. June 2012 06:22

I just ran through a couple of well-known platform-games (mostly 8 bit classics) to find out about their ratios in terms of the differents sizes involved. I measured a couple of things, most importantly: the size of the main character and the size of the screen.

I only checked platformers that were well received with the general public (ranging from Super Mario Brothers to Super MeatBoy) or that I particularly liked and remembered. The results are nothing spectacular but a couple of interesting properties did come up:

1. The main character is usually contained within a square. the size of 51x51 comes up a lot (I scaled everything to 1024x768 IPad resolution to normalize everything), it seems to be the sweet spot size for a character at that resolution.

2. In percentages, we can say that the character ranges between 3% upto 7% of the screen width (these are the minimum and maximum values), with an average of 5%.

3. The height of the screen varied the most, ranging from 56% to 75% of the width of the screen with an average of 66%. The height seemed irrelevant, and is probably mostly determined by the given screensize of the particular device.

So what does that all mean? Let's say you are developing an 8bit styled platformer for the new IPad with 2048x1536 resolution. Your character should then measure 102x102 pixels and the height of your game should minimally be 860 pixels (that leaves a LOT of room for virtual buttons, menu's, or different resolution support for other devices). Ideally the height would be 1013 pixels (average). Personally I would aim for a full-screen game but a little more than half of the screen has been shown to be sufficient as well.

So there, finally a useful way to apply your basic math skills and learn something about the ingredients of a good platform game as well!


Games | Indie Games | XBLIG

Dream Build Play 2012

by Niels Brouwers 12. June 2012 18:01

After my personal debacle with my 2011 DBP entry (when I finally finished one level filled with enemies it turned out to be dead-slow on the XBOX itself - it was too late to change so I submitted what I had) I had to find the time, energy and spirit to re-do everything and this time, do it right.

And I did, I now have a clean 60FPS running multi-directional full screen parallax scrolling platform game on my XBOX 360! And although, game-wise, it still needs a lot of balancing and a story-arc to fleshen out the characters and all that stuff, I am pretty happy with the result so far! Well in time before the deadline, I submitted the Carter Jones Adventures for Dream Build Play 2012 (thank you Microsoft for sending me my password which I, conveniently, forgot).

So, I learned a lot in one year of time about what is important in developing games: testing, testing, testing (yeah, I already knew that but you know, priorities....). Also, don't worry about the lack of updates here recently, I was developing something that will generate a lot more updates as soon as I can fully use it!

My plan is to release the game on the XBOX Live Indie Games (XBLIG) channel somewhere in Q3 2012. Here's a bunch of screenshots from the game that I submitted. For the Dream Build Play submission I kind of cheated with the movie, I re-used the one I send last year. Just don't tell anyone that, no-one will know and's about the games not the movies, right?

Productivity and stuff...

by Niels Brouwers 6. March 2012 19:00

When you are working at daytime on a 'normal' job and developing games in the evening it is sometimes difficult to get some productivity going on when you get back home from your day-job. Last week I was struck by some virus, causing headaches that started in the afternoon and had me going to bed early to try and recover more quickly. So I got nothing done at all in the evenings! Luckily this weekend things turned around, the illness has nearly gone away completely now and my energy levels are filling up back to normal. Being sick sucks...

Still, I did get some stuf done. I managed to work out some animation stuff (I am trying to build a simple editor using bones), it should enable me to do animations while on the go and I also did some level editing. I actually did some play-testing on games from other people as well, I like checking out what others are working on - it is one of the cool things about XNA / XBLIG development. Too bad many developers seem to be abandoning ship, even I am looking around at the alternatives. Ios, unity 3d, playstation suite - there is plenty to choose from! But first I shall finish the Carter Jones Adventures on XBLIG!

I am hoping to do some more drawing an finishing of stuff on the first level this week (especially enemy explosions need some work right now!).

Different cousin, different dog!

The year of the dragon

by Niels Brouwers 30. January 2012 06:36

'The year of the dragon'. Say that out loud a couple of times, it just sounds like a great (sub)title for a game or movie or something like that! I like dragons, never met one though, but I like them. Unfortunately I am a tiger according to chinese astrology and the tiger and the dragon....well...they don't seem to get along very well. I don't know if or how this will influence my plans for releasing the Carter Jones adventures this year, but I really want to get the game out there so I am putting quite a lot of effort into it!

In my next post I will get into some animation updates I have been doing / will be doing over the couple of days. Should be fun, animating anything is usually a lot of work: for each movement of a baddy in the game all the individual frames need to be drawn and although I try to cut corners here and there (using procedural animation / rendering stuff in 3D) it usually works out best if I drawn the core animations by hand.

I did make good progress last weeks. I refactored the entire background collission code which is now pretty much generalised and working great, to prove it worked I used the routines on the critter baddy and so refactored that code as well. In the process I managed to stumble upon a rare bug and fixed that as well.


Happy chinese new year!

Rewriting code: tile-player collision code

by Niels Brouwers 16. January 2012 04:19

A lot of time on the Carter Jones Adventures game is spent on rewriting pieces of code. Visually you probably wouldn't notice any difference if I would show the game before or after a rewrite but in terms of performance, memory leaks, bugs and maintenance of the code there can be a huge difference.

The Carter Jones Adventures is a full-directional sidescrolling game, this means that the player can roam around freely depending on how I layout the level and where I place the platforms. I do the laying out of the levels in my custom level-editor (there are some screenshots of that in previous posts). A level is built up out of graphics that are packed together in one or more large images, by copying tiles out of the larger image into the level, a level is constructed.

Tiles are 32x32 pixels in my game. And previously I defined a heightvalue ranging from 0 to 32 for each tile. This allowed for having a unique height value for each position. Height locations between adjacent tiles were extrapolated. This system of 32 different heights and extrapolating the heights between tiles was causing some problems: occasionally the player could jump 'between' tiles and get stuck on a platform for example.

So, today I set out to rewrite that code. The new approach would define a 'rectangle' of outer tiles that represent the player. These tiles are investigated, they can be either solid or fallthrough and the new algorithm detects where the solid tiles are (if any). Depending on the current state (e.g. walking to the right) and the measured rectangle (e.g. solid tiles under the player, fallthrough on the right,top and left) I can now determine the possible actions such as moving to the right. I can now use this algorithm everywhere in each object class, not just the player's (using exactly the same algorithm from several states is one of the basics of programming - which I did not obey: due to the explorative nature of the code I copied it over instead of generalizing). Anyway, the occasional errors are now gone, the code is much cleaner and therefore much easier to read and I will use this code in all future objects thus preventing myself of creating new errors. All in all it was a sunday morning well spent!


Visually representing the rectangle of tiles around the player helped a lot with developing this piece of code. The FPS and milliseconds of time spent in drawing (D) and game-loop updates (U) are always displayed since Dream Build Play 2011 happened.