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
The main problem with supporting multiple games is data structures and organization. Maybe the first step is identifying the tables that are game-specific so they could potentially be moved to their own schema? I've never used multiple schemas in Postgres before, so I'm not confident this is the right approach. Scoping problems come to mind.
Regardless, the following tables (and views) are currently specific to Ark, even if they aren't used:
The mods table is questionable. Both of the following scenarios make sense:
mods is global with a reference to a global games table.
Each schema has its own mods table, which would have a column to store the game it belongs to.
Not sure which would be better. Option 1 has the advantage of guaranteeing workshop_id uniqueness. However, mods for other games may not even have a workshop_id column, and might need other columns to make sense. That would give option 2 the advantage. But it would mean every mod would require its own confirmation process. Which might not be a bad thing, even though Steam is likely the only mod provider for the foreseeable future. Hard to predict what would be needed of this table.
The text was updated successfully, but these errors were encountered:
Not sure if I'm allowed to post here, but if you do end up accomplishing this huge milestone for say, ATLAS, I'd definitely buy it. I'm sure others would appreciate it as well. The ease of use your program provides is awesome.
(>^^)> Beacon: ATLAS Edition <(^^<)
Absolutely allowed to post here. This problem will need to be solved for Ark 2, and the clock is ticking. Atlas has a small market share, but shares a lot in common with Ark, so I'm not sure if I'd do Atlas. I've been exploring the idea of supporting 7 Days to Die or Rust, but neither seem to have the level of customization that Ark has. So all I can say right now is I'm not sure what the future holds.
Thanks for the reply! Looking forward to Ark 2! And if I had to vote on the two options you're looking at above, I'd say that each schema having its own mods table sounds more organized, but overall the choice is yours, and both methods are okay.
The main problem with supporting multiple games is data structures and organization. Maybe the first step is identifying the tables that are game-specific so they could potentially be moved to their own schema? I've never used multiple schemas in Postgres before, so I'm not confident this is the right approach. Scoping problems come to mind.
Regardless, the following tables (and views) are currently specific to Ark, even if they aren't used:
The
mods
table is questionable. Both of the following scenarios make sense:mods
is global with a reference to a globalgames
table.mods
table, which would have a column to store the game it belongs to.Not sure which would be better. Option 1 has the advantage of guaranteeing
workshop_id
uniqueness. However, mods for other games may not even have aworkshop_id
column, and might need other columns to make sense. That would give option 2 the advantage. But it would mean every mod would require its own confirmation process. Which might not be a bad thing, even though Steam is likely the only mod provider for the foreseeable future. Hard to predict what would be needed of this table.The text was updated successfully, but these errors were encountered: