Posted December 7th, 2009 by micah

Adventures in game engines

Part 1 – Diary of a new iPhone game
Part 2 – (you’re reading it)
Part 3 – The story, so far…

My initial vision for A Princess Tale

Here’s some of the first sketches I did when coming up with ideas for the game:

The game will be very plot-based, and the plot will be linear. Nonlinear plot-based games can get much bigger and more confusing quickly, and since this is my first game of this type, and also since it’s an iPhone game I want to keep things as simple as possible, I’ve decided on a linear plot. This basically means that the player must do something to move the plot forward, and then they must do something else, and then something else, in that order, until finally they win.

I’m going to store this in a simple state variable. When the game starts it’s 0, and all of the characters in the game will know what to say to you because the state is at 0. After talking to the troll that guards the bridge over to where the dragon is, you then need to get him a cell phone (because he’s lonely and wants to text with his girlfriend), so the state is now 1. When you go back into the village and talk to people, they’ll know that it’s time to talk about cell phones and where to obtain them in Kingdom now.

So simple linear plot. Now the game interface. I want it to be like the original Zelda game, because that game was awesome, so my plan is to make the game world split into several screens. When you move off one screen, the next screen scrolls over. Each tile is 30×32 pixels, and each screen has 16×10 tiles. So, together this makes it so each screen is 480×320 pixels big, which is the size of the iPhone screen. You move the player by touching the screen. You attack enemies by touching them, you talk to characters by touching them. Everything will be very intuitive, just touch things to do stuff.

Since drawing the map will take the entire screen, there still needs space for a Heads Up Display (HUD). This will either be at the bottom of the screen or the top of the screen, depending on where the player is. If it’s at the bottom and the player moves closer to the bottom, the HUD disappears and reappears at the top, to stay out of the way. I haven’t completely decided what the HUD will look like, but so far I’m leaning towards: A menu button, a switch weapons button (between sword or bow), a use potion button, and some hearts displaying your current health.

The Game Engine

Ok, now that that’s all settled, how do I actually do it? My last game, teh internets, I programmed in Objective-C using cocos2d-iphone for all the graphics. Cocos2d is wonderful to work with and saves hours of time and is an awesome community-driven project, but for something like the game I’m envisioning, it doesn’t include higher-level things like a tile map editor, easy ways to script objects, etc. So I began looking into other options that can save me a lot of time.

I started with GameSalad. I downloaded it, followed some of the tutorials, and was getting really impressed. I even made myself a test game with a menu system, some moving sprites, some collision detection (and if you’re interested, you can download my test game called SaladTest here). With GameSalad, it would be easy to design a huge game world, and with the simple GUI quasi-scripting of actors, it would be easy to switch from scene to scene. I could even easily make huge maps that scroll, instead of just screen-sized maps, if I so decided. I was still a bit cautious about the lack of control. How do I make my game respond to iPhone OS events like if someone is receiving a call on their phone or if there’s a low battery warning? But I figured it looked very cool, and I went ahead and bought the $99 license.

Then, while perusing the forums, I noticed a thread asking about how to save and restore state in the game, and the answer was “you can’t yet”. I looked into this more, and even wrote an email to the GameSalad people (haven’t heard back yet though) about it. But as far as I can tell, it’s impossible to save anything to file and later load it again in GameSalad. This means each time you open the game, you have to start from the beginning. Well… damn. That ruled out GameSalad.

I briefly looked into Torque 2D also. The $750 price tag made me pretty shy about it. It’s not entirely unreasonable, especially if it can speed up the game development process a lot, but it’s also quite high for an indie developer with hardly any budget. I downloaded the Torque Game Builder and played around with it a bit, but then I started thinking more about exactly how I want the game to end up, and decided to not use Torque 2D, and go back to my very first idea. Program from scratch with the help of cocos2d.

The Map Editor

The most daunting task for this game to me is making it quick, easy, and bug-free for me to edit the vast amount of content in the game. The first thing I need for that is a map editor. So I decided to program one. I want to be able to share a lot of code between the map editor and the actual game, so I decided to make the map editor an iPhone app. So I sat down and started to think out how it might work.

It’s very sloppy, I know. But here’s the gist of it: Each map will have 4 layers, GroundBottom (for dirt or grass tiles), GroundTop (for things like flowers, that can be growing out of the dirt or grass below it), Objects, and Sky. The player will exist on the Objects layer, along with all of the solid things that the player can’t walk through or that the player interacts with, such as NPCs, trees, walls, doors, etc.

From within the map editor you’ll be able to save maps, load maps, create new maps, and delete maps. You’ll also be able to switch which is the active layer, switch which is the active actor (I borrowed the term “actor” from GameSalad, it’s a sprite — each ground tile, each tree tile, each anything, is an actor). When I scribbled those notes, I also had a vague idea of how I would need to make triggers work.

A trigger will be something that does something. I’ve decided that triggers will only exist on the Objects layer. So if there’s an actor that you can talk to, then that actor is a trigger. If there’s a door that should move you to a new map when you walk into it, then that door is a trigger. If there’s an actor that’s a new sword laying on the ground, that sword is a trigger. It’s anything you can interact with, basically. In these notes, I was originally thinking each map would have 4 default triggers attached to it, which would get called when you walk off the screen in any of the 4 directions. But I have decided to change that behavior, more on that later.

Anyway, after a couple hours of coding, I ran into an obnoxious bug. I got my map editor to a pretty good start, but then I noticed that there were gaps between the tiles when displayed. Here’s a video of it that I made to show people in the cocos2d forum, to ask for a solution.

With the help of people in the forum, I finally figured it out. I didn’t exactly fix it, so much as hack in a fix, but I think it works enough for me to be satisfied. Since then, I’ve also been changing the map editor around a lot to make it more user friendly.

The big thing that I decided though was that rather than saving and loading maps, and having directional triggers on each map to point to the next map, I would just use a grid. I looked at the giant grid map from the original Zelda game for inspiration:

And with that, I decided to make the map for A Princess Tale to be a 10×10 grid of screens, making a total of up to 100 screens for the game. I haven’t yet done this, but I’m planning on making a very quick and easy way to select which screen on the grid to edit. And while I’m working on the level editor, I’ve also been designing the layout of the world on paper:

As you can see, I still have far to go. But making the map is very helpful in thinking out the story. Every section of the map needs to be there for a reason. Every place on the map above has it’s purpose, and there’s more places that I still need to design (such as the wicked forest to the west, where the witches live, and I haven’t done any design on the village yet).

In order to save me time in the long run, I’m going to plan out the entire story of the game, and draw out the entire map for it, before I start laying out the maps, in case I end up wanting to change things around later on. Here are notes I’ve taken for the tasks that the player must complete:

And now, in its second post, this development blog has finally caught up with the development. The next couple of posts will probably be more about the design of the game, and the graphics and sound, than the development. It just seems to make the most sense to me to finish designing this game before I get my hands too deep in code. So stay tuned.

Part 1 – Diary of a new iPhone game
Part 2 – (you’re reading it)
Part 3 – The story, so far…

Comments (2)

Have something to add?

Name: (required)

Email Address: (will not be published) (required)

Website:

Comments: