Currently the data/layouts and data/maps directories have over a hundred folders. Not only that there's a few files within each of those folders that can get lost when navigating the directories. When adding more maps, especially at the scale of multiple regions, this directory will become more and more unwieldy. Ideally we'd want a system to split this up to be more manageable, and while we're at it if there's a way to make this more modular that would be beneficial as well. If the system is "modular" this could allow us to have multiple variations of a particular region that you could specify at compile time; for example an original hoenn region and one that has newer features and modifications. So a self contained "region" should be possible. However, we should still be able to reference maps from other region slugs.
Design
So the goal is to refactor the data directory to have a slug for the region. So the data should go from:
Basically anything that describes groups of data gets put in the base directory, and anything specific for a particular map gets placed with that map name slug. Something to note here is that by moving wild_encounters.json into each individual wild_encounters, this makes json serialization and de-serialization easier to just read from a single map. Then we can create a compiled list of them all later.
At compile time we should compile each of these individual files from each region into a single master list of data at the base data directory. This includes:
*Note: Changes will need to be added to porymap to support this.
Ambiguous Design Decisions
We may benefit from compiling an intermediate version of each of the above files in each region directory. This could improve compile time as we wouldn't need to compile every file into a single master list every time one thing changes, instead amalgamate the data from an intermediate file version of these outputs at the region directory.
Tilesets were decided it should not be stored at a region level, because they're ostensibly commonly used across regions. This may change in the future should the next section happen.
We may find that it makes sense to create a common data/(text|scripts|tileset) directory as well as store region specific data in each location. This would allow for common functionality for each region to access and could de-duplicate similar text and scripts.
Description
Motivation
Currently the
data/layoutsanddata/mapsdirectories have over a hundred folders. Not only that there's a few files within each of those folders that can get lost when navigating the directories. When adding more maps, especially at the scale of multiple regions, this directory will become more and more unwieldy. Ideally we'd want a system to split this up to be more manageable, and while we're at it if there's a way to make this more modular that would be beneficial as well. If the system is "modular" this could allow us to have multiple variations of a particular region that you could specify at compile time; for example an original hoenn region and one that has newer features and modifications. So a self contained "region" should be possible. However, we should still be able to reference maps from other region slugs.Design
So the goal is to refactor the data directory to have a slug for the region. So the data should go from:
To something like this:
Basically anything that describes groups of data gets put in the base directory, and anything specific for a particular map gets placed with that map name slug. Something to note here is that by moving wild_encounters.json into each individual wild_encounters, this makes json serialization and de-serialization easier to just read from a single map. Then we can create a compiled list of them all later.
At compile time we should compile each of these individual files from each region into a single master list of data at the base data directory. This includes:
*Note: Changes will need to be added to porymap to support this.
Ambiguous Design Decisions
We may benefit from compiling an intermediate version of each of the above files in each region directory. This could improve compile time as we wouldn't need to compile every file into a single master list every time one thing changes, instead amalgamate the data from an intermediate file version of these outputs at the region directory.
Tilesets were decided it should not be stored at a region level, because they're ostensibly commonly used across regions. This may change in the future should the next section happen.
We may find that it makes sense to create a common
data/(text|scripts|tileset)directory as well as store region specific data in each location. This would allow for common functionality for each region to access and could de-duplicate similar text and scripts.Discord contact info
No response