øA slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=printpage;topic=264.0 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexc3cf.html slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&topic=264.0 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexc3cf.html.z x &dh^ ÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ ð¥ r OK text/html ISO-8859-1 gzip 8:Ö r ÿÿÿÿÿÿÿÿ Wed, 11 Mar 2020 04:24:30 GMT 0ó° ° ® 0® P® €§² ð® %dh^ ÿÿÿÿÿÿÿÿ~! r
Print Page - Original Fantasy Map Design
Board of Slick
Original Fantasy => General Discussion => Topic started by: Entroper on February 03, 2008, 03:40:51 PM
Title: Original Fantasy Map Design
Post by: Entroper on February 03, 2008, 03:40:51 PM
This post is in reference to my project referenced here: http://slickproductions.org/forum/index.php?topic=173.0 (http://slickproductions.org/forum/index.php?topic=173.0)
I've studied the way maps are stored in FF1, and I'm trying to design the format my own maps will use. Let me just give a basic rundown.
Each standard map (I haven't looked at the overworld yet) has a tileset. The tiles are simple 16x16 sprites, and each tile also has two bytes of data that go along with it. The first byte is a set of flags that determines things like whether or not you can walk on the tile, if you can encounter enemies on the tile, whether it takes you to a shop or another map, treasure, etc. The other byte is data associated with the previous (which shop to enter, which map to warp to, which treasure, etc.).
So basically, this whole set of information is tied to each tile, and as a result, the "town" tileset, for example, has about 60-70 "door" tiles that all look the same but all link to different shops and inns and what have you. The advantage of this system is that it's very easy to program; the disadvantage is that it's rather confusing for mapmakers to have to keep track of which tiles are which.
I want to ditch the above system and go with something easier for mapmakers to use. What would make the most sense? Do I keep a list in each map of "special" tiles and their functions? Is there an even better way?
Another thing to note are forced battle tiles. If I keep these in a list instead of tying the data to the tile, I could make these forced battles occur only once (I might even change most of these to monster-in-a-box-style battles, always thought it was lame that you could skip the battles by clever chest-opening).
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 03, 2008, 07:00:47 PM
Hackster has a useful function that lets you "highlight" certain tiles in the editor. The tiles appear tinted in the editor but not in the actual game. You can assign your own color scheme to help yourself immediately see auto-fight tiles, which door is which, and so on. You could try doing something like that...
Title: Re: Original Fantasy Map Design
Post by: Dragonsbrethren on February 04, 2008, 06:53:06 AM
I want to ditch the above system and go with something easier for mapmakers to use. What would make the most sense? Do I keep a list in each map of "special" tiles and their functions? Is there an even better way?
Another thing to note are forced battle tiles. If I keep these in a list instead of tying the data to the tile, I could make these forced battles occur only once (I might even change most of these to monster-in-a-box-style battles, always thought it was lame that you could skip the battles by clever chest-opening).
Perhaps this comes from my background using RPG Maker but it would make a lot more sense to me to store doors and chests as events, rather than having a ton of each, FF1 was very...strange in that regard.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 04, 2008, 11:41:31 AM
I want to ditch the above system and go with something easier for mapmakers to use. What would make the most sense? Do I keep a list in each map of "special" tiles and their functions? Is there an even better way?
Another thing to note are forced battle tiles. If I keep these in a list instead of tying the data to the tile, I could make these forced battles occur only once (I might even change most of these to monster-in-a-box-style battles, always thought it was lame that you could skip the battles by clever chest-opening).
Perhaps this comes from my background using RPG Maker but it would make a lot more sense to me to store doors and chests as events, rather than having a ton of each, FF1 was very...strange in that regard.
I like that idea, but it requires me to design the event system before I can implement the map system.
:hmm:
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 04, 2008, 09:10:01 PM
OK, here's another question. Say I just use events to handle everything. Should events be stored in each map file, tied to the map? That makes sense for chests, fixed battles, and doors, and even for somewhat more complicated events like moving the SLAB with the ROD. But what if designers want to create longer events (cutscenes) that span multiple maps? Or what if an event that occurs in one map affects the status of events in other maps? (For example, defeat Garland, return to the castle, King builds bridge.) Is it enough to allow events to reference other events by saying, for example, run event 13 in Corneria.map? That would work, but would it be too user-unfriendly? I tend to think that storing all events globally would be more user-unfriendly since it makes organization difficult.
I really appreciate your input on this, as clearly there are users here much more experienced in event scripting than myself.
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 05, 2008, 06:25:54 AM
In RPG maker, the events are tied to the map tiles on which they're triggered. So an event that spans multiple maps would be stored on the tile that triggers it, but would contain teleport commands. So to use the Garland example, you'd have a Garland tile that when you talk to it would trigger an event that looks something like:
* Display a message: "I will knock you all down!" * Fight Monster Party: Garland
And a Princess Sara tile that when you talk to it would trigger an event like:
* Display a message: "Thank you LIGHT WARRIORS" * Teleport party: (Coneria Castle, xx, yy)
So while it spans multiple maps, it's stored in the tile that triggers it, regardless of where it takes the party during execution.
Conceptually, I think most events are inherently tied to the map because they're normally triggered by either stepping on a particular tile or examining/talking to it, and which tile triggers which event is important, so I can see how keeping events separate from the map might be confusing for the person making the events trying to keep track of what event index corresponds to what map tile.
However, there are certainly some events that are not tied to tiles on the map. Of particular note would be events that are triggered by using items. The "whistle" item in FF4 for example triggers the Big Chocobo menu, but you can use it anywhere; it's not linked to the map in any way. Similarly, in FF1, using the Bottle to release the Fairy seems to me like it would be awkward to try to link directly to a map.
In terms of storing the files, there could be a separate event file, but the tiles in the map can have pointers to various events. Likewise, certain items such as the bottle could have event pointers. So building the bridge would not run event 13 in Coneria.map, it would simply run event 13 from the event file.
As far as being user-friendly, I don't imagine it being too bad as long as you can launch the event editor from the map editor (or item editor or whatever other entities trigger events).
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 05, 2008, 12:59:17 PM
Yeah, it sounds like each map will have its own events, and there will be global events in another file.
Are there event-related global variables in FF1? It seems like most event triggers are done through items, like checking whether you have the LUTE or the ROD, etc. The only global variables I can think of are the orbs.
At any rate, I think I'll allow integer variables to be associated with maps, and you can refer to them with namespaces. Something like TowerOfBabil.SupercannonDestroyed = 1 or Global.EarthOrbRestored = 1 (just examples).
I think I've got enough of a handle on this to start looking into dumping the map data from the ROM into a new format.
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 05, 2008, 03:27:16 PM
Whether or not the party has class-changed is probably a global variable/switch.
Also, although the Canoe appears in your inventory as an item, I've discovered through hacking that simply having the Canoe in your inventory is not enough to be able to traverse rivers. It seems that the "get canoe" event must also set a switch of some kind.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 05, 2008, 03:47:02 PM
Cool beans. Overworld.CanoeObtained = 1.
I think I'm getting this hammered out pretty well now. :) I'm into the details of how to save and load the event and variable states in a save file, and how to manage the system in memory during the game.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 06, 2008, 08:22:27 PM
Next question: Store "regular" and "overworld" maps in the same format or separately?
There are two major differences between the overworld in FF1 and the rest of the maps. The first difference is that the overworld stores additional flags for things like land fight, river fight, ocean fight, landing your airship, docking your ship, using your canoe, etc, and does NOT have any treasure chests or NPCs. The second major difference is in enemy domains: regular maps have only one "domain" listing which monster parties you can fight and their respective probabilities. The overworld is divided into 64 sections, each with its own domain. I would really prefer to have a unified map system (who says you can't canoe around in an underground lake in a cave, and meet NPCs and find treasure all on the same map?), but I'm scratching my head trying to find the sweet spot of making domains powerful but not complicated.
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 07, 2008, 09:20:28 PM
Well if you want people to be able to use your program to create something like Dawn of Souls, you'd need to allow canoe-ing and airship-ing inside dungeons.
Is there any reason you couldn't have a unified map system that can create overworlds and dungeons alike?
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 07, 2008, 09:34:43 PM
Well that's what I'd like, just trying to figure out the monster domains thing.
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 08, 2008, 07:20:08 AM
Well I guess for each map you could have a list of "zones" each of which would contain:
* A set of co-ordinates indicating its borders * A list of monster groups that you could encounter if you run into a random fight in that zone
The overworld would have 64 of such zones of equal size while most dungeons would have one per floor.
Whenever the player triggers a random encounter, check to see which of the current map's zones the player is in, then go to that zone's random encounter list and pick a fight accordingly.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 08, 2008, 02:07:15 PM
Would it be worth it to implement a "paint by numbers" scheme, where you can assign arbitrary domains (not necessarily rectangular)?
EDIT: Don't worry, I wouldn't get rid of PNEOP. ;)
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 08, 2008, 03:34:25 PM
Quote
Don't worry, I wouldn't get rid of PNEOP. ;)
Of course not. It's not a bug, it's a feature!
As for the paint by numbers scheme I assume you mean assigning each tile its own pointer to one of the domains. I see no reason why you couldn't do that... it just might be more annoying to edit that way. It would certainly have an advantage in a situation where you wanted something like an oddly-shaped desert where you fight a hard monster or something. Something like that could in theory be done with the rectangular zones scheme but it might be a bit of a chore, although I think that most of the time, the zones will probably be rectangular (or could easily be made rectangular without causing many problems) and to have to assign each tile a monster domain may be annoying for large maps.
That's just my initial impression though. I'm sure whatever you decide will be just fine.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 08, 2008, 03:39:13 PM
It would certainly have an advantage in a situation where you wanted something like an oddly-shaped desert where you fight a hard monster or something.
I think you just sold me on it. I was trying to think of situations where you would really want to use that, and that's exactly it. Done. Tonight I might finally define a map file format. :)
Title: Re: Original Fantasy Map Design
Post by: JCE3000GT on February 09, 2008, 12:01:25 AM
:picsorstfu:
I love that smile.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 09, 2008, 12:03:25 AM
http://entroper.no-ip.org/Pictures/OF/
:)
Title: Re: Original Fantasy Map Design
Post by: Pinkpuff on February 09, 2008, 06:14:06 AM
Quote
I think you just sold me on it. I was trying to think of situations where you would really want to use that, and that's exactly it. Done. Tonight I might finally define a map file format. :)
Awesome! Just a suggestion for the map editor though, if you go with this scheme, you might want to include a sort of rectangular "domain paint" tool that lets you set the domain of each tile in a large rectangular area at once. I'm just picturing trying to paint a 256x256 map tile by tile and I see myself falling asleep real quick:
Set tile (1, 1) to domain 1. Set tile (1, 2) to domain 1. Set tile (1, 3) to domain 1. ... Set tile (1, 64) to domain 1. Set tile (2, 1) to domain 1. Set tile... zzzz..
As opposed to:
Highlight (drag mouse) from tile (1, 1) to tile (64, 64). Set all highlighted tiles to have domain 1.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 09, 2008, 01:05:11 PM
I think what I'll do is have a fill function. So you can draw the outline of your domain and then fill it in.
Title: Re: Original Fantasy Map Design
Post by: Imzogelmo on February 25, 2008, 10:30:24 AM
Just found this topic, and as I was reading, I thought "why not let each tile have it's own domain settable?", but then that came up. :happy: Then I thought, "well, you'll need a way to fill in several domains at once for editing", but then that came up too.
So then I thought "why not make it even more flexible, like FF6's system?" That is, domains still have a set of terrains where encounters can occur (4 different ones, determined by tile, of course 4 is arbitrary to the game), and then each of those can have multiple formations that you can face (again, FF6 uses 4 per terrain, but that's arbitrary). So a domain then resolves to a sort of script that says "If this is a forest tile, trigger a battle of set A, else if this is a desert tile, trigger a battle of set B, etc."
This could still be done with a "paint by numbers" scheme. I guess my real point is that the domains could just be that- numbers- and then you could have a script to decode what that numbered domain means. That way, you could have a single domain for land and sea (in a given area), and within the domain script you switch based on whether on foot or in the ship (for an example). You'd need something like that anyway for setting backgrounds in battle. I realize it's not quite as useful for land, but if you allow land tiles to change via events, then it would prevent a normally swamp-only battle from occurring in a desert (if the tile changed from swamp to desert, that is).
Title: Re: Original Fantasy Map Design
Post by: Imzogelmo on February 25, 2008, 10:43:47 AM
Also, for the event triggers, you may want to have events set to trigger on a logical combination of any of the following: "facing up, facing left, facing down, facing right, stepping on, talking/action to". In FF1, the key items are global in nature, but those don't have to be the only ones (of course that would be a designer's decision, no reason to limit the format).
Speaking of events, each map will have to have its own "onLoad" event. If map tile data can change, this will be essential so that changes that can survive a map reload will not be lost.
Title: Re: Original Fantasy Map Design
Post by: Entroper on February 25, 2008, 12:01:38 PM
Yeah, I've been working on how to make tile data changes persistent. I'll make a specification for that when I start working on the save/load system. There are a number of things going on there already, like saving the event enabled/disabled states.
As I finished up the event spec, I realized I didn't have any information on how events would be triggered. That's probably bad. :) Off the top of my head, I want triggers to happen when stepping on a square or when pressing the action button while facing a square/sprite. I think for direction facing, you can test that in the script itself (I'll need to add conditional operators for that).
What other event triggers do I need? I think I can support all of FF1's quest with "walk onto square" and "action button at square/sprite" triggers, but certainly there must be other useful ones?
Title: Re: Original Fantasy Map Design
Post by: Imzogelmo on February 25, 2008, 12:24:28 PM
For how the events get triggered, I can mostly draw from experience with FF6, which has several ways (and this gets convoluted very quickly, so bear with me...)
Tile triggers: These always trigger by stepping on a tile (although some of them branch to "do nothing" when certain conditions are not met, for instance, the event it is set to do once has already occurred).
Map loaded triggers: Each map has one and only one. This can be used to load different music conditionally, or to make tile-patches to a map (like for opened treasure chests, for instance, although FF6 has some other automated way of doing that which takes the chests out of the picture). These should be able to handle whatever changes you expect the map to need (FF6 has to reload the map any time you visit the subscreen).
NPC triggers: These are triggered by "talking" to an NPC. That's handled by a pointer to an event. Interestingly, FF6 has an event command to "change event pointer for NPC xx" so that you can actually have it change based on another event. This is only mildly useful, as it has no inherent memory, so you still need event bits if you want the changes to be persistent.
Event triggers: Well, technically, you're just calling a script from another script. This is obviously important for several reasons.
Item-use triggers: This is not too common, but an example is the use of a Tent (changes the sprite, music temporarily goes to nighty night, saves are written out, etc.). These are hardcoded in FF6, but with a good automated way of doing it from the item data, this could be very useful.
I'm sure there's at least one more that I'm forgetting...
Title: Re: Original Fantasy Map Design
Post by: Entroper on March 02, 2008, 10:54:42 PM
Thanks. I'm going to greatly appreciate all the feedback I can get from users with scripting experience from previous FF games. :)
So it sounds like the only ones that I need to code in the event header itself (thus far) are 1) stepping on a tile and 2) pressing the action button when facing a tile or sprite. Items, map loads, and events can just call other events, so that doesn't need to be specified in the events they're calling.
Title: Re: Original Fantasy Map Design
Post by: Aerdan on April 16, 2008, 02:29:22 AM
Re monster encounters...
Set up a list of tiles wherein each tile is part of a specific domain, then set zones so that you can control formations per domain per zone. This way you can arrange the formations per-domain, with a per-formation byte to set the zone. As an added bonus, you don't have to prod the maps in any way other than for events and tile-placement.