Top down rpgish. Z-layer help

gameking31

  • Posts: 22
I've been at this for at least seven hours now. From midnight to seven AM I've been looking for some way to get the game to take the Y variable of one actor, compare it to another, and put them on the appropriate Z layers, all in one nice event that can be put in each scene or object, but Any and all user content is incompatible and outdated. Forum posts so far haven't helped and the ones that looked helpful lead to broken or removed hyperlinks. Google is also sparse at best about even knowing what Stencyl is. All I want is for my skeleton man to circle a piano in a believable way in the view of 2.5d like many old beat-em-ups and old style rpgs. Thank you to anyone who has an answer to this problem.

stefan

  • *
  • Posts: 2263
Welcome to Stencyl!
Is the piano part of a tile set or is it an actor?

merrak

  • *
  • Posts: 2700
To place an actor A behind another B, you can use two blocks:

Code: [Select]
Send A to layer of B
Send A back a layer

And to put A in front

Code: [Select]
Send A to layer of B
Send A forward a layer

You can also use z-index within a layer, which would require less planning in the scene design stage. (e.g. what happened if B was at the bottom most layer, for instance, and you tried to push A further back? Using z-index is illustrated here)

gameking31

  • Posts: 22
Thank you everyone for your replies already, I've been to that page already due to google's very limited result pool for this matter. Bringing an object to the front would be fine, if it weren't for the fact that the finished product of this game will have you exploring an entire mansion, full of furniture and the usual haunting s that will have to make their way around objects, and this could get complicated fast if we use a 'bring to front' method.

To answer the first question however, the piano is an actor that doesn't move. I use this because  I planned on having interactions with specific objects, which would have been my next test if I hadn't wasted all my time bashing my skull into problem one.

merrak

  • *
  • Posts: 2700
I think the issue with z-indexes is that you're trying to use them like a sort of actor-based  depth buffer, which (to the best of my knowledge) they're not. There are a couple good solutions I can think of. Keep in mind both solutions basically add an entire dimension to the existing 2D coordinate system. This simple-sounding problem has quite a bit of depth to it.

1. Painter's Algorithm. I actually wrote about implementing this over here in an isometric game. It could work for you, too. You would only need "scene height" number of buckets, and each actor is placed into the bucket corresponding to its y-coordinate. The advantage is that a "draw stack" (as I call it in the post) based solution handles a lot of actors efficiently. The drawback is that you're basically writing a little renderer that sits on top of Stencyl's (using the Drawing events). This means letting go of some of the things Stencyl makes easy for you (like some of the tweens), or implementing it yourself.

2. An alternate solution would be to build off of Mr. Wagoner's solution. At the very end of the post he gives you a "z-index update" block. What you'd want to do is make a similar event. It would look something like:

Code: [Select]
For every y coordinate that is on screen
    For every actor with that y coordinate
        Move actor to the top within its layer
    End For
End For

Note that we only loop through the y-coordinates that are currently on screen. Don't loop through the y-coordinates that are out of the camera's bounds. The simplest solution is to call this event whenever the y-coordinates of any actor change, but we'll want to avoid that (read on).

The advantage is that you're not writing your own renderer. The drawback is that you potentially have a major bottleneck. This is a double loop, and could be called often, especially if you have a lot of moving actors.

If you (or anyone else finding this thread) wants to try implementing that idea, what I'd suggest you do is put the reordering event in a scene behavior. Whenever an actor moves, set a boolean "update z-index?" to TRUE. In an "Drawing" event within a scene behavior, run the following:

Code: [Select]
If update z-index? then
    Call the z-index update event
    Set update z-index? to FALSE
End If

Then, whenever an actor moves, do this: (Put this code in an actor behavior. Attach it to each actor that moves)

Code: [Select]
If new y-coordinate != old y-coordinate then
    Set update z-index? to TRUE
End If

This ensures the update runs at most once per screen update. (So, at most 60 times per second).

« Last Edit: July 11, 2015, 01:27:46 pm by merrak »

gameking31

  • Posts: 22
Thank you so much for taking the time to reply to me.  I will try implementing this once I retrieve my pet lizard's tank carpet from the wash. As a forewarning though, I am not a programmer, as to why I'm using Stencyl and not Java or C++. Is this all possible using  the existing lego block programming, or if not, able to be copy pasted into a script block? I will attempt to make this work on my own for now.

PhilIrby

  • Posts: 545
(edit); oops, this is the same theard marrek gave you in his #2.

Have a look at this thread. Might be of some help.
  http://community.stencyl.com/index.php/topic,36173.msg204747.html#msg204747

« Last Edit: July 11, 2015, 04:45:41 pm by PhilIrby »

merrak

  • *
  • Posts: 2700
Thank you so much for taking the time to reply to me.  I will try implementing this once I retrieve my pet lizard's tank carpet from the wash. As a forewarning though, I am not a programmer, as to why I'm using Stencyl and not Java or C++. Is this all possible using  the existing lego block programming, or if not, able to be copy pasted into a script block? I will attempt to make this work on my own for now.

I'd say Mr. Wagoner's solution (#2) will be the place to start, then. I can think of some other ways to optimize it, depending on what actor arrangements are possible. But, I don't know what those are, so I tried to give you some general, catches-all-cases solutions. If you get #2 working and there's no lag, then problem solved :) If there's lag, we can go from there.

gameking31

  • Posts: 22
Sorry I have to be so naive about this, but I don't see how I should be editing it. His thing groups individual objects, and dependent on what object it is, it puts it on a certain Z value (Which somehow, I'm missing how it's even doing that.) I've fiddled with it, a bit, but not much comes of it because I'm not entirely sure what direction I'm supposed to take his build.

Edit, I've fooled around with it some more now that I've gotten some sleep, and still no luck. How do you create and use these several 'buckets' for different Y values? The concept makes sense to me, but the implementation is what I'm having trouble with.

EDIT: Please someone help me understand this problem. All of the z-order solutions available on stencyl are incompatible, and it is a very important part of this game we are trying to make.

« Last Edit: July 13, 2015, 06:45:47 pm by gameking31 »

gameking31

  • Posts: 22
Alright, I've been at this for the entire week now, here's my scene behavior right now. I just want to know what I'm doing wrong. I really want to move on and start making this game. (First snippet is ALWAYS, and second snippet is CREATED)

My main character just appears above everything else. No Z switching, nothing.


gameking31

  • Posts: 22
CLOSED: So I finally figured out where I was going wrong. On forge there's a Z-layering example, (Uses the little guy from the default maze game and trees.) I copied his blocks over but they didn't work. I didn't realize I had to remake the custom blocks because they were not yet implemented. Luckily, you just make a custom block, and just remake the two blocks he used. After that, I just put the 'update z-order' equivalent on something that activates constantly. Thank you everyone here for all your help, and sorry for not figuring this out sooner.

letmethink

  • *
  • Posts: 2545
The reason why yours didn't work is because, despite where you drag the blocks from, they will all refer to the inside 'for each actor in region'
~Letmethink