Different solutions to a character in an AGS game in front and behind something!

[ManicMatt]

I didn't put this in the technical help threads as I am not in need of any help. But if it is still more appropriate, or somewhere else is, please move it there, mods!

I am talking about when a character is behind and in front of a walk behind. For instance, if an NPC is sitting at a table with their arms resting on the table. They can't possibly be both behind and in front of it.

I created a second character that is their arms and as its only during a blocking scene that they rest their arms on a counter, I don't need to worry about interactions with the arms, although that's not too big a deal.

So i was just wondering how other people got around this, should there be an easier solution for future reference.

It's interesting to me that something so basic isn't so straightforward, unless I'm being dumb, lol.

You can't have part of the table be the character, because the hotspot label will name the character instead of the table/counter, so I dismissed that idea when I first thought about how to proceed.

I used a character instead of an object because not only is it global, but I swear animation speeds are different for objects and characters.

[Ali]

Unless they're constantly moving, why not just put them in front of the table, and not draw the part of that's supposed to be behind?

[Matti]

I've had trouble with this too.

Once I had a character sitting at one side of a table and the arms were supposed to rest on the table while the legs would be covered by a table leg. I solved this by making the table leg a different object and put it in front of the character.

I also had the situation with a character sitting behind a table with the arms on top of it. If I remember correctly I did what Ali suggested and cut out parts of the body that were supposed to be behind the table. But I think that's still a rather annoying and unpractical solution, especially if it's not pixelart or if the character is animated.

[ManicMatt]

In this instance, my character slams their hands down on to the counter. Additionally their idle animation has their arms behind the counter.

So I have the arms stay in room 0 and summon them to the correct room at the same time the actual character's view is changed, and then back to 0 again. It's almost like doing a magic trick, or a video masking effect!

[Cassiebsg]

But isn't it a "special view"?
I just change the view to a new one and "draw" the character in place, and cut out parts that are suppose to be behind.

[ManicMatt]

Do you mean, not use a walk behind, just perfectly line up the character and don't draw below their waste or wherever? Hmm I suppose that works, although it is a bit of a hassle unless the table is a perfectly straight line. In my instance, it's a diagonal line.

You made me realise that's what I did in the game in my signature. Boiled-Hard peers around a wall, but it was a pain getting the pixels to be just right along a curved wall. I had the background as a layer when drawing the sprite.

By having the npc set behind the counter, I don't have to cut out anything, so it seems we either have the complication of cutting out an exact line, or the complication of making the seperate entities.

[Cassiebsg]

In my case it's a little easier, since I'm rendering my characters, I can just place them and tell it not to render in the "blocked" part.
Alternatively you can choose to include the table (or an entire rectangle of the BG) in the animated sprite.
I think what makes it a challenge (or used to, in older versions of the engine) was that AGS used 2 pixles for "high definition games" instead of just one. That made it sometimes  impossible to perfectly align the sprites. But am pretty sure this has been fixed in the newest version (right?  )...

[ManicMatt]

As I already said, having the table be a part of the sprite means that if it's not a blocking scene, the label text will say the character's name on the part of the table that is their sprite.

I dunno about that, I didn't have any issues with Trails and Traces that was around 640 or something but that's hardly a high resolution I suppose, and Boiled-Hard is the lowest resolution - 320 x 200. I do remember having that issue in some older game I made many years ago.

[Babar]

An image example of your scene (or a video of where you implemented before) would be helpful. Because the situation doesn't seem all that complicated: just place the sprite exactly where it should show, and put it in front of the desk?

[ManicMatt]

I mean yeah I CAN just not draw below that counter, no walk-behind required. But it's just extra time with all his animation frames trying to remove excess graphics where I drew just slightly below it. This character (Who you might recognise, lol) turns his body in some animations so he's not all that static. I might even have him walk slightly from behind the counter because he will be placing an item or two on the counter but not right in front of him.

[Snarky]

I don't know what application you're using to draw your sprites, but in Photoshop you could just import the background as a layer (if not already done), then select the counter and create a mask from that selection (or rather, the inverse) and apply it to the folder with all the sprites that should be affected, so that any part of the sprite that is behind the counter will not be drawn. It should take less than 20 seconds.

[ManicMatt]

I'm using Asesprite, but yeah I see what you mean.

But.. as soon as he needs to walk, then what? If he didn't, then sure, that would work just fine.

So I think I can take from this, a better solution if a character doesn't need to move from behind something, but if they ever walk or are the main character, then my original solution seems to be the best way.

[Babar]

Even if the character needs to move, just change the view of the character for that (you'll likely need to change the view of the character anyhow, from standing still doing stuff to walking).

[Cassiebsg]

Yes, you can also make the counter an object, so you don't have to deal with any walkbehind at all! In that case the only thing you need to deal is when his hands need to be over the counter, and that you can just use a specific view for the purpose.

[TheManInBoots]

I don't know what application you're using to draw your sprites, but in Photoshop you could just import the background as a layer (if not already done), then select the counter and create a mask from that selection (or rather, the inverse) and apply it to the folder with all the sprites that should be affected, so that any part of the sprite that is behind the counter will not be drawn. It should take less than 20 seconds.

This way the arms on top of the table will be cut out though as well or with inverted selection the entire body shows below/on top of the table. So it's probably more than 20 seconds if you consider the arm shape.

If you wanted a different method for the sake of it, you could also create the cut-out of the arms into the table, and do that for the table for every animated sprite.
And then once you have every cut-out for the table you write in late repeatedly:

Code: ags

if(player.View==12&&player.Loop==0)//Selected Sitdown on table view
otable.Graphic=player.Frame 98;//98 would be the sprite ID of the first frame of the table cutout animation,...
//... corresponding to frame 0 of the sitdown animation

This way the table animates the cutout together with the character animation.

But having the arms as a separate character is still the best solution imo as well.
This way the character can walk around with his hand on the table, do whatever you want, and sit down where you want, you just let the hand follow the character.

[Ali]

Honestly, I think the most sensible way to do this is just cut the blocking portion out of your sprite. The player can't see it, so it doesn't need to be there! This is the way I've done it.



This way you only have to line the character up with the background pixel-perfectly once, and all animations in that position will work. It doesn't rely on you lining up 2 characters and perfectly synchronising them with each other, or synchronising the overlay to match the animation. Plus, you can see if the animation works by eye, without having to run it in-game.

As Babar says, switch to a set of views where the proportions and position match the regular walk/talk sprites, but with the table cut out. The change ought to be seamless.

[TheManInBoots]

Babar the limitation to that approach is that you have to place the character at ONE specific spot on the table, because the y-value changes as well with x-coordiante on a diagonal table.
So you would have to calculate pixel-perfectly for every new spot.
Also this approach doesn't account for round tables or otherly shaped foreground objects if you want to change spots.
That's why an extra character for the arms gives most flexibility.

[Ali]

If the character needed to punch many different spots on a wobbly-edged table (in a cruel revival of the Full Throttle wall-kick puzzle) then a separate sprite would be the only sensible option.

But for normal purposes, that's overkill. The cut-out region doesn't need to be flat or regular. It would follow the outline of whatever is on the table.

[TheManInBoots]

We agree on that.

[Snarky]

This way the arms on top of the table will be cut out though as well or with inverted selection the entire body shows below/on top of the table. So it's probably more than 20 seconds if you consider the arm shape.

Obviously you wouldn't mask the arms when they're supposed to appear on top of the desk. Since Matt talked about making the arms a separate character, I assume they are already drawn on a separate layer.

There are really only a few reasonable ways to solve situations like this in 2D, where parts of a sprite should be hidden by a background element and parts shouldn't:

1. You divide the sprite into separate sprites, and display them with different baselines (e.g. as different characters)
2. You divide the background element into separate object sprites/walkbehinds, with different baselines
3. You pre-mask the sprite so it doesn't include anything that should be hidden
4. You include the background element as part of the sprite

The best solution will depend on the situation (for example, solution 2 wouldn't really work in this case) and other factors. This seems like a pretty clear case for 3 or 4, since that's generally the simplest and doesn't require messing around with repeatedly_execute() (which is almost always best avoided), but sure, 1 will work too. Matt did ask if there was another, simpler solution, though.

[TheManInBoots]

then select the counter and create a mask from that selection [...] and apply it to the folder with all the sprites that should be affected, so that any part of the sprite that is behind the counter will not be drawn

What exactly do you mean with "all the sprites"?

Well, personally I would do it as well with different characters, but that's a personal preference.

But if you look for simplicity -if that's what ManicMatt asked for-, and you have only one sitting position, then as Ali pointed out, pre-masking the character is the easiest solution,
because you do not have to create a second character and animation.
If you have the arms separately in your image editor, you can pre-mask the character sprite using the table mask as you described, and just layer the arms on top of the cut out character.
So that eventually you have only one single animation and character for the table animation.

[ManicMatt]

For my second character that is much further along behind the counter, I don't intend for them to move around as much as the other character here, and will be rather static comparebly, so I have done as Ali demonstrated.

Oh yes, I always draw arms, legs, head and torso (and sometimes hips) in different layers, which is something I highly recommend if anyone isn't using layers already.  It's especially useful when it comes to animation. Although I do on occasion start drawing on the wrong layer, doh!

[TheManInBoots]

Although I do on occasion start drawing on the wrong layer, doh!

Yeah, happens to me too sometimes! When I click to make a layer visible and believe it's also selected because of it, when it's actually not