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

Thoughts on supporting multiple games #211

Open
thommcgrath opened this issue Aug 10, 2020 · 3 comments
Open

Thoughts on supporting multiple games #211

thommcgrath opened this issue Aug 10, 2020 · 3 comments
Assignees

Comments

@thommcgrath
Copy link
Owner

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:

blueprints
computed_engram_availabilities
crafting_costs
creature_engrams
creature_stats
creatures
diet_contents
diets
engrams
game_variables
ini_options
loot_sources
maps
objects
spawn_point_limits
spawn_point_set_entries
spawn_point_set_entry_levels
spawn_point_set_replacements
spawn_point_sets
spawn_points

The mods table is questionable. Both of the following scenarios make sense:

  1. mods is global with a reference to a global games table.
  2. 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.

@thommcgrath thommcgrath self-assigned this Aug 10, 2020
@thommcgrath thommcgrath pinned this issue Aug 10, 2020
@BraniyaKz
Copy link

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 <(^^<)

@thommcgrath
Copy link
Owner Author

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.

@BraniyaKz
Copy link

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.

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