Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Encounter schema redesign #277

Open
magical opened this issue Aug 3, 2019 · 2 comments
Open

[RFC] Encounter schema redesign #277

magical opened this issue Aug 3, 2019 · 2 comments

Comments

@magical
Copy link
Member

magical commented Aug 3, 2019

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?

@eevee
Copy link
Member

eevee commented Mar 5, 2021

Do you have any ideas for what the ancillary tables would look like for various encounter kinds that we currently do and don't support?

@magical
Copy link
Member Author

magical commented Mar 5, 2021

Yes, i'll try and dig up my notes. Not sure why i didn't include more detail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants