Need Help with Top Down a la Zelda Object Sorting

Hey there,

I am fiddling around with a zelda like rpg. I am having a hard time with the sorting of tall objects like pillars or trees. Imagine that tall pillars are overlapping each others. I have some very basic events that goes something like : if player Y position > than the pillar position then move pillar to front (draw order). But that is obviously a problem when you have two pillars overlapping each others because it moves the one that is supposed to be behind, in front of the pillar that should be in front.

Thank you for your help !

If I can add these important details. I will be layering tons of those objects in the game in order to create breakable walls.Since the game has a perspective (not completely top down) the player can be in front r behind those objects.

Thanks you !

I made you an example, it uses the Layer object that come with MMF (I think...)

http://www.rhysd.com/layeringobjectsa.mfa

I'm assuming you want it so that when the player moves behind the tree, the player is underneath the treetop so it appears he is behind the tree? All you need is two layers. On the top layer have the objects that the player is supposed to be under (treetop, top of pillar, etc), then on the same layer with the player have the tree trunk that the player collides with. If this is what you are wanting, you don't even need to use the layer object to sort anything.

If that doesn't make sense I'll make an example for you.

You're referring to Z-sorting, and the layer object is probably the best method for this (as posted above)

Sure you could try Shawn's method, but if the player is able to walk behind a lot of stuff, that's going to be tedious cutting everything up into separate objects.

For Zelda: A Link to the Past, they merely had several layers in their tileset and did much like Shawn suggested... The problem here is that MMF isn't very tileset friendly... Meaning you'd have to move around a lot of active objects to get the same effect.

So yeah, I'd say go with the layer object... That will let you keep each object down to one active. Though I think I've tried it out before and sometimes you'll still get weird issues with objects swapping z positions.

Quote:

---

Originally Posted by Konidias

That will let you keep each object down to one active

---

I'm curious though how you'd handle the collision with only one active representing the tree if you are going for an overlap effect? Somehow, you'd have to only collide with the trunk while moving the treetop forward. With one object you'd either have to collide with the entire object itself or not at all. MMF2 doesn't allow you to define your own collision masks for actives. Which raises another issue... you'd be using a lot of actives for no reason. Making the background as actives when you could easily just use backdrops on separate layers is not very efficient. Actives take more resources than backdrops. Also using the layer object for this is a lot of unnecessary events.

Unless I'm misunderstanding what you are saying, there is no way to get the desired effect with one active for the entire tree or pillar.

Putting the collision box inside the animation for the obstacle would work.

Quote:

---

Originally Posted by Konidias

Putting the collision box inside the animation for the obstacle would work.

---

I don't understand what you mean? You can't put a collision box in the animation. The collision is the entire graphic, which goes back to what I said about not defining your own collision mask. In order to have a collision box, you'd have to use an invisible active on top of the tree graphic and have the tree set to not be an obstacle. In which case, you'd be far better off just using backdrops on layers.

Say you have a 32x64 tree, but you only want to have the bottom 32x32 pixels be an obstacle... Well you'd just have the tree graphic in the Stop animation and then you'd put your 32x32 box in another animation inside the active... then you'd just switch the animation to the box before doing collision checks, after the collision checks in your event list, you'd switch it back to the Stop animation.

So the end result would block the player but you'd only ever see the tree graphic, and not the box, since it's not displaying at the end of the game loop, only during the collision check.

Wouldn't that produce a flashing effect though? You'd have one animation as the whole tree, and one with only the trunk. Switching between those would make the tree flash or blink, I would think.

At any rate, I made a quick example for him showing my method.

http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=218065#Post2180 65

Granted, using multiple objects as opposed to one would take more time, but if switching animations causes it to flash, I'd just use backdrops.

It shouldn't flash because the game is only updating at the end of the event loop... Not during the loop. You can have 50 events changing an object's position and then run the game, and the object will not jump all over the place. It will be in the position the very last event put it in.

To the game, yes it's seeing:

change animation to obstacle
detect collisions
change animation to tree

But to the player they just see the tree animation.

This is the same reason why when people try to have an object follow another object's position, it "lags" behind unless you put that following event underneath the other events... The loop is going from the top to the bottom and then updating the game screen. So if you do:

parent the child object event

and then

move parent event

You're always going to get this weird delay because the game is positioning the child first and then the parent is moving... But if you do:

move parent

and then

parent the child object event

It's moving the parent first, then it's positioning the child to the very last position the parent moved... So it's perfectly locked on.

Sorry if this is long winded but it seems you don't quite grasp how the game loop works so I thought I might help to explain it.

Ok that does help explain it a bit. I guess the game loop updates it so fast that you don't see a transition from one animation to the next.

Out of curiosity, do you have an example or can point me towards one showing this method? Sounds like it's something I should learn how to use myself. The method I use works, but if it saves me from dividing up my graphics, that would save a lot of time.

I believe it's been discussed on these forums before, so you might be able to find an example by searching... Either way, I'll make an example when I get home in a few hours.

One thing about what you said though "I guess the game loop updates it so fast that you don't see a transition from one animation to the next." That's not really true... The game loop isn't updating it faster than you can see, it's just not ever displaying it in the first place. :P It's reading it internally but not displaying it externally ever. You have to separate what you're seeing on the screen from what you're seeing in your event list.

The game isn't running through each event one by one and displaying it on the screen. It's running through the entire event list and then displaying the final result. Even if you slowed the loop down to one loop per second, you'd still only see the end result of the loop, not the individual events.

There's this:

http://www.create-games.com/article.asp?id=1639

But the example is apparently no longer online.

Ahh okay. Yeah I guess I didn't understand very well how the game loop updates. So in other words, the game loop reads the events, then displays everything after it cycles through the loop?

Also, I wasn't trying to be contrary or argumentative I was genuinely curious how that would work properly, so I hope you weren't taking it that way. I never heard of this method so I was a bit confused. Thanks for explaining! This will be very useful and save a lot of time.

Oh it's okay. I didn't think you were arguing or anything. I'm happy to help.

The only thing about this method is that you have to be careful what events you're using because not all events are created equal. For example, I think you're only able to really use the "if overlapping" event, and not the "on collision" because these two events have different priorities in the loop. Which may make it difficult to work with depending on your game.

If all else fails, I'd always use the one obstacle for each active method. It's much easier just having a single invisible obstacle object you can place behind your graphics instead of cutting up all your graphics into pieces.

Thanks you all for your replies !
RhysD your example was the bomb, you indeed had lots of those objects overlapping and it worked great. Didn't know about the layer object. Thanks

Well here's more info on how I have it setup.
My pillars are indeed something like 256 x 64 and the collision is 64 by 64. I only copy this collision square around and i have an event creating the pillars on top at the start of frame. I am also planning to have every destructible states saved when the player saves... But anyways I do have a separate collision object. In this game I do not use the graphics as collisions in most cases (player has to go behind and my environments are huge paintings sliced into sections for faster drawing but not made out of little tiles). I am making a 720p game heavy on artwork. Testing the limits of mmf2? :)