> | | | | | | | | | > Becoming Familiar with Flixel

Becoming Familiar with Flixel

Posted on Sunday, July 15, 2012 | 2 Comments

Welcome back, dear reader!  I hope you're ready for another tale about the plight of the independent video game developer, because I'm going to jump right into it.

Before I began to work on the Flixel-based Otto's Odyssey, I had to re-familiarize myself with Flixel.  I had used it before but not long enough for it to really sink in.  Fortunately, there are many tutorials floating around the internet and a few linked directly from the Flixel homepage.  The tutorial I decided to work with can be found here, although my code now looks quite different.  I had looked at a couple other tutorials if I remember correctly, but the one linked is the main one.  If you are curious about the others, they are really easy to find if you just go to the Flixel homepage (here).  I think I also found some on Google.

Anyway, what I really find useful when starting a project like this are tutorials, documentation, and search engines.  Tutorials can help you get started or show you how to program a particular thing into your game.  The documentation in Flixel is really nice; I haven't come across anything yet that was missing a description.  Documentation is helpful because it allows you to understand what all the individual components in the library are capable of.  This is basically my main tool when there is no tutorial or any help from the search engines, because in this situation I am essentially coding entirely from scratch.  Search engines are helpful because you can oftentimes find forums where somebody has posted a question similar to your issue and has received help.

It's rewarding to figure a challenging programming issue out completely on your own, but as an independent developer it's key to be able to save time where you can, because I'm also making the music, sound effects, art, and story for this game.  Actually, I have been a little lucky in that regard because I've found a good resource for tile-based game artwork that is in the public domain or free to use in commercial games.  I do insist on crafting the music and sound effects, however, because I have two software programs that are perfect for the job and I played trombone (quite well) for about ten years so I have a strong love and appreciation for music.

Once I had the tutorial completed, I started changing the code around and slowly turned it into what it is right now.  The first thing I did was figure out what size I wanted my tiles to be and then I picked a screen size I thought would work well.  I took bits of code out that I didn't want, like the coins from the tutorial, and altered other bits of code that I wanted to keep.  One of my first code alterations was when I tried to figure out how to have the player sprite display an image instead of being drawn by the game on the fly.  It was actually pretty easy; I just opened up Photoshop and made a small 16x16 green guy that looked like a Christmas tree or something.  Then, I opened up the documentation to see what sort of things the FlxSprite class could do.  As it turns out, the FlxSprite class has a built-in method called "loadGraphic" that lets you specify an image.  It also lets you specify whether or not it should be animated, but I will elaborate more on the animation later because I didn't touch it at first.  After that, I was done.  The image of the green guy loaded up perfectly and everything seemed to work fine.

I want to try to re-tell everything chronologically, but I'm afraid I just don't remember every single detail.  I'm pretty sure I messed around with the x and y velocities of the player once I got the image working.  The image was bigger than the box that was being drawn on the fly so I had to change the movement speeds of the player to match it.  The last step in this part of the process, before I uploaded the first test version of the game to my portfolio, was to get the game to display images for the map. 

Fortunately, the way the tutorial is laid out is exactly how I wanted -- in tile format!  Tile-based games use arrays to store the map data and then use the array to populate a "map" object with images to generate the map.  Each bit of data in the array represents one tile on the map.  These types of games were commonplace back in the NES and SNES eras because the technique saves on memory and processing time.  In Flixel, there is an object called a FlxTilemap that does exactly what I want and I will tell you all about it...

...next time!  See you soon.


  1. I really like your writing style!
    As a ex - game programmer myself, I find thise more than interesting to see your look on things and how you approach them.

    Keep it up!

    1. Thanks for the kind words. It really means a lot to me!


Powered by Blogger.