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.

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?

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.

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.

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.

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"}

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.

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.

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...

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.

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.

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.

You'll wind up putting layers in later