Levels

Posted on June 23, 2010

Let’s imagine that you, being the entrepreneurial indie iPhone game developer you are, are making one of those games with multiple levels; maybe old school, but at least easy enough for you to make a few levels, sell your game, then add more levels if sales permit. You start programming and after a few quick prototypes you have your little man running on the screen, bullets flying, dumb monsters chasing him. Since you have embraced the rapid prototyping method, and since you are having fun, you keep adding all kinds of stuff: flying quesadillas, cannibalistic herbivorous plants, trash cans full of cats (there need to be cats). For each new item you add to your test level, you write some code that more or less looks like this:

struct CannibalisticHerbivorousPlant
{
    CannibalisticHerbivorousPlant()
        : position(0,0)
        , velocity(0,0)
        , hunger(HungerType::Atrocious)
    {}
    Vector2D position;
    Vector2D velocity;
    HungerType::Enum hunger;
};

CannibalisticHerbivorousPlant cannHerbPlants[MAX_PLANTS];

cannHerbPlants[0].position = Vector2D(10, 13);
cannHerbPlants[1].position = Vector2D(-5, 0);
cannHerbPlants[2].position = Vector2D(13, 0);
...

I know, that doesn’t look like anything I would ever code myself, but we are talking about you after all, and you have to recognize that when you are in rapid prototyping mode, you are pretty sloppy.

Your development cycle at this point is something like this:

  1. Code furiously, adding the functionality for the new items or monsters, then their position and other state in your test level.
  2. Compile. Go get coffee, the sloppy code is getting kind of big.
  3. Run the app. Find that you put a plant in mid-air. Although you archive the idea for a future feature, you decide right now it just looks ridiculous.
  4. Modify the position in your code.
  5. Recompile. Go get another coffee.

After a few dozen items, and some hundreds of modifications, your hands are shaking all over the keyboard, and you swear your IDE is spawning duplicate windows like Gauntlet ghosts. Time to take an extra shot, and think about your tools.

Unsolicited Advice #1: Spend Time on Tools

So the code is getting messy by the minute, and this is just the test level! In the long run you are going to need something that loads the different levels, and saves player progress. You have heard of this technique of just dumping your memory into a binary file for a quick load/save, so you do that. You ran your game once more, save the initial contents of memory into a file, then proceed to get rid of all the code that initialized your test level, and replace it with a nice simple call to your new load function. It works. Purrffect.

But wait, there is an upside down quesadilla just flying by! How did you managed to miss that? So you look at the hex dump of your level file and you wonder… is that 63A0 the orientation of the quesadilla? Or the grow rate of your zombie peppercorn?

Obviously, you need a better way to do this. You are sold on this prototype and want to go full steam ahead! What you need is a level editor to create and edit these files, one with a user-friendly interface. Even better if is one of those fancy GUI apps where you drag stuff around. That way there will be no more guessing, no more floating plants, no more quesadillas flying out of formation! It will increase the speed of your development cycle tenfold! Once it is done. And gosh, that sounds like a lot of extra work. Just thinking about it you don’t feel so agile anymore. So you prepare for the hardship hoping you can ship in a couple years if you don’t get fed up with the damn editor first. Well, I have something to tell you:

Unsolicited Advice #2: Don’t Get Stuck!

You are blocked. You have looked into doing an application with windows and stuff, and all that Model-View-Controller, event queue, menu managing crap weights like a tombstone on your game’s back. You need to look for alternatives. What do you need, really? An application with a GUI, and a file in your specific memory format at the end. Maybe you can use an open source editor and write an exporter for your format? Or write a command line tool that converts their format into yours?

So you keep thinking about that while you go to your daytime job where you maybe create animated Flash intros with no mute buttons, another one of those stupid drag-n-drop JavaScript shopping carts, and a website or two with a backend database full of nicknacks that somebody expects to sell. You come back home still wondering how to make this GUI where you drag-n-drop your graphics, and somehow saves all that data without too much effort. You decide to go to the coffee shop, iPad under your arm, see if you get inspired by the barista of the day. Would not it be wonderful if you could run your editor right there in the coffee shop too? In your iPad?

If it was me, I sure would use all those nice tools available out there that I am used to work with. Since we are talking about you, maybe you use different tools. But, just for the sake of it, let’s imagine you are like me. You start thinking of creating a “proper” Mac or Windows application, then you change your mind and change it into an iPad one, then you realize you will spend more time messing with code that has nothing to do with your levels than anything else. You change it into a website, with a MySQL or PostgreSQL database, and PHP scripts. But finally you go for the fastest solution: 200 lines of JavaScript, the browser’s SQLite database, a single PHP web service to export the files. A few hours later you have a working editor.

And that’s kind of the point: use whatever you think you can pull off faster. Use the tools you know best, or the ones that others have created before you, and concentrate only on your custom parts. Don’t get stuck on doing things a certain way just because that’s how everybody else with a multimillion dollar budget is doing it. You are an indie! Being small and being able to adapt to changes is your strength! You can change your code really fast, change your tools, change your goals. And at this point, almost anything is valid as long as you can continue concentrating in making your game.

Unsolicited Advice #3:
Faster Development != Faster Coding

Is sunny again. You are sitting in the coffee shop showing the barista of the day your fancy editor running in Safari, having fun placing quesadillas in the sky. “Cool! Can I play it now?” she asks. Mmmm… let’s look at your development cycle again:

  1. You let the barista of the day change the quesadilla’s formation in your editor. You export the level.
  2. You pull out your MacBook from the bag, start XCode, replace the level file. The barista of the day goes attend another client.
  3. You compile your app while you sip your coffee nervously. You hear giggling coming from the far side of the counter.
  4. After what seems like ages the game finally loads. You jump off your chair, iPhone in hand, to show it to her. She gives you the “who are you?” look, then continues talking with the other guy.

Wait a moment! That doesn’t seem to be any faster than before! OK, but at least you don’t have any upside down quesadillas, that would have been embarrassing. But how do we make this faster? Maybe loading the level file on the fly? Haven’t you seen some video recently of a guy saying loading content from the web will make your designers wet themselves?

So you modify your load function so it loads from a URL instead of from a local file, adding #ifdefs all over the place to make sure that only runs on your Debug build. Let’s rewind:

  1. You let the barista of the day change the quesadilla’s formation in your editor. Is that a… bunny head? Whatever. She clicks Save and the level is saved in the server.
  2. You pull out your iPhone and start the game. She squeals with delight when the quesadillas fly by. Ooops. One of them hit a house.
  3. She goes back to the editor giggling. Some guy leaves cause he was tired of waiting.

Now we are talking. That kind of development cycle will let you tweak your levels to your hearts content! You will be so productive this will be done in like no time at all! Now, if you could only stop getting distracted by the barista of the day… seems she wants more bunnies. Maybe killer bunnies. Back to coding!

3 Responses

  1. Pingback: Rizer Games

  2. Pingback: iDevBlogADay « Retro Dreamer Blog

  3. Pingback: A beginners guide to iPhone game development | Bytesize Adventures

Leave a Reply

Your email address will not be published. Required fields are marked *

six + 13 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.