You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been thinking about this for a while. I don't know exactly what the new schema should look like, but I'm pretty sure i want the central table to look like this:
Encounter (
id PRIMARY KEY
pokemon_species_id
location_area_id
encounter_method_id
version_id
)
That is, the core relationship for encounters is the relationship between four entities: a pokemon can be found in some location via some method in some version. There is no other info in this table; details like rarity and level range can be added in other tables that augment this one. The intention is that the tuple (pokemon, location, method, version) would be unique; the id attribute is just a shorthand for other tables to reference.
The problem with the current schema is that it is too tailored to details of how encounters worked in D/P/Pt. Part of the reason we haven't added things like horde encounters in X/Y and swarms in B/W is that they just don't fit.
By designing the new schema around the simple 4-tuple of (pokemon, location, method, version), we avoid locking ourselves into details of how encounters work in any particular game, and make it easy it easy to adapt to future changes. The central table provides enough information to be useful on its own, while not requiring so much that it becomes an obstacle.
It should also be useful when ripping data for a new game. It's often the case that when a new game comes out and we find the encounter data, we don't understand all the details of what all the encounter slots are for, or what the rates are, etc. With this schema, we could add the general info immediately and then fill in the details later.
I debated whether to include the method column, since it isn't strictly necessary, but decided to leave it in. We usually have a good idea what the method is, it provides useful info to players, and we could always add an "unknown" method if need be.
Thoughts?
The text was updated successfully, but these errors were encountered:
Been thinking about this for a while. I don't know exactly what the new schema should look like, but I'm pretty sure i want the central table to look like this:
That is, the core relationship for encounters is the relationship between four entities: a pokemon can be found in some location via some method in some version. There is no other info in this table; details like rarity and level range can be added in other tables that augment this one. The intention is that the tuple (pokemon, location, method, version) would be unique; the
id
attribute is just a shorthand for other tables to reference.The problem with the current schema is that it is too tailored to details of how encounters worked in D/P/Pt. Part of the reason we haven't added things like horde encounters in X/Y and swarms in B/W is that they just don't fit.
By designing the new schema around the simple 4-tuple of (pokemon, location, method, version), we avoid locking ourselves into details of how encounters work in any particular game, and make it easy it easy to adapt to future changes. The central table provides enough information to be useful on its own, while not requiring so much that it becomes an obstacle.
It should also be useful when ripping data for a new game. It's often the case that when a new game comes out and we find the encounter data, we don't understand all the details of what all the encounter slots are for, or what the rates are, etc. With this schema, we could add the general info immediately and then fill in the details later.
I debated whether to include the
method
column, since it isn't strictly necessary, but decided to leave it in. We usually have a good idea what the method is, it provides useful info to players, and we could always add an "unknown" method if need be.Thoughts?
The text was updated successfully, but these errors were encountered: