[Solved] RPG Games and the Overlapping issues

I'm figuring out how to handle the overlapping issues on a RPG game.

To make a screen, imagine a old RPG like Zelda 16bits.

Let's brainstorm about it and hit a final solution until the official Behavior don't come out.

The Problem: In Generic RPG Games, the hero overlap objects on the map, like trees, rocks, grass, houses, etc.

The First Alternative: Make a code for each object type on the canvas check if the player.X and Y is over or under his object.X and Y.

This way you will need to setup the X and Y origin always where you want the objects and player touch the ground. Many people handle this on Flash using a shadow, so, if something is below the middle point of the character shadow, it will overlap the player, if not, will go behind (one level).

The actual problem using this way is: you can't know if the player is the next object behind or on the front of the object, so, how do you setup it to go 1 level behind the player? You can't, it don't have an index (or I missed this part of study).

Do you did another solution? another way? share with us.

I use the z sort plugin that sorts everything on a layer based on the y position: http://www.scirra.com/forum/plugin-isometric-z-ordering-based-on-y_topic46247.html

the most important thing with this kind of issue is collision. The size and origin of your collisions make all the difference with this effect.

With the zelda example you have to be aware that not ALL of link overlaps what hes "in front" of just part of him. That parts determined by how his collision is set up and where his origin is.

Beyond that the only thing you do is make sure things higher up on the screen are at the bottom of the z order than the things lower on the screen.

You dont even really need this effect depending on collision size to sprite size. It can be accomplished purely with layers.

Look at the nes/snes final fantasy games as an example. All the characters fit in 1 "square" of the maps. They collide with things but can also go behind things. The parts they can go behind are on a layer above them. The things they collide with are on the same layer as them

I've been trying to come up with a method that doesn't use any plugins. This is what I have so far. I created a family called SortedSprite and gave it an instance variable z_order. I made my character and scenery sprites both members of SortedSprite family. Then if the player character collides with another SortedSprite, its z_order instance variable is set to the other's z_order+/-5 (5 is sort of arbitrary # here) depending on the two sprite's y values. A variable is then set to trigger resorting of all of the SortedSprite objects using the For Each (sorted) condition.

DepthSorting.capx

(Created with R87, and requires paid version since it uses families.)

It works pretty well, but rather than resorting all of the sprites, might be better to sort just certain sprites -- say just those within 20 or so points in the z_order variable, which could be done using the For Each sorted expression...

Maybe this would work better?

For Each (ordered)

Object: SortedSprite

Expression: SortedSprite.Y

Ascending

----> Move to front

Maybe this would work better?

For Each (ordered)

Object: SortedSprite

Expression: SortedSprite.Y

Ascending

----> Move to front

Doh! How come I didn't see that? All that work to add in and set that stupid z order variable. You are brilliant, TL22!

Here is the new improved, simplified version...

DepthSortingSimplified.capx

Still bothers me if there are really a lot of objects. Perhaps dividing sorted objects between different layers based on Y, and then, on collision, only sorting the objects on the player's current layer? Or maybe that would be just as much work to keep moving objects between layers? You might be able to assign layers to most objects like scenery at start of layout (or design time), and only have to move certain moving objects like player and NPCs between layers , so it might not be so bad. Any thoughts before I try it out?

I dont understand why youd want to move between layers at all. If a layer is over the main play layer then that layer should be considered to be a "not much of anything is higher into the 'sky' than this" the exception being sky/clouds etc.

That means under pretty much every thinkable circumstance the player should always be under it, thus its on another layer.

Same for the ground layers. The player will most likely never be below that layer so consider it that way all the time.

Its like this:

------ arbitrary number of sky layers for fancy foreground effects

------ Top layer 1

------ Top layer 2

------ Player layer

------ Bottom layer 1

------ Bottom layer 2

Everything in the top layers is always above the player. You dont really need 2 of em but you might have a use for 2 its possible. Those layers consist of ONLY objects the player should ALWAYS be under or behind like bridges or the high part of a wall section you dont collide with.

The bottom layers (again you might not really need 2) is for things the player should ALWAYS be on top of, ground dirt roads etc.

The middle Player layer is where anythin the player can overlap should be and thats the only layer your z-sorting should be needed on.

The only time the player should change layers is for things like a bridge you can walk under and across. But that kinda complicated topdown collision doesnt have anythin to do with this

I dont understand why youd want to move between layers at all. If a layer is over the main play layer then that layer should be considered to be a "not much of anything is higher into the 'sky' than this" the exception being sky/clouds etc.

You're right that there is no requirement to change layers. The issue is one of performance. If you are sorting every sprite in the layout, and you have a huge layout with hundreds of items, that is a lot of sorting! If you have the items divided between a three or four layers, then you only have to sort 1/3 or 1/4 of the items.

Anyway, I got it basically working with the player swapping layers based on Y. I have one more thing to iron out, and then I'll post it.

EDIT: Here is the version with the player moving between layers. Looks much more complex because of all of the text objects used to show what is going on (layer number, Y, number of sorted objects out of total scenery objects, and cumulative sorts). There are 138 scenery objects, and without dividing them between layers, they'd all be sorted on each collision. Dividing them between two layers cuts the number of sorts, but still not sure of the benefit of this...

DepthSortingLayerd3.capx

NOTE: When I say number of sorts, I guess I really mean the number of objects moved to the top or bottom of the layer as the result of a sort. The sort is actually sorting all SortedSprite objects, but they are only moved if they are on the player's layer.

Maybe this would work better?

For Each (ordered)

Object: SortedSprite

Expression: SortedSprite.Y

Ascending

----> Move to front

Smart, very smart =]

I need to test it and see if work at a good fps ^^

Is this the best sorting option available to us right now?

I am going to try this out before jumping into a plugin, but sorting in my "birds eye view" game is becoming an issue that I do not want to design around any longer, so hopefully this works out for me.

> I dont understand why youd want to move between layers at all. If a layer is over the main play layer then that layer should be considered to be a "not much of anything is higher into the 'sky' than this" the exception being sky/clouds etc.

>

You're right that there is no requirement to change layers. The issue is one of performance. If you are sorting every sprite in the layout, and you have a huge layout with hundreds of items, that is a lot of sorting! If you have the items divided between a three or four layers, then you only have to sort 1/3 or 1/4 of the items.

Anyway, I got it basically working with the player swapping layers based on Y. I have one more thing to iron out, and then I'll post it.

EDIT: Here is the version with the player moving between layers. Looks much more complex because of all of the text objects used to show what is going on (layer number, Y, number of sorted objects out of total scenery objects, and cumulative sorts). There are 138 scenery objects, and without dividing them between layers, they'd all be sorted on each collision. Dividing them between two layers cuts the number of sorts, but still not sure of the benefit of this...

DepthSortingLayerd3.capx

NOTE: When I say number of sorts, I guess I really mean the number of objects moved to the top or bottom of the layer as the result of a sort. The sort is actually sorting all SortedSprite objects, but they are only moved if they are on the player's layer.

If you don't want to use a third party plugin, for each ordered is the method to use. The plugin I linked to might be faster, though.

If you don't want to use a third party plugin, for each ordered is the method to use. The plugin I linked to might be faster, though.

Aside from the ability to not publish to the Scirra arcade, are there any other downfalls to 3rd party plugin use?

I have to use SpriteFont right now, so does that mean I might as well use all plugins I feel are needed since I am already using one?

There's a chance some plugins might not be 100% compatible with appmobi or cocoonJS (unsupported features and such - I've checked that the one I linked to works with cocoonJS so I don't think that's the case for that that plugin with appmobi though), but aside from that and no uploading to the scirra arcade, no downsides to them.

I always come here to check if the post still alive ^^

A plus need to be added here:

If you have enemies overlapping each other, you'll need to check their own.Y and use the solution of sorting them behind each other.

I was thinking in make an instance variable and call it by Z, them, check their.Y and sort on the canvas. You can also check if the object is displayed on the canvas, saving CPU ^^

Objects can belong to multiple families at once. I just plug all the sprites I want to z sort into an additional family called "Zsort" and then do the "For Each (Ordered)" method. Works like a charm.