Flick Ninjas Dev Part 2: Arbitrary Level Design with a Tile Based Engine

In Part 2 of an ongoing series leading up to release of my game Flick Ninjas in the iOS App Store, I discuss development of a tile-based engine that allows the artist to draw arbitrary levels and then import them into the game engine.

So, I'm just 5 days from submitting my game Flick Ninjas to Apple, and I'm in the thick of final testing, but I decided that I should start of series of posts relating to difficult problems I had to solve during development of my first game as I count down the days to submission.

Part 1 of this feature (admittedly, I didn't know this would be a series when I wrote it) addressed crafting a platformer that works better with a touchscreen then it would with a gamepad.  

In this post, I will review a decision I made to create a tile based engine that imported arbitrary images of levels and generated the tile-map based on that.  Right off the bat, I'll admit that this might not have been the best choice I made, as size constraints quickly reared their ugly head as I started creating Retina Display ready images.  However, the ability to quickly draw my levels and simply import them with very little modification into my game was quite a time saver.  Being an artist, WYSIWYG is an awesome perk in an engine!

I originally designed my game to use a standard tile based engine, with the intent to fit together standard tiles to construct levels based on different environments.  I designed a few levels based on this approach, and determined that these basic tiles would limit my art direction significantly.  Also, it would expose my weaknesses as an artist, as repeating tiles/textures have never been my strong suit.  I luckily had made a decision early on that I wanted to use Flash to simply draw the levels and then import them without having to have a special level editor.  Because of this approach, I already had an importer that would search for repeating tiles in a png file and construct a map out of it.  I decided to throw a simple arbitrary level design (no obviously repeating tiles) at it and see what happened.  It worked beautifully.

The next issue was to fix my collision detection and response system to allow for pixel based collisions, but I'll save that discussion for another post.

I worked with this approach for several weeks, cleaning up and polishing gameplay before really putting the content pipeline through it's paces.  I designed 5 different themes each with a corresponding level, and here is where I ran into one of my first drawbacks to this approach.  Level complexity was limited to the size of the image that the tile generator would spit out.  If I increased complexity, it wouldn't fit in a 1024x1024 image, the texture size limit for the iPhone at the time.  I was luckily able to figure out how to decrease the complexity of my levels without it being too obvious in the design of the levels, but it was still a bit disheartening.  Oh well, chalk one up to experience.

Then came Apples announcement of the iPhone 4's Retina Display.  I really loved how sharp everything looked on the device in the Apple Store, and I couldn't wait for the feature to come to the iPod Touch (I don't actually own an iPhone.  I'll explain this in a later post as well).  I filed away a feature request to myself to add support and didn't really touch it for a month or two.

When I did finally approach the problem, it took a few days to get it working properly, but since I had drawn all my levels in Flash, I could export them at double resolution without any loss in quality.  The first real problem with this was addressed by Apple. They increased the max texture size to 2048.  Because of this I could generate essentially identical images by simply doubling the resolution.  Honestly, all of these decisions coming together to make my life easier were fairly serindipitous (I being a faith-based individual, attribute this to confirmation that I should stay on the path I've been taking), but I definitely didn't complain.  After exporting a few levels I ran into another problem.  Flash CS3 would not export images large enough to encompass one of my levels.  In the end I ended up having to cut part of the level out, and keep the limitation in mind for future designs.  Once again, difficult, but definitely not the end of the world.

In the end, I ended up with what I think is a fantastic art style, and a pipeline, albeit with a few caveats, that makes content creation fairly straightforward and simple to accomplish.

That's it for this post.  Stay tuned for another feature each day, and keep your eyes open for my game Flick Ninjas to be released in mid-February.  Feel free to visit my personal development blog for more information, and to view my official gameplay trailer.

Latest Jobs


Hybrid, Cambridge, MA or Chicago, IL
Quality Assurance Lead

Bladework games

Remote (United States)
Senior Gameplay Engineer

High Fidelity, Inc.

Game Interaction Designer

Fred Rogers Productions

Hybrid (424 South 27th Street, Pittsburgh, PA, USA
Producer - Games & Websites
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more