> | | | | | | | | | > Tile-Based Games Must Animate Smoothly!

Tile-Based Games Must Animate Smoothly!

Posted on Monday, July 23, 2012 | 7 Comments

One of the main reasons for tile-based games is to save on processing power and memory.  Drawing one giant image for the map is a lot more taxing than a bunch of smaller images, a lot of which are duplicates.  Nowadays, it's not really necessary to use this technique, but it does replicate the feel of older games and that is something that I'm trying to accomplish.  Also, because tile-based games save on memory and processing power, they also animate more smoothly (higher frame rate), which is not true of the past two versions of my project.

Generally, the acceptable average frame rate for a game is thirty frames per second.  I think this is too low and that it should be sixty frames per second or possibly more, because games with taxing graphics will not always display a steady frame rate and once you dip below thirty it becomes very noticeable.  Actually, I can notice it at thirty frames per second too, but I don't think that's common for human beings.  Anyway, games at higher frame rates animate more smoothly as well, which is something that always looks appealing to a gamer.

Bumping up the frame rate of the game is actually really easy to do with Flixel.  In the FlashDevelop window, I have a file named Main.as which creates the game screen.  It also allows you to input a parameter for the game's frame rate and the flash player's frame rate.  I changed both of them to "60" and suddenly the game felt a lot more fluid.  The player's movement still didn't feel quite right, but I was not going to worry about that yet.  Here's the line of code that sets the frame rate:

Flash Actionscript 3 Flixel code to set frame rate.

After bumping up the frame rate, I noticed that every so often it would skip a frame or two, which is simply unacceptable, especially in an action-oriented game.  I searched the internet for similar issues and came across a fix for the solution here.  Apparently there is a small logical error in the code that checks for "greater than or equal to" when it should just check for "greater than".  I usually don't expect that things will work when I find them through a search engine, but this fix actually did work!

One of the other big things I did for this upcoming release was make a new player sprite.  The old one was really starting to look ugly and the main character of my game is supposed to be a robot anyway.  I already have a sprite for Otto from my capstone project, but the problem is that when I was working on it I was using 32x32-sized tiles and the Flixel version is using 16x16-sized tiles.  As such, I was forced to make a new sprite.

Now, I'm not much of an artist when it comes to drawing.  Unfortunately, without some other talented person to take care of the graphics for me, I'm stuck doing it myself.  I have considered the possibility of hiring somebody or convincing somebody to do a collaboration with me, but for now I just want some placeholder graphics that I can use while I work on making the game.  I like my placeholder graphics to look at least somewhat game-like, otherwise it's really easy to lose motivation.  Who cares about a bunch of single-color blocks?  If your graphics have even a little bit of life to them, it will keep you more interested in working.

Otto's current sprite is based largely on the one used in my capstone project, but does look fairly different.  Unlike the previous player sprite that was only one tile tall, Otto is now two tiles tall.  This looks more natural for a game like this and also allows me to do different things gameplay-wise.  I also decided to animate the player sprite, because it's something that I'll need to be doing for every enemy in the game and probably some objects as well and I may as well see how it's done.  I tried to make it look like Otto's wheels spin when he moves left or right.

Fortunately, the FlxSprite has a method that allows you to add different animations to it.  The method is "addAnimation" and it lets you specify a name and frame rate for the animation.  You also need to include an array of the frames used for the animation.  My code looks like this:

Actionscript 3 Flixel FlxSprite code to add animations.

So, for the first line, I'm creating an animation called "move_left" that uses frames 0 through 3 of my player graphic and it animates at 20 frames per second.  When I move left, I simply tell the player sprite to play that animation, like so:

Actionscript 3 Flixel FlxSprite code to play animations.

As you can see, it's actually fairly simple to do thanks to Flixel.  There is a logical error that I've come across, however, and I've only been able to partially fix it without diving into the Flixel code itself.  Basically, every time you start moving the animation always starts at the same frame, but it is supposed to start from the frame it last displayed.  It's a small bug though and I don't really think it warrants fixing since it has no effect on gameplay.

Since I am trying to make a game similar to Metroid, I felt that Otto needed to have the ability to shrink and unshrink, similar to the morph ball of Samus Aran.  I certainly don't intend to just copy the game (nor do I think I'd be able to!), but I like this gameplay element for many reasons and I think that Otto can do some cool things with it that haven't yet been seen in a game.  I actually found it sort of confusing to implement this at first, but my solution seems to work just fine so I am assuming that's how it's done.

When the player presses the down arrow, if Otto is not currently small then he will shrink.  Shrinking Otto means changing the attributes of the FlxSprite, particularly the "height" and "y" values.  The "y" value is always the top-most pixel of the FlxSprite, so in order to shrink the player you need to increase "y" by the height of one tile.  You also need to update the image being displayed for the player.  I probably could have done this with just one sprite sheet, but my solution is to just call the "loadGraphic" method again, shown here:

Actionscript 3 code to adjust Otto's height while shrinking.

Don't forget to also change the "height" attribute and the offset again.  Since the player has now shrunk, his height is only 14.  I use 14 instead of 16 because I want the player to have a little wiggle room when platforming.  A height of 14 combined with the offset allows the FlxSprite to overlap two pixels of tile if jumping into a tile.  My "checkFacing()" function is custom and I simply use it to update the player's current frame based on the direction he is facing.  Since my two graphics are set up exactly the same, changing the frame (each direction has 4 frames of animation) works the same.

My last task for this release was to make another new map.  Last time I tested horizontal movement, so this time I decided to make a completely vertical map.  Like the previous map, I used this one to also test the jumping limits of the player as well as see what kind of gameplay elements I could create with the tiles and the new shrink/unshrink ability.  You can see this version of the game here.

I eventually decided that I didn't like the current feel of the player's movement, so I ended up changing it.  However, you'll have to wait until my next post to hear about it.  Oh, and I guess play it as well, since I always link the version of the game that I'm talking about in my posts.  My friends and I all think that the player's new movement is perfect or close to it, so you're in for a treat next post!

See you again and thanks for reading!


  1. This is over my head, but its pretty cool to read how this gets made.

  2. THx bro really helped alot

  3. Will surely use it for myself!

  4. Pitty I'm going to develop a game in Java for Android or this would have saved some time!

    1. You know, I was actually going to make Android games/apps at one point, but I got fed up with the SDK and scrapped the idea. Part of my reasoning for doing so is the fact that Android supports Flash anyway, so I could make a Flash game and still reach the Android audience. If you use an iPhone... well, your loss!

      Anyway, good luck with your game!


Powered by Blogger.