How to games like the below:
{"name":"img.php","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/4\/449218d8066452ffd7bdc35bffabd454.png","w":320,"h":240,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/4\/449218d8066452ffd7bdc35bffabd454"}

handle collision?

My thought was that objects (but not characters) are bound to the grid with a passable/not passable flag. These games, like this one, often simulate depth. If you look at the 2 people standing by the buildings you can see their heads are "on" the building. How do they handle this? Do you just give characters a collision rectangle around their feet and do a BB collision check with their feet rectangle against actual grid squares that these non passable objects are on? Then draw non character objects first, then characters so they are drawn overlapping these objects? I'm just thinking there is a standard way of making a game like the above and I'm curious of what it is.

From what I've played of games like that, I doubt they even do bounding box collision, but just don't allow movement at all into such tiles.

As to the drawing, imagine that he screen is horizontal and you are at the bottom (front). Once you've drawn your background tiles, draw any objects from the back first.

The above game doesn't seem to move characters from tile to tile. It seems to have free movement, so some sort of checking would need to be done to see if a character can move on a tile? If it's free movement and doesn't use BB collision, how else would you do that?

Uh, what exactly is the problem? Throw a bounding box that only partially covers the sprite (like around the feet) and go to town, sorting sprites by depth before you draw them?

There is no problem, I was just curious on how these games handle collision.

Depth being the top of the sprite or the BB of the sprite, or another given variable about the sprite?

In this game you can walk "behind" the top of the building giving it more of a "depth".

Am I right to assume the building is bound to the map grid and made up of smaller squares. If so do you BB each of those squares or do you make a big BB around the entire building.

I'm just curious on how these things are done, and how others would do them.

It can be done like this:

for (int ty=0; ty<TILESY; ty++)
{
for (int tx=0; tx<TILESX; tx++)
{
  int x = tx*TILESIZE;
  int y = ty*TILESIZE;
  
  if (abs(charx-x)<=BBOX_W/2 && abs(chary-y)<=BBOX_H/2 && !Tiles[tx][ty]->Passable)
  {
    StopMovement();
  }
}
}

It should work fine, I remember doing something like this in one of my games. Of course it could be wrong, I didn't test it and I am a bit tired. Of course it would vary depending on the pivot point of your tiles, so you'd have to adjust a few things.

EDIT: Not entirely sure if it's even on-topic... need more sleep.

You just make certain tiles unwalkable, and make certain tiles always overlap NPCs; yes, you cheat. Assuming the base of your buildings are wide enough no one will ever notice.

So if you are doing free movement of characters (they aren't tied to any tile), do you do BB collision between the characters BB and actual tile areas?

I would think after you place your building tiles down, making 1 big rect the BB on that building would speed things up, since now you have 1 check (player BB vs building BB) as opposed to the player BB vs each tile the building is made up of. Does that seem logical or would it not make a difference really?

With actual tile areas. It's really not as slow as you might think, since at most you need to check four tiles for walkability (assuming the player's bounding box is smaller than one tile), which cuts down the time you need to spend drastically.

You may look at AGDN on the tutorials, there is nice tutorial where he makes engine like that you posted screenie. There's some sort of free movement.

A few boxes are enough.

{"name":"590582","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/5\/6576b097f2a239ecbe1e2755e0492529.png","w":320,"h":240,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/5\/6576b097f2a239ecbe1e2755e0492529"}

I am working on the somewhat of the same thing. What I am trying to do is sort of like what Paul whoknows posted. I have 6 tile layers: 3 ground (below sprites grass, dirt, etc), 2 sky (above sprites tree branches, bridges) and 1 collision.

The collision layer is invisible in the game but not in the editor. I have a seperate tile sheet with different shapes and sizes: boxes, rectangles, circles all colored yellow. They are drawn onto the map just like an other tile but in the collision layer.

I have not implemented the collision yet because I have not learned about pixel perfect collision only bounding boxes plus I haven't made the game I have only made the editor. The collision tile layer is updated and moved just like the other layers. Instead of drawing it to the screen I am going to draw it to a seperate bitmap and check collison from there.

See, there are many people working on similar projects. Anyways, the result is half an engine instead of a complete game. I recommend you to fuse to a single developer team. That is what I think will lead you you to success. Btw, I love pixelling 2d tiles. In case there will be a group of at least three programmers (and thus a real chance to get such a game finished), I`d love to help out.

My tile engine works with collision detection.

Every tile has a flag "walkable". If it's false the player can't step on it. I have some sort of a movement queue implemented, so it only checks the tile you would be walking over next. And yes, the player doesn't "jump" from tile to tile, he really "walks". With animation and everything. I can share the code and/or a small techdemo if anyone cares.

@Micah: Two people are slower than one person. Three people are slower than two people. At least when it comes to conception and planning, which is the foundation of making a game. I'd rather have half an engine or a poor game than nothing at all.
Obvious exception is when you really know the people you work with. Personally. And when you meet them frequently.

I've played around with these sorts of things plenty a long time ago, and I found the simplest method was to have the map be just a grid of walkable/non-walkable tiles as you have stated, and the character represented by x,y coordinates rather than a bounding box. When moving, just do something like this:

  if( key[KEY_UP] )
  {
    if( is_free(x, y - MOVE_SPEED )
    {
      do_animation();
      y -= MOVE_SPEED;
    }
  }

  do other keys here.

Where is_free(x, y) checks if the position is not in contact with a non-walkable tile or some sort of solid object(such as an NPC). If you want the character to move over full tiles rather than just a speed(or, "free movement" as someone called it), just use newx and newy variables and interpolate rather than changing the coordinates right away.

And for handling depth, when the map is loaded, you should assign each tile a depth. depth = -(y); works very well. Movable objects should, of course, update their depth each time they are moved, and when drawing, the array needs to be sorted.

Most of what I have said is probably stuff you already knew, but it reaffirms your thoughts that they can work rather well. I've had good experiences with them, at least.

My two cents. Don't move your character and then check for collision, if collided then move them back. That can get buggy.

//Not good method
if(key[KEY_RIGHT]) {
  player.x++;
  if(collided(player.x,player.y))
    player.x--;
}

Rather, check for the collision first, and permit passage if there's no collision.

if(key[KEY_RIGHT]) {
  if(collided(player.x+1,player.y)
    player.x++;
}

Of course, working in a group is different from working alone. It seems that people do not understand that 15 minutes of gameplay can't be called a game. On the inet everyone is a pro and working on his big deal, but in fact you`re not getting more than a crappy tileengine, which itself makes half an engine.

When it comes down to splitting tasks you could supply even a team of ten hobbyist developers: Webdesign and Webmastering, Engine ( 2 programmers ), Scripting, Storywriting, Music, Music Handling, Graphics ( Ingame, GUI )...
If that is not enough let one programmer go through the code and clean it.

Engine writing should be modular, so you can split tasks again. You see: if programmer a let`s say is going to write on the rendering routines where programmer b works on the ai, there is no need for knowing each other personally. Often every programmer wants to do everything, so this will lead to chaos. But that is not my idea's weakness...

Ok, let's try it. Open a "new team project" thread and I'm in. I can supply working code for drawing routines and a tile engine. Furthermore I have several great game ideas, some really innovative stuff. I'm sure we'll find another programmer, then you do the graphics. Musicians and webmasters should be easy to find, too.
Oh, wait.. isn't it Monday today?

About the "Engine writing should be modular":
It SHOULD be modular but it isn't. A good game engine is built bottom-up. GFX/Sound/Input layer, on top of that a tile engine, on top of that basic game logic like collision detection, on top of that maybe a scripting engine utilizing the lower-level functions and on top of that the high-level logic. Notice the many "on top of that"s? You gotta know the entire existing code base if you want to work on a new layer. Yeah, or you have a good design plan -- the architecture of the finished engine before you start coding.

{"name":"590595","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/3\/835938715af9625fe3deb744a3b70866.png","w":700,"h":300,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/3\/835938715af9625fe3deb744a3b70866"}
Image: Modular vs. Bottom-up

Would it be valid to create depth for static objects vs moveable objects at the editor level? Like for a tree I can put it's branches and leafs on a foreground level, so when the player walks on it they always get drawn over the player.

it is valid and that is what i am doing in my game http://www.allegro.cc/depot/Thegame/.

my game is what i came up with after i looked at the AGDN rpg tutorial.

i will up data it now so you get fresh example.

As piccolo said, it is valid. In fact, many old RPGs done it this way. Typically, the depth of each tile is determined by which layer it is on. The problem arises with larger, movable sprites, though. Consider if, for example, a larger than normal creature of some sort were to walk in front of the tree. If part of its sprite is taler than the tile width, then he would appear in front of the tree stump, but underneath the tree's branches. To counteract this, I would suggest you still take Y position into consideration when calculating the depth value for your tiles.

I didn't think about that Elverion. The problem is my tree is placed as x amount of separate tiles. To use the whole Y value sorting thing I would have to have the tree as one image it seems.

Ideally, yes. But you can also use the layer to find out the correct depth, and that should work with multiple tiles.

depth = -( y + layer offset )
where layer offset is computed as:
layer offset = ( layer - base layer ) * TILE_SIZE
where base layer is assumed to be the layer where the NPCs would normally walk around.

So, as long as you place the stumps at the base layer (which you should, because they would represent a non-walkable tile), and the branches a layer above that, I think that should work. This might be a bit more work than is necessary, so you might just use the simple method with layers.

I think I'll just put all "objects" on the same layer and just sort by the y value of it's collision rectangle.

You'll wind up putting layers in later

hmm for object that don't move like trees and houses i put the bottom part on the lower layer then the top on the layer above it. like so.

http://www.allegro.cc/depot/screenshots/3138_large.jpg layer 2

http://www.allegro.cc/depot/screenshots/3139_large.jpg layer 3

this way you can put you none passable zones and the base of the house or tree. when you do this it make the object appear 3D because the top part of the object will be draw after the player object so it will look like the player is be hide the tree.

That's find if you characters are smaller than a few tiles. If one of your characters is 4 tiles tall and stands in front of your house, the top part will be drawn over him breaking the illusion. That is why I'm thinking of just giving all objects collision rectangles.

thats not a problem ether. what you do is break your characters in to parts draw the parts on different layers. i am also working on a characters editor the works with characters parts. that is also for my MMrpg and is located in the depot.

Wow, I guess I didn't think about putting characters on different layers. That seems like it would be a pain. I'll stick with just making collision rectangles and check against those.

I just sort my game objects by y coordinate and draw top down.

My big sticking point (and I have an idea for this that suits my engine, but it merits discussion here and I haven't seen it brought up) is brideges and things you can walk iver/under. Fenix Blade, as well as quite a few of the old SNES RPG's, can do this and it's very effective both in terms of looking cool and possibly making map layouts a bit more efficient.

Attached a quick montage for visual reference:

{"name":"590613","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/6\/a698b3e99672e36c106cf99a6cce39ec.png","w":600,"h":140,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/6\/a698b3e99672e36c106cf99a6cce39ec"}

Ideas on how to do that?

Maybe putting those bridges onto different layer. Or even better idea: having separate layers for each ground level - only problem is with travelling between them.

This is my thinking, yes.

there should not be a problem this is how my games works.

edit

that is the same as
drawlayer(1);
drawplayer();//if player on this layer
drawlayer(2);
drawplayer();//if player on this layer
drawlayer(3);
drawplayer();//if player on this layer
drawlayer(4);

I'm just going to babble here, but maybe it's some food for thought.

Why not have infinite layers? In fact, represent layers with Z (as in X,Y,Z). Each tile stores an X,Y and Z variable as well as b,t,l,r variable (bottom, top, left, right). Now, in your map editor, at any time you can pick which layer (Z) you are adding to. So you could have grass at Z=0 and Z=10 (where 0 would be lower depth-wise than grass at 10). Next, you set the b,t,l,r variables, which determine if you can pass the position of the tile. Alternatively, you could just use BB, but even with b,t,l,r I don't see why this would anger free movement (although it might get a little finicky at the edges).

Now here's the kicker: our player is at layer z. That's z, not Z. Meaning, the player is not on a static layer, but his layer actually changes. Say for example you go through a door, well the door has as underlying code that sets the player's z to its Z variable. Thus, in 23's picture (the far left one) above with the bridge and the door, say when you exit that door your now on Z=20 so z = 20. But, before z = 0, so you'd be below the bridge. There's still a bit of confusion in the collision, but maybe it's an idea.

[edit]
In the end, you'll have to sort your tiles from Z=0 to Z=highest in some kind of structure and then draw them going through your sorted list with the method above.

23yrold3yrold, the second image is from Secret of Evermore (during the Prehistoria chapter), and the third from Final Fantasy 3? I'm not so sure about the first one. But yes, I would say that the best way to do that would be to put the ground over multiple layers, and move the character up or down layers when they come in contact with things like stairs or ladders. Stairs could be done by having invisible collision points at both top and bottom of the stair sprite. If the character is on layer 1, and hits the collision point at the top of the stairs, move him to layer 2. Just the opposite, if he hits the bottom of the stairs while on layer 2, move him to layer 1.

Walking over/under the bridge would be pretty easy to do, I think. On the layer that you would walk under the bridge, you do not place 'blocking' tiles, and your depth is greater than the tiles above, so you appear under it with no problem. On the above layer, though, you should place invisible non-walkable tiles at the sides of the bridge to prevent the character from walking into nothingness. Again, your depth would be less now that you are up a layer, so you would appear above it.

Final Fantasy IV.

And Onewing/Elverion pretty much suggested it the way I'd do it. Everything in my game is an object, sorted by z for layer and then y for objects on the same layer that overlap. Tiles would have triggers moving objects between layers as they pass over them. I don't know if that's how the old classics did it, but it's my way.

Now, how to draw transparent water over the player's lower legs when he's walking in liquid. Another trick some old classics (and Fenix Blade) did .... and one that still stumps me a bit.

Funny, I was just thinking about that too when I began reading your post. I think that it's the same as walking in the high grass (another Fenix Blade feature): you just draw seafloor, then begin drawing of translucent water tiles and when it comes to player you draw him and then again the water tiles. Which will end in half of the body (legs) covered by water. Just add some nifty effect of ripples around player and you got it.

Where is Sirocco? He could help...

I don't know, that sounds like over-complicating things. I've got two ideas:

1) The FFIV way (or some rpg game...). When over a forest tile, the lower half of the body turns translucent. This could just be code inside the player object, in which when the player is on certain tiles, the lower half is draw translucently (that shouldn't be too difficult to do) on top of the forest tile. Thus, when on a water tile, the player code knows to draw the bottom half translucently. Now, we still have the problem of the ripple effect. This is a special function in the tile object that basically is run when the player is moving on top of a water tile. This special function draws the ripple before the player is drawn, so the solid part of the player is drawn over the ripple, while the translucent part appears below the ripple, creating some sort of depth.

2) I scratched this idea as I was writing it.

my game can do this as well. what i do is. my player is made up of parts so using my above post code i draw all parts of the play where they need to go. in this case :
ground layer 1 player feet or bottom half layer 1 translucent water layer 2 player top half layer 2. in that order.

Since I started this thread I'm using it for transfer of text. Feel free to ignore the following.

But now not only is the water showing over the legs, so is the seafloor. I think OICW was onto something there; draw sea floor tiles, draw player or other objects, draw water, draw ripples (if any). Then specially draw the player again, but filter out the part of the sprite that's underwater so only the top half is drawn and it looks like his lower half is submerged. That actually seems a pretty good idea ...

I'd just draw the normal water tile, then the player, then a translucent special water tile with ripples

OK, I'm not much into this (I'm just the artsitic friend of the one who plans on making the game ^^ ).

Anyway, you mention the problem of
A) walking in front of and behind textures, not into them.
B) walking in grasslands etc.

A)
Why don't you just make your character AND some kind of indication of the feets. This way, it's not the question if the character collides with the basis of a building. The character is forced to stop when the indicator (feets) hit the basis. Combined with the house in two layers, the character will be able to walk up to the wall, but no further!

B)
If you are using .gif-files anyway, why don't just place a new .gif making the illusion of high grass moving. If this is placed over the character, it would look as if the character were moving, not the layer over him/her.

I'd do it how Thomas suggested.

I would think the "foreground" layer could handle walking in water or high grass. That's pretty much what Thomas is saying.

I was put a collision rect around what would be the base of objects. Then do simple BB collison checks. It seems to be working well.

Oh by the way Rick: I thought that you're working on that isometric board game.

I was but I have drawing technical issues that always get in the way, harder than these top down, and it takes away from programming the gameplay, which is what I enjoy more.

Hehe, me too, me too. That's why I abandoned the idea of isometric engine.

If I were going to go isometric nowadays, I'd just use a 3D grid and camera angle like Final Fantasy Tactics.

Yeah, I'm thinking that if I'm going to make RTS or RPG I'd go for normal tiles or switch to complete 3d.