Bridges

This page describes **bridges**, specifically the type where the player can pass over them and underneath them.

## Types of bridges

A bridge is one or more tiles which can appear either over or under the player, and this can be altered mid-game by the player's actions (namely, whether they try to walk underneath or across them - events are used to trigger changes in bridge behaviour to allow this). The key feature is that you can move both above and below a bridge.

If you can *only* move below the bridge and never on top of it, then that kind of bridge is simply made up of tiles with a high priority (to appear above the player) and terrain tag 13, "Neutral" (to make the game ignore the passability and terrain tag of those tiles).

If you can *only* move on top of the bridge and never below it, then that kind of bridge is simply the ground. Its tiles have priority 0 and terrain tag 0. Note that, if you put one of these bridge tiles on top of another tile which has a non-zero terrain tag (e.g. Surfable water), then you will need to set the terrain tag of the bridge tiles to 17 ("NoEffect") instead to ensure that the water's terrain tag doesn't "bleed through" the bridge tile and make it behave oddly.

The rest of this page describes "proper" bridges, i.e. one you can pass both over and under.

## Bridge tiles

A bridge which can be passed both over and under needs to appear below or above the player (respectively). What this means is that the bridge tiles are rendered at a different height depending on the value of a certain variable (`$PokemonGlobal.bridge`). This variable also determines whether the player obeys or ignores the passability of the bridge tiles. It is 0 if the player will go under the bridge, and greater than 0 if the player will go over it.

All bridge tiles should be given terrain tag 15 ("Bridge"). Tiles with this terrain tag will behave as described above.

Bridge tiles should be set up in the Database to appear above the player (e.g. priority 4). However, their passability should be set up as though the player is walking over them, i.e. not passable in the directions off the sides of the bridge - you shouldn't be able to walk off the bridge except at the ends that connect to land.

The above means that, by default and without any triggers to alter bridge behaviour, bridge tiles appear above the player and are completely ignored when it comes to deciding passability or terrain tag. It is the tiles beneath the bridge that matter when deciding these things.

This also means that, to save tileset space, you can also use these bridge tiles to draw bridges that can *only* be passed beneath - simply don't have any bridge behaviour-altering triggers for them (see below).

## Bridge trigger events

The code below is used to change the behaviour of bridge tiles:

* `pbBridgeOn` - Tells the game that the player is about to move over a bridge. Makes bridge tiles appear below the player, and enables their passabilities.
* `pbBridgeOff` - Tells the game that the player is no longer moving over a bridge. Makes bridge tiles appear above the player at their original priority, and causes their passabilities to be ignored.

These two lines of code are typically run by stepping on events near each end of the bridge that are triggered by Player Touch. Each end has two sets of events: a set nearer the bridge which calls `pbBridgeOn`, and a set further away which calls `pbBridgeOff`.

The exact number and positioning of each set of events will depend on how the map containing the bridge is laid out. They should be positioned to obey these rules:

* The most recent script to be run before attempting to go over a bridge *must* be `pbBridgeOn`.
* The most recent script to be run before attempting to move away or go under a bridge *must* be `pbBridgeOff`.

The events do not have to be directly next to the ends of the bridge. They could be some distance away, so long as it is not possible to approach the bridge without stepping on them. You can use large events that span the whole path to reduce the number of events used for this.

There is no harm in triggering a `pbBridgeOn` event if you have already most recently triggered another (or the same) `pbBridgeOn` event. The same goes for `pbBridgeOff`.

## The code behind bridges

The scripts `pbBridgeOn` and `pbBridgeOff` both affect the value of the variable `$PokemonGlobal.bridge`. If this is 0, bridges will appear above the player and can be passed under. If this is 1 or greater, bridges will appear below the player and can be passed over.

This variable is a number rather than true/false because it represents the height of the bridge. Typically this height is the number of cliff "strata" between the bridge's level and the level of the ground beneath it. The default is 2, but you can change it by using `pbBridgeOn(3)` or similar. The height of the bridge in the screenshot above is 2.

The value of `$PokemonGlobal.bridge` has a number of effects, as follows:

* While 0, tiles with the terrain tag "Bridge" are rendered at a height of their original priority, and their passabilities are ignored. This allows movement beneath the bridge as though it didn't exist.
* While greater than 0, tiles with the terrain tag "Bridge" are rendered on the ground (beneath the player), and their passabilities do matter. This allows movement over the bridge.
* While 0, certain methods which check what the terrain tag of a map tile is will ignore any tiles with the terrain tag "Bridge". This allows the player to surf on water beneath bridges, have wild encounters in tall grass beneath bridges, etc.
* While greater than 0, the player's reflection in still water will be coloured a solid blue and be shifted south by half a tile multiplied by this value. This only applies if the setting `TIME_SHADING` is false; if it is true, then the player's reflection disappears instead (due to technical issues related to changing both the color and tone of the reflection).

Any map transfers will call the method `pbBridgeOff`.

## Limitations and bugs

* Events will appear above or below bridges depending on whether the player is on a bridge. This will result in a visual glitch if the event is ever on-screen while the player is in the opposite position to it (i.e. the player is on a bridge while the event is beneath one, or the player is off a bridge while the event is on one).
	+ You could make an event standing on a bridge appear "Always on Top" to avoid this visual problem. There is no solution for events that are below a bridge.
* Events will always ignore bridge tiles for the purpose of moving around, and will instead use the passages of the tiles below the bridge. This can lead to events walking off the sides of bridges if they have a random move route, or being unable to move even if you want them to (if the ground beneath the bridge is not passable).
	+ Using move routes to control events going over bridges is a solution to this, albeit a limited one. Remember that there may still be a visual glitch as mentioned above, so you probably won't want to do this anyway.
* If you are beneath a bridge and an event is on the bridge (or vice versa), you can interact with the event despite the difference in height, and you will not be able to move across the tile occupied by the event.

## Tips

* Since the player appears to be more than 1 tile tall, bridges should be at least 2 tiles "high", i.e. have at least two cliff strata between the top of the bridge and the ground beneath it. This is why the default bridge height is 2.
* A bridge running vertically will be connected to a cliff edge at the southern end, whose tiles will have limited passability because they are of a cliff edge (i.e. you couldn't normally walk northwards off them even if there are passable tiles beyond). To get around this, either use duplicates of northern cliff-edge tiles which are passable to the north, or draw over the impassable cliff-edge tiles with an invisible tile that is passable.
	+ Be sure to keep track of these tiles. You will need to either ensure you're using the correct cliff tiles, or be very careful when placing the invisible tiles (because you won't easily be able to see where they are).