Creating the "game world"?

[Noise]

I'm looking to make a basic game, with a top-down view like the Zelda games for Gameboy/SNES. Preferably just with Xcode and Interface Builder for now if possible.

Now, I know about moving UIImageViews and such. My main concerns are the following.

First, how do you make the game world larger than the basic 480x320? I'd like to have a fairly large game "map" that can be explored.

Next, how are collisions handled? For example, I obviously wouldn't want the player to be able to just walk through a building. I'd want them to be forced to stop when they hit the building. Would the building be in the basic background image, or would it

Finally, how would I handle alternate views? Such as the interior of a building? Basically, making the character walk through a door, then present the interior view - perhaps placed on a black background?

I'd appreciate any help with this!

[MiniRobinho]

Regarding the game world size, I've also wanted a bigger size than the actual screen size to layout everything. I think it can be done, however you can't do it through interface builder because that only allows editing within the iphone screen.

For collisions you can use CGIntersectsRect(character,building){DO SOMETHING} which will then do something when the two images "interesect" or touch essentially. And yes, if you have a background image, you'd need a separate image saved of just the building so that the game can detect where the building is.

For alternate views, you could have two views, and then using CGIntersectsRect(character,door){load second view containing building interior}

Hope that helps

[Noise]

Originally Posted by MiniRobinho

Regarding the game world size, I've also wanted a bigger size than the actual screen size to layout everything. I think it can be done, however you can't do it through interface builder because that only allows editing within the iphone screen.

For collisions you can use CGIntersectsRect(character,building){DO SOMETHING} which will then do something when the two images "interesect" or touch essentially. And yes, if you have a background image, you'd need a separate image saved of just the building so that the game can detect where the building is.

For alternate views, you could have two views, and then using CGIntersectsRect(character,door){load second view containing building interior}

Hope that helps

It actually does help quite a bit!

I was thinking CGIntersectsRect, but wasn't sure.

As far as loading the second view, I would then just set it to place the player's UIImageView at the correct coordinates for the door entrance, right?

Would I use CGIntersectsRect as the barrier for the views as well? For example, the inside of a small building. If it doesn't take up the full screen, how would I prevent the player from simply walking right "over" the walls of the interior and onto the background?

[smasher]

Professional games don't depend on what's happening on the screen to figure out what action happens next. You can get away with it in simple arcade games, and I've even suggested it for simple games in other threads, but it makes the game difficult to port to other platforms and difficult to change resolution, etc. In more complicated games you need to separate the drawing from the model.

The "model" is the computer's mental model of what's happening; you update the model each turn and then you draw what's on the screen later based on the model. So, you need to think in terms of what the computer needs to know in order to make decisions, *not* in terms of what appears on the screen.

A good way to store a map is a two-dimensional array, or an "array of arrays." You could use NSArrays, but it's easier to use C arrays. This gives you a grid in the computer's memory, with rows and columns like a spreadsheet; it's easy to check if there's a tree at x=7 and y=4 is by typing "if (myMap[7][4] == TREE)"

I'd start with a 2d array of ints, with mostly zeroes and a few ones. A zero would represent a clear area, and a one would represent a tree or wall or blocked area.

When it comes to drawing this map, I'd start by having your character stuck to the center of the screen, and move one square at a time. You'll have a grid of UIImageViews too, in a different 2d array; every time you move the character, you'll change the image in each imageView to match the one

//this code would go inside your "update" method that moves the player
//and redraws the screen

//TODO: move the character, changing playerx and playery
//TODO: this is where you'd check if myMap[newPlayerx][newPlayery]==1 before allowing the move.

//update the grid of imageViews on the screen based on the myMap array.
for (x=0;x<16;i++)
     for (y=0;y<16;i++){
          int tileNum = myMap[x+playerx][y+playery];
          UIImageView imageView =myimageViews[x][y];
          //TODO: replace with an array of images instead of "if" statements,
          //use initWithContentsOfFile, etc.
          if (whatTile==0)
               imageView.image = [UIImageNamed @"grass.png"];
          if (whatTile==1)
               imageView.image = [UIImageNamed @"tree.png"];
     }
}

