> | | | | | | | | | > The Refined Zoo

The Refined Zoo

Posted on Tuesday, July 24, 2012 | 5 Comments

Ah, I almost didn't see you there, good reader!  Welcome, welcome!  Please, come in and have a gander at our grand refined zoo.  Here, you will find only the most esteemed of wildlife, including our Gentleman Gorillas and Sir Snow Leopards.  If you're lucky, you may even catch a glimpse of the rare Master Marmoset!  Oh dear reader, join us at our glorious refined zoo, won't you?

Otto with top-hat and monocle.
Like a sir.
You may be asking yourself just what the hell I'm talking about!  Well, I don't blame you.  It's a pretty weird title post.  The title simply reflects two of the main things I'll discuss today.

My main focus after the progress covered in last post was to refine the player's movement.  All tile-based games, regardless of genre, have very fluid and responsive movement.  I'm not sure really how else to describe it!  When you play a game like this, the player's movement just feels right, like it was meant for that game.  The mechanics of the player's movement also need to be balanced for the screen size and general object size.  In my game, a normal jump takes you two tiles high.  There are also jumps that look too long to make, but if you are skilled you can cross the gap!  It's things like this that make a game fun.  One of my favorite things about Super Metroid was being able to get items you weren't technically "supposed" to be able to get yet by doing things that required skill.

Anyway, it took a lot of testing, trial, and error to get the movement velocities to feel right for my game.  I considered going about it a mathematical way at one point (player should move x tiles in y frames), but quickly decided it would be much easier just to test different values.  The player FlxSprite has a few attributes that I focused on for this task, "maxVelocity.x", "maxVelocity.y", and "acceleration.y".  There is also a drag variable and acceleration for x, but I didn't mess with them because they already felt fine.

The original player movement lets you jump way too high and for much too long, so that was the first thing I changed.  It also all felt too slow, so I bumped all the numbers up quite a bit.  Finding the right balance between the acceleration and maximum velocity for "y" is key for jumping and falling.  After that, it's just a matter of increasing the maximum velocity of "x" to match.  I actually didn't have to increase the maximum velocity of "x" by very much at all for it to feel right.

Another thing to consider when playing around with these variables is possible power-ups and upgrades in the game.  For instance, I will probably incorporate some sort of item in the game that allows Otto to jump higher and something else that increases his speed.  In this case, it's wise not to make the player movement's too fast-paced at the start.  Just focus on making something that feels balanced.

Once I settled on a set of values that felt right, I sent it to my best friend for him to test.  He is also a very avid gamer who grew up playing the same types of games as me, so I really value his opinion.  Getting the opinions of others is always important for game testing.  Even being as experienced with games as I am, it's always good to have an outside perspective.

My friend thought that the movement was very close to being perfect.  However, he did have some issues in the version I sent him with not being able to make a certain jump.  As a result, I bumped the maximum "x" velocity up another notch and this is also when I implemented a decreased vertical aspect on the player's bounding box -- the top two pixels of Otto's sprite will overlap any tile he jumps into.  This is actually pretty typical behavior in games like this.

Player movement after tweaking it based on my friend's input now feels absolutely right.  I'm not sure if it will be changed again from this point on, but I wouldn't count on it!  If I do change anything about it, it will be probably be something minor.  You'll get to see for yourself what you think of it at the end of this post!

I also fixed a bug in this release.  If the player is currently shrunk, the bug allows them to expand even if there is a tile directly above them.  The result is that the top half of the player overlaps a tile that should be impassable.  My solution was to check the tile above to see if there would be an overlap before I ran the "expand" code.  This is done with a method called "overlapsAt()", which checks a certain point against an object, so I simply check the player's position as if it were 1 tile's worth of pixels above where it currently is.  If there's a collision, disallow the expansion.  Otherwise, allow it as normal.  The code for it looks like this:

Flash Actionscript 3 code to disallow expansion.

My code simply does nothing if there is a collision, aside from sending a trace statement to the output window to let me know that it worked!

The last thing I wanted to do for this release was to make a new map, but not just some small-scale thing used for a quick test.  This time around, I wanted to build what I like to call a zoo!  I got the idea for a zoo from a game called Duke Nukem 3D.  I've always been into game design and map/level design especially.  When I was younger around the time I was into Duke Nukem 3D, I built maps for it.  During that time, I came across a series of maps called "Zoo #" that was basically a testing grounds for all the enemies in the game as well as game mechanics, such as doors, switches, sector effects, lights, and so on.  You'd basically have one main room and then a bunch of rooms connected to it that each had a different type of thing like that within.

So, that's really what I wanted to accomplish with my own Zoo map.  It's currently still a work in progress, since there are still many things in the game I want to implement before I can put them in the map.  My latest version, which I don't want to show you just yet, has 45° and 22.5° slopes implemented in it, but I eventually want to get water/liquid environments, lava, moveable blocks, destroyable blocks, and "false" blocks, just to name a few.  For now, though, I just tried to test out what kinds of jumps the player would or wouldn't be able to make with the new tweaked movement velocities.

Keep in mind, the particular set of jumps in this version are a bit difficult, because I am trying to test the limits of Otto's movement.  You wouldn't generally see these jumps in the main parts of the game, but probably in some secret area that has a hard-to-reach item or something like that.  Anyway, here is a link to this post's version.  Test out the movement and let me know what you think of it in the comments!

Thanks for reading!


  1. it rly looks like like a sir meme :D

  2. "It's very interesting post. I'm impressed with the whole blog!"

  3. Hmmm interesting indeed!;)

  4. A map with a hat on it. Well played sir. Well played!


Powered by Blogger.