Open encukou opened 12 years ago
Three options here. By "generate maps" I mean making the browser build the map using div
s for tiles (see http://sanky.rustedlogic.net/etc/pokemap/out.html for an example)
The last option is probably the most feasible, but I'd still like some input. It would be nice to have seamless maps, but keep in mind maps can differ in border tiles, and Gen I Kanto isn't connected correctly (Cycling road is a tile less long than the routes to the east). Another question is what to do about version changes. Sometimes, a map changes in the third version, sometimes it does between the pair, sometimes it doesn't at all. How do we store this in the database? In any case, I want to store sprites in the database separately and overlay them. That includes items. Since Gen II and III (and to a certain extent, IV) scripting is a solved case, we could /theoretically/ parse events for item or Pokémon giveaways/trades, too. That would be really neat. What about text?
Database-wise, we'd gain some new tables: Map (location (or sublocation?), game, height?, width? tileset? maybe information on flying/teleport etc.?) Sprite (map, x, y, type (as a polymorph), ?) PokemonInstance? (Sprite, species, name, moves, ...is_trade?, is_battle?) ItemInstance? (Sprite, item, is_visible?) There is a total of three ways there can be a Pokémon: a fight (legendaries, Kecleon...); a giveaway and a trade. Do we need tables for all of these? Probably at least to separate fights, since they can't be named, nor have specific moves.. And trades, because you need a Pokémon in return, while the level is irrelevant! Three ways to get items too: hidden, visible and as a part of a script. In, for example, Gen III, regular items in Pokéballs are sprites but hidden items are signposts. Both give items through scripts, though.
All in all, this is a pretty complicated issue, so let's get it down right.