Walk Behind Transparent Foreground

[gaydarade]

Intro.
Hey all, I'm a longtime lurker, and these forums have been a huge help to me in the past so I wanted to give something back. This is a tutorial for how to selectively fade out foreground elements! This question has been asked a few times throughout the forum, in different contexts, so I hope future devs can use this thread as a jumping off point for how they might tackle "walking behind walls".

Preview.

Updates.
v1.0 (June 6, 2021): Included a simple method for RM, with examples from VX Ace.
v1.5 (June 7, 2021): Updated formatting for clarity. Minor edits.
v2.0 (June 12, 2021): Added a second method specifically for VX Ace, using Victor's fog/overlay script (this one). Minor edits.
v2.5 (August 3, 2022): Updated Method Two. The event code was improved significantly for performance.

Background.
When I played the Early Access for CrossCode forever ago, I loved the feeling of depth that walking behind structures offered, when they selectively faded out. I really enjoy the visual/mechanical design of that game, and I've wanted to emulate some of those features for forever.

For the player: it looks really slick, and it encourages a lot of exploration, especially if you start hiding treasure chests behind terrain.
For the beginning developer: this is a great way to introduce yourself to some parallaxing concepts without fully committing to a totally different style of mapping, and likewise, this is a great place to dip your toes when you want to learn a little bit about scripting.

I referenced a few different topics for ideas: most importantly here, here, the Script Call Collection, and here to see more helpful examples of the necessary script calls for pictures. I recommend taking a look through those threads if you're curious and want to come up with ideas yourself. There's a lot of smart discussion in there.

Method One: Vanilla Ace.

Spoiler: Method One: Vanilla Ace

How-To.
TL;DR:

1. I have a base map that's designed with none of the overlap elements. (This can be parallaxed, but it's just as easy to do in the RM map-editor).
2. I have seven separate overlay images in the pictures folder.
3. I have 7 regions on the map that each correspond to an overlay area.
4. I have one event that loads in the images, then watches the player's region_id to decide what to fade in and out.

Warning:
The code used to manage the events is really beginner stuff! I've improved since 2021, and the code in Method Two is a little smarter. Check that code out after you read this, because it may give you some ideas for how to improve, even if you want to stick with Vanilla Ace.

Detailed guide w/ pictures:

Spoiler: Detailed Summary

1. I started with a basic map using the RTP. This doubled as the source for all my picture overlays: You can just screenshot this, but I used tsukihime's Map Screenshot script. A little later on, you can see the pillars and walls that I removed in an image editor.


2. I duplicated that map, and with some more shift-click mapping back and forth I took out all the elements that I wanted the player to be able to walk behind.


3. This is the same map as above, but showing the regions where our overlapping elements will be. It makes kind of a goofy rainbow smiley face.


4. I used GIMP to cut out the following 7 elements from my original map that I want to fade independently of one another.


5. Finally: Here's page 1 & 2 of the Event that makes it all work:


Page 1: Autorun event with a script call and a self-switch toggle.

$game_map.screen.pictures[0].show("map 1 - region 1", 0, 0, 0, 100, 100, 255, 0)
$game_map.screen.pictures[1].show("map 1 - region 2", 0, 0, 0, 100, 100, 255, 0)
$game_map.screen.pictures[2].show("map 1 - region 3", 0, 0, 0, 100, 100, 255, 0)
$game_map.screen.pictures[3].show("map 1 - region 4", 0, 0, 0, 100, 100, 255, 0)
$game_map.screen.pictures[4].show("map 1 - region 5", 0, 0, 0, 100, 100, 255, 0)
$game_map.screen.pictures[5].show("map 1 - region 6", 0, 0, 0, 100, 100, 255, 0)
$game_map.screen.pictures[6].show("map 1 - region 7", 0, 0, 0, 100, 100, 255, 0)

Page 2: Parallel Process event with a script call.

x = $game_player.region_id

