A variety of battle backgrounds
This is a pretty handy default, although it may not be sufficient if you'd rather have a more fine-tuned system (for example, I don't think it looks right to have an open seas background when you're paddling down the river). Normally, for dungeon maps, you'd only really need to set a single background for more or less all of the encounters, and this can be done in the map properties. But because the world map often involves multiple varied terrains, a single determined background just isn't going to cut it.
Now, you can, I believe, use region ID codes (which can be freely placed on maps, and are usually used to designate regions containing a specific set of encounters) to trigger different battle backgrounds, although I feel that may introduce some confusion for the developer, as it splits the use of region IDs across two separate purposes. Terrain tags may also be used, which are linked to the actual tile graphics themselves, although you can only denote 10 such tags (as opposed to the 64 region IDs), so they are much less useful in this case. I ended up utilizing the tile IDs instead, which are ideal - since you can designate the battle background through event (without mucking up the way anything works on other maps) - but a little tricky because you have to figure out what the tile IDs are for the tiles you're using in the first place.
I ultimately decided that I would have to use my own terrain-specific background system while I was working on an airship random encounter, inspired by the Doom Gaze enemy from Final Fantasy VI. For developers' reference, action button and touch events don't trigger while you're on the airship (but they do on the boat or ship). Otherwise, you'd find yourself entering towns in your airship just by flying over them, and that would be...awkward, to say the least. But, autorun and parallel process events will still run when you're in the airship, and so I used the latter to rig my airship random encounter.
Doom Gaze attacks sporadically when you're flying around in the airship in FFVI
It worked swimmingly, except that the system-designated battle background was, like the other vehicles, the ship background. The ship floor looked fine enough, but having the ocean, instead of the sky, in the background, was all wrong. So I manually set the background for that encounter to the one I wanted. Problem was, after I got off the airship, and ran into an encounter on a snowfield, the background was still specified as the ship+clouds background I had set for the airship encounter. And though I could respecify the background after getting off the airship, I couldn't revert it to its default unspecified state, thus triggering the automatic terrain-dependent backgrounds the system falls back on (trying to set the background to "none", by the way, just causes it to use a black screen as the background).
So I figured, if I want this to work right, I'm just going to have to knuckle down and create a system of my own that selects the backgrounds I want. The good news is that it's doable just by using a single parallel process event (per overworld map, if you have more than one) that recurringly checks the player's x and y coordinates. The bad news is that figuring out the tile IDs that the event checks the coordinates against was a bit of a pain in the ass. You'd think this was one of those things listed in the owner's manual under "specs" or something (and maybe it is - but I couldn't find it). At any rate, it is possible to brute force it, enough to get the pattern down and fill in the blanks.
First, though, you have to have a basic understanding of how autotiles work (which most of the overworld terrain tiles are). My first thought was that I could look at the tilesheet, and just count the tiles 0, 1, 2, 3, from top left to bottom right, but the way the autotile system works is that every autotile on the sheet corresponds to some 47 different tiles (depending on how its borders are oriented). Not only that, but the first tile begins at ID number 2048, and not 1 or even 0. This tutorial by Nick Palmer is an excellent discussion of how those autotiles work, but it stops short on listing the actual tile IDs, or even identifying which tiles in the pattern are the first and last (which would facilitate identifying the number at which each terrain type gives way to the next one).
So I just figured it out myself. And I'm gonna tell you what they are, so that if you find yourself in my position, you won't have to repeat all the grunt work I've just done. First, I played around with the shallow sea tiles (because that's the first terrain on the tilesheet), and rigged up an event that displays the tile ID of the tile the player is standing on when he presses the shift (dash) button, so I could jot them down. As it turns out, the tile with the lowest numerical ID within any autotile set is the one with no borders (the "center" tile), and the one with the highest numerical ID is the one with borders on all sides (the "lone" tile). After figuring that out, it was simple enough to just find out the lowest and highest IDs for each of the subsequent terrains. For what it's worth, though, here's a graphical representation of each of the 47 tiles in the autotile set, in order, from lowest numerical ID to highest. I assume the other terrains work similarly, and at least, the lowest and highest tiles have born that theory out.
The ID range for the rest of the terrains in the A layer Field tileset ("World_A") are as follows:
White numbers denote layer 1 IDs, green numbers denote layer 2 IDs.
Note that the tile ID actually has three layers, which correspond to the graphical layers on which the tiles are laid down. Layer 3 corresponds to the B, C, D, and E layers, so, in the case of the Field tileset, that would be towns and castles and things like that. The A layer, which is the one we're dealing with, includes both layers 1 and 2 of the tile IDs. The trees and mountains and things in the lower right corner of the tilesheet go on top of the ground, so they are all designated with layer 2 IDs. You'll notice, also, that the deep sea tiles are marked by layer 2 IDs. This is because they are actually placed on top of the shallow sea terrain. This is also why the sea add-ons, like the rock shoal and the icebergs, when placed on deep sea tiles, change that tile to shallow sea, instead of going on top of the deep sea. Some of these terrains have IDs that do not span the full 47 values; this is because they are not autotiles (they don't have variable borders). Incidentally, if you wanted to find the layer 3 tile IDs for the B, C, D, and E layers, you'd probably have a much easier time, as they don't include autotiles, and you can probably just count them off from the tilesheet (but I haven't actually tried it out).
Layer 2 (or 3) tiles placed on top of layer 1 (or 2) tiles (like trees on grass, or deep sea over shallow sea) will retain the lower layer ID of the ground tile, in addition to the upper layer ID of the add-on. This is something you'll have to account for in your conditional branches if you're designating different behavior for different combinations of layers. For example, shallow sea and deep sea tiles will both have layer 1 IDs in the range of 2048-2094, but the shallow sea tiles will all have layer 2 IDs of 0, whereas the deep sea tiles will have layer 2 IDs in the range of 2096-2142. As another example, pine tree forests will always have a layer 2 ID in the range of 3056-3102, but their layer 1 ID will be determined by the type of terrain the trees are sitting on. Tiles like the swamp tree, lava bubbles, waterfall, cloud, pond rock, and whirlpool, despite appearing to be add-on tiles, are actually stand-alones, and are designated by their own unique layer 1 IDs. It is also worth noting that for the 16 types of terrain in the bottom left corner of the tilesheet, each tile with a layer 2 ID is automatically placed upon (and therefore carries the layer 1 ID of) the terrain to its immediate left (exactly like the deep sea goes on top of the shallow sea).
tl;dr - If you ignore everything else, the real meat of this post is that last image above. I hope it proves useful for somebody somewhere someday.
No comments:
Post a Comment