Hope I didn't start over your head. If you need the code to initialize the arrays and add the imageViews to the screen I can add that too.

BTW in my model everything is measured in map squares, and I convert to pixels when drawing to the screen. So a tree is one map square wide, although it may be 16 pixels on the screen. That makes the math easier inside the model.

PS - Professional games usually use OpenGL or possibly Cocos2D instead of imageViews. I think imageViews are good for a first game / learning experience though. You can still draw about 80 moving imageViews to the screen if you'll settle for 15FPS, or about 50 items at 20 FPS.

[Noise]

Thanks a lot for the info, Smasher.

So, basically, rather than starting with a big image, I need to start with a grid, right?

With that, I'd set up the map as a grid, with each square being it's own image? Kind of like a tile? With things like buildings, would I use one larger image, or would I need to split that image into several blocks for the grid?

Is there a visual way of setting this all up, or would it all need to be done through programming? I'd prefer visual, just because I love seeing the artwork all fall into place, but if it's through coding only, that's fine as well.

What engine do you guys prefer? I was thinking for my game to just use image views, as it will be fairly simple. A basic map, with the player, and NPCs to interact with. Would that be enough to justify using OpenGL or Cocos2D? I'm planning on keeping it all 2D, with a similar view to a traditional Zelda game.

[smasher]

Originally Posted by Noise

Thanks a lot for the info, Smasher.

So, basically, rather than starting with a big image, I need to start with a grid, right?

With that, I'd set up the map as a grid, with each square being it's own image? Kind of like a tile? With things like buildings, would I use one larger image, or would I need to split that image into several blocks for the grid?

I would suggest tiles. You might have a grid of UIImageViews that is 16 tiles wide and 16 tiles tall, but your map could be 100x100 tiles or bigger if you wanted. You only show the images for the visible area though.

Is there a visual way of setting this all up, or would it all need to be done through programming? I'd prefer visual, just because I love seeing the artwork all fall into place, but if it's through coding only, that's fine as well.

I would start with having the map in code for now. You can switch to using a tile map editor (like tiled) later, once you get this working. It's possible to use Interface Builder, but I wouldn't recommend it. You can hardcode your map like this for now - a field of grass with a few trees:

int mapArray[8][8]={
{0,0,0,0,0,0,0,0},
{0,1,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,1,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,1,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0},
}

What engine do you guys prefer? I was thinking for my game to just use image views, as it will be fairly simple. A basic map, with the player, and NPCs to interact with. Would that be enough to justify using OpenGL or Cocos2D? I'm planning on keeping it all 2D, with a similar view to a traditional Zelda game.

Is this your first game? I think UIImageViews would be fine. Cocos2D would give you better performance and some extra effects, but you'd have a little more to learn. OpenGL is much harder and you have to code all of the animation, etc. yourself. They are all just different ways of drawing; you still have to write the model yourself.

[Noise]

Awesome. Thank you for your help!

This is my first game. I've built quite a few traditional apps, and I'm getting pretty decent with Obj-C, but I have zero experience with game design for it.

My plan is to start off with just a basic game world as a test to get the basic feel of simple game design. I'll use the view style that I want, so that I can move on to more advanced games in the same style later on.

How many pixels do I need to make each tile? Is there a set size that's "standard," or is it game dependent? Is there a standard size for a player character or NPC's?

[smasher]

Tiles are usually some power of two, like 16x16 or 32x32. It's more efficient to create blocks of memory that size, multiplying by powers of two is faster than multiplying by other numbers, and OpenGL requires textures to be powers of two, so you'll see them a lot.

You could also make tiles rectangular, 32x16, and make characters two tiles tall at 32x32. That's what I did.

I would definitely start with UIViews or Cocos2D. OpenGL could be intimidating, and you'll spend a lot of time doing "plumbing" not game programming.