if x != 1 then $game_map.screen.pictures[0].move(0, 0, 0, 100, 100, 255, 0, 15) end
if x != 2 then $game_map.screen.pictures[1].move(0, 0, 0, 100, 100, 255, 0, 15) end
if x != 3 then $game_map.screen.pictures[2].move(0, 0, 0, 100, 100, 255, 0, 15) end
if x != 4 then $game_map.screen.pictures[3].move(0, 0, 0, 100, 100, 255, 0, 15) end
if x != 5 then $game_map.screen.pictures[4].move(0, 0, 0, 100, 100, 255, 0, 15) end
if x != 6 then $game_map.screen.pictures[5].move(0, 0, 0, 100, 100, 255, 0, 15) end
if x != 7 then $game_map.screen.pictures[6].move(0, 0, 0, 100, 100, 255, 0, 15) end

case x
when 1 then $game_map.screen.pictures[0].move(0, 0, 0, 100, 100, 128, 0, 15)
when 2 then $game_map.screen.pictures[1].move(0, 0, 0, 100, 100, 128, 0, 15)
when 3 then $game_map.screen.pictures[2].move(0, 0, 0, 100, 100, 128, 0, 15)
when 4 then $game_map.screen.pictures[3].move(0, 0, 0, 100, 100, 128, 0, 15)
when 5 then $game_map.screen.pictures[4].move(0, 0, 0, 100, 100, 128, 0, 15)
when 6 then $game_map.screen.pictures[5].move(0, 0, 0, 100, 100, 128, 0, 15)
when 7 then $game_map.screen.pictures[6].move(0, 0, 0, 100, 100, 128, 0, 15)
end

Notes, Pros, & Cons.
Notes: My code is a little sloppy, but it gets the job done. Any feedback for how to clean that up is welcome! I also wonder if you could set this up to use Sprites instead of Pictures. That might avoid some of the worst drawbacks of this method, at the cost of adding a few extra events to each map.

Pros:

1. This method looks good & achieves the intended feature.
2. The time investment is moderate & manageable.
3. Setting this up is beginner-friendly.
4. The base concept can be translated easily to most versions of RM.
5. If other script resources for Ace disappear, this method will still be available.

Cons:

1. This only works on your map's default resolution (vanilla Ace: 13x17 tiles, 416x544 px).
2. This doesn't work with Screen Shake or Screen Tint.
3. There's a little lag before the event shows the pictures, which should be covered up with a fadein/fadeout command.
4. Because you cannot reference files in sub-folders, it really clutters up the Pictures folder if you're trying to keep a big project organized.
5. You have to manually erase all the pictures on the screen every time you change maps.

Method Two: Ace w/ Victor's Scripts.

Spoiler: Method Two: Ace w/ Script

How-To.
TL;DR:

1. Install Victor's Basic Module and Fog and Overlay. Read the installation instructions & usage guides for both.
2. As in Method One, prepare the map, regions, and overlay images.
3. In the map notes, set up the overlay images you'd like to use for your map as per the Fog and Overlay setup instructions.
4. Then find the "set_fog_opacity" method in the Fog and Overlay script: you can use this function in a script call, rather than as a "comment call". This way you can build nice clean logic statements around it.

Detailed guide w/ pictures:
First, follow instructions 1 through 4 from Method One's detailed guide. Then proceed.
0. Instead of using the pictures folder, this script uses a "Fogs" folder that you insert yourself. This means you can also work with sub-folders.

1. Using the map notes box, set up a fog effect for each overlay image, this will load them instantly with the map, automatically remove them when you change maps, and has the added benefit of keeping your overlays organized. If you give each fog effect the same ID as the Region it's tied to, that will simplify the code we use in the next step. Note below that we're also searching subfolders for images here: this is another level of helpful organization.

