How do you implement a clickable room object that has a shadow?

Started by Monsieur OUXX, Fri 31/01/2020 07:46:56

Previous topic - Next topic

Monsieur OUXX

There's this paradigm I keep bumping into, and I don't know if I'm doing it right.

Imagine this :
- you have a room
- in the room, there's an object that the player can pick up
- the object is part of the room, so it casts a shadow

The problem is :
- the shadow is part of the object sprite (because it needs to disappear at the same time as the object when you pick up the object) => it means that the "clickable area" of the object will include the shadow.

For small objects it's not noticeable. But for large objects it's awkward (like, you have a shovel standing against the room's wall and it says "shovel" when you hover over it with the mouse, but the 40 pixels to the right of the shovel (representing its shadow cast on the wall) also say "shovel" for no apparent reason).

How I usually resolve it :
- for small objects I let it slip
- for objects with a big shadow I create a second object just for the shadow, that's meant to blend into the background (it's not clickable). To do so I set its baseline to 0. Then when the player picks the "real" object, I disable that shadow objet at the same time.

Is there a better way?
 

Retro Wolf

Make the object unclickable use a hotspot instead. Deactivate the hotspot and the object at the same time when the player picks up the "object" which is secretly a hotspot.

Khris

In the room's rep_exe, keep drawing shadows for visible objects.

Code: ags
  if (oShovel.Visible) roomDS.DrawImage(212, 133, SHOVEL_SHADOW, 70);


As soon as the object is picked up and therefore invisible, the shadow disappears. Drawing it at 70% transparency means you don't need to mess with alpha channel PNGs. And if the lighting conditions change, you can change all shadows in a central place.
If you move this to a module, you can register objects' shadows in room_Load.

Don't know, just spitballing here  :-D

Crimson Wizard

Why using two objects is bad? The only issue I can think of here is the AGS room object limit, but that could be worked around in a critical case. Maybe it's just that AGS room workflow makes using multiple objects less convenient, and thus is causing doubts?
In any other engine I would not think twice and also just create a "child" object for a shadow, without clicking detection.

Laura Hunt

Quote from: Retro Wolf on Fri 31/01/2020 08:51:39
Make the object unclickable use a hotspot instead. Deactivate the hotspot and the object at the same time when the player picks up the "object" which is secretly a hotspot.

This is what I do too.

Crimson Wizard

Quote from: Laura Hunt on Fri 31/01/2020 10:43:17
Quote from: Retro Wolf on Fri 31/01/2020 08:51:39
Make the object unclickable use a hotspot instead. Deactivate the hotspot and the object at the same time when the player picks up the "object" which is secretly a hotspot.

This is what I do too.

I am afraid, you could have missed an important nuance. The object and its shadow may need to have different baselines, because object has a volume, and is solid (an obstacle) and probably can be walked behind, but shadow is flat and should be walked upon. So, instead of 2 objects, you will end up having 2 objects + 1 hotspot, which is 1 entity more.

Laura Hunt

Quote from: Crimson Wizard on Fri 31/01/2020 11:17:57
Quote from: Laura Hunt on Fri 31/01/2020 10:43:17
Quote from: Retro Wolf on Fri 31/01/2020 08:51:39
Make the object unclickable use a hotspot instead. Deactivate the hotspot and the object at the same time when the player picks up the "object" which is secretly a hotspot.

This is what I do too.

I am afraid, you could have missed an important nuance. The object and its shadow may need to have different baselines, because object has a volume, and is solid (an obstacle) and probably can be walked behind, but shadow is flat and should be walked upon. So, instead of 2 objects, you will end up having 2 objects + 1 hotspot, which is 1 entity more.

True, but because our current game uses isometric perspective, there's always a "sweet spot" right at the intersection between object and shadow where you can place the baseline so that the object remains "solid" (as in, you can walk behind it) but the shadow can be walked on. I'm guessing this would also work with a top-down perspective if the shadow is pointing downwards, since the baseline can cleanly split the object and the shadow.

But if the shadow is pointing to the side (like here, for example), then yeah, this would not really work... Good catch.

fernewelten

Quote from: Crimson Wizard on Fri 31/01/2020 10:03:22
The only issue I can think of here is the AGS room object limit

In that case, you could draw the room background to include all the the object shadows and also prepare for each object a separate sprite that "edits out" the respective shadow. After all, there's no (onerous) limit on the number of _sprites_.

When player picks up the shovel, draw the "edit out" sprite directly onto the background at the place that the shadow of the shovel is. Shadow gone.

ManicMatt

I'm confused as to why its bad as well.

In Trails and Traces, there's chair on wheels that moves sideways, and the shadow for it is an unclickable object, and it moves in perfect tandem with the chair, which is more or less the same principle.

Are you just looking for a more efficient and quicker method?


fernewelten

So we've got a light source that throws a conspicuous shadow behind a shovel.
player walks up to the shovel.
So now the light source would need to throw a conspicuous shadow behind player as well, wouldn't it?

And _that_ shadow is going to move around with player and probably change shape and size all the time …

Monsieur OUXX

Thanks everyone for the answers.

Let's recap :
QuoteYou could use an object and a hotspot instead of two objects
Good idea!

QuoteYou might need a hotspot and TWO objects if the baselines don't match
Yes, but I haven't encountered that scenario yet, I'm keeping it simple

QuoteWhat's wrong with using two objects?
Nothing is wrong with that. I'm just trying to reduce the number of manual actions as much as possible. if I have two objects, I have to import two sprites, not get mixed up in the sprites numbers, and one of the sprites must have a pink area (which means more manual work with layers in the graphic file). The hotspot method is great because I can just draw a rough shape over the single sprite and be done with it.

QuoteWhat about overlapping objects?
No one mentioned that one but I'm taking the liberty of adding it : if my shovel (and its shadows) are behind a cabinet door, then when the cabinet door is closed I have to disable the hotspot AND the door cannot use the hotspot method (as hotspots can't overlap). But that's just a corner case, no big deal (this corner case happens to be present in Relic of the Viking, though).

QuoteIf the object casts a shadow then the character must cast a shadow too
In theory yes, but it's actually like that (no shadow from the character) in many games, and it practice it goes fairly unnoticeable.

QuoteThe character's shadow could be automated with a module
It's not the topic of this discussion, but I've also thought about it and the main difficulty is that shadows are not additive. Only the brightly lit parts of the background would become darker. The parts that are already under a cast shadow from the scene would not get darker. It means you can't just draw the character's shadow over the scene, as is. You'd need to keep the overall shadows in a separate channel. It quickly becomes overly complicated.


All in all, I got my answers.
Thanks again, everyone!
 

Snarky


SMF spam blocked by CleanTalk