3a. The last step is to set up an event that will fade our overlay images in and out as necessary, based on our region ID. Victor intends for this script to be used through "comment calls", but we're total rebels and we can sneak around that no problem. Search his script for a method called "set_fog_opacity". There are two of them in the script, but the one associated with Game_Screen is going to save us a lot of time and hassle. You can find it around line 94 of the script. It takes 3 arguments, an id, an opacity, and a duration, which is just like the comment call.


3b. Set up an event with two pages. Each page should have one script call. The first script call will initialize a global variable that will help us track the regions that our player walks over. The second script call is going to check any time a player's Region ID changes, when it does, it's going to see if there any fogs that it needs to fade out or fade back in, and it's going to update the global variable.

Event page 1:


Event Page 2

Map page Notebox
[Code = xml]
<fog effect>
id: 1
name: "m1/r1.png"
</fog effect>

<fog effect>
id: 2
name: "m1/r2.png"
</fog effect>

etc. There are 7 of these, but you can have boatloads. Just make sure to match up the right ID with the right Region
[/code]

Event Page 1: Autorun
1 Script Call:

$region_delta = 0
$game_self_switches[[@map_id,@event_id,'A']] = true

Event Page 2: Parallel Process, Self Switch A is On
1 Script Call:

x = $game_player.region_id

if x != $region_delta then
screen.set_fog_opacity(x, 160, 15) unless x == 0
screen.set_fog_opacity($region_delta, 255, 15) unless $region_delta == 0
$region_delta = x
end

Notes, Pros, & Cons.
Notes: This setup is really nice! I'm a big fan of doing it this way, so big shoutout to Victor for the scripts.

Pros:

1. This method looks great and works with all screen effects.
2. The time investment is even less than Method One, and takes less brain power to keep track of.
3. You could even upgrade it further, by storing all the code in a Common Event,

Cons:

1. These instructions really only work for Ace, and probably won't be too helpful outside of that.
2. This method requires access to & compatibility with Victor's scripts.

Previous Version's Event Code.

Spoiler: Previous Version Event Code

TL;DR:
After tinkering with this a lot and testing some things, I managed to upgrade the code a lot. But to help show my process, and for people who may b e trying to learn, I feel it's helpful to include some of the old snippets here. You can see them below, and there's clearly a lot of beginner reasoning being used. The new version's way better, but this was the easiest way for me to think about it a year ago.

The Old Stuff
3a. The last step is to set up an event that will fade our overlay images in and out as necessary, based on our region ID. Victor intends for this script to be used through "comment calls". That won't work for our purposes, but if you look at the Fog and Overlay script, you'll find two methods called "set_fog_opacity". One is under the class "Game_Map", and the other is under "Game_Screen". We want the one from Game_Map that processes the text from a comment call. We can pass strings to that method in a regular old script call, so that's exactly what we'll do.

3b. Set up one parallel process event with one page and one script call. The script call will have all the code we need in one place to fade our overlays. In this code, we grab the player's region ID and store it in "x". Then we have one command that compares x to the fog effect ID, and fades out when there's an overlap. After that we have a series of commands that check conditions for when a fog effect should go back to full opacity.

x = $game_player.region_id

if x != 0 then $game_map.set_fog_opacity("<fog opacity #{x}: 126, 15>") end

if x != 1 then $game_map.set_fog_opacity("<fog opacity 1: 255, 15>") end
if x != 2 then $game_map.set_fog_opacity("<fog opacity 2: 255, 15>") end
if x != 3 then $game_map.set_fog_opacity("<fog opacity 3: 255, 15>") end
if x != 4 then $game_map.set_fog_opacity("<fog opacity 4: 255, 15>") end
if x != 5 then $game_map.set_fog_opacity("<fog opacity 5: 255, 15>") end
if x != 6 then $game_map.set_fog_opacity("<fog opacity 6: 255, 15>") end
if x != 7 then $game_map.set_fog_opacity("<fog opacity 7: 255, 15>") end

Ending
Anyway, that's all I have for now! I'd love to see how other people implement this feature, or hear if anyone has ideas on how to do it better!

 

[Shaz]

Moving to VX Ace Tutorials

 

[Aslanemperor]

So... There's a MUCH simpler way to do this.
1. Go into the database and select "tilesets."
2. Click the map you're using (so if it's in a dungeon, select the "dungeon" tilesets).
3. Click on one of the many empty tilesets (C or D are usually left blank).
4. Add the tileset file for "Tileset A" to that section.
5. You may now use the Tileset A tileset to create event pictures. Create events as "Above the players" with the desired wall pieces as the image. Make sure you select the right panel of the 6 options given since this is not going to auto-conform like when you put walls down normally.

Just like that, you have an invisible path within the walls. No scripts or complex event triggers. What little event work you do is only to create the image of the walls.

 

[gaydarade]

Hi! Thank you for your feedback!

You would need to significantly modify your method to achieve the following effect, which is the basis of this tutorial:

If there's a much simpler way to do this, please keep me posted; I will update this tutorial accordingly.

That said, I'll add some preview gifs to the original post to prevent future confusion.

 

[Andar]

4. Add the tileset file for "Tileset A" to that section.

doesn't work, because there is no single file for "tileset A".
Tileset A are autotiles, they are combined from five tilesheets A1 to A5, and their formats are completely different than the format required for the B to E slots.

To get an autotile into the upper layer, you would have to reconstruct the specific variant of the autotile into a tilesheet compatible with the B to E slots.

 

[gstv87]

I've been handling the possibility of having to include something like this in my game.
still in the to-do list, but I've been thinking about adding another viewport layer to the map object, a cutout effect *to the player*, and either a collection of pictures, or another map added as a child of the first.
the idea was to handle everything at viewport level, updating the mask as the player moves.
but still, all theoretical at this point, I'm still cutting and shaping the tiles.

 

[Aslanemperor]

doesn't work, because there is no single file for "tileset A".
Tileset A are autotiles, they are combined from five tilesheets A1 to A5, and their formats are completely different than the format required for the B to E slots.

To get an autotile into the upper layer, you would have to reconstruct the specific variant of the autotile into a tilesheet compatible with the B to E slots.

It certainly does work. I've done it and tested the result already, which is how I learned to do it in the first place. The autotile function only means that you have to choose from the 6 options available for the terrain in question. As a result of this, you have to be vigilant and make certain that you're choosing the right tiles so that it doesn't look obviously wrong and give the game away.

I will say that this only works if you're looking for a HIDDEN path, which is what I thought you were doing. If you want to reveal the path after you've entered it, your way clearly looks and works better. It's just more complicated.

 

[Andar]

The autotile function only means that you have to choose from the 6 options available for the terrain in question

the engine itself creates over two dozen different tiles from the twenty quarter tiles that make up an autotile. Only five of those are directly available if going your way.
The sixth tile is not used on the map by the engine itself, it is supposed to be decorative and describing the autotile, and as such often in a different scale as it is only a placeholder in the tilescreen of the editor.
Add to that that you never mentioned the user had to choose the correct tilesheet of the five available but made it sound as if everything was on a single tilesheet.

so your advice is only a very limited workaround to some tiny special cases.

 

[gaydarade]

I've been handling the possibility of having to include something like this in my game...

I'm not super familiar with the MV/MZ family, but I love the sound of this. I'd be thrilled to see the final product/any nuts & bolts that you decide to share.

It certainly does work...

Ahh, okay. I didn't know if you had stumbled on something I hadn't; I'm glad you explained further. I do appreciate the feedback though! I've toyed with the idea of self-contained events for each fade-able region, but there are a number of limitations to going that route that I'd need to work around. I've also heard that it's possible (or fairly easy??) to change the opacity of entire tilesets at once. I don't think that would work exactly for my purposes, but it could be helpful for yours down the line.

---

Cheers everyone, thanks for the thoughtful contributions.

 

[BCj]

Thanks for this! Loved the system in CrossCode