In the first part of my ramblings about our data model, we talked about games and release, now it's time to discuss another very demanding thing for any data model: compilations. How shall these commercial game collections be treated at Oregami?
Let's start with the basics. Since every compilation has its own release history, it needs its own database entry at game level. On the other hand, every game release with one or more DLCs bundled is technically a compilation, too, which would severely clutter up our game list with entries that most often don't have, or deserve, its own release history because they are more or less randomly bundled up in different regions, even at different retailers. But since we are serious about documenting gaming history, we should be attempting to also document the DLC crazyness somehow. So, what to do?
As stated above, the first step is real compilations getting their own database entry at game level, with all the bells and whistles of having their own RG's and Rs. To qualify for this, a compilation shall contain the following items, at least:
1) Two stand-alone games
2) One stand-alone game with at least one significant add-on (The discussion about what defines a significant add-on, we will do in another thread dealing with add-ons in general.)
Every compilation entry will be marked as such by a switch, so we can filter our data displays later on.
The linking between the compilation and the bundled games happens at the R level. When a user enters a R for the compilation, he will be able to select a compilation case for this R which will help us, as always, to better customize our data displays. Right now, we have the following cases identified:
Linking the games at R level also solves the problem of different releases of one compilation containing different game setups.
As you may have guessed, the setting of the compilation case at R level, and the mirroring of R data is independent of the game entry being a compilation. This enables us to document all these DLC bundle releases without cluttering up our game lists too much. Just enter a new R for a normal game, and mirror its R under the DLC game entries. Or it enables us to fully document Rs that have promo material included, like demos of other games. Or we won't have to create a G entry for every covermount of every press issue, if we don't want to.
Furthermore, this data setup enables us to solve another corner case: the nested compilation, or compilation-compilation, if you will. I recently saw this quite a lot, as the Stronghold Collection (a compilation of all(?) Stronghold games) gets bundled with other games quite often in Germany recently. Here, any R of the new compilation would be mirrored under the Stronghold Collection, then be re-mirrored under the Stronghold games included there. This may be an exercise in UI design, but it seems solveable nonetheless.
We recently discussed more corner cases in the German forum, but I don't want to overpower you right now.
Let me close this long post with an example (partly fictional) data modelling:
-Game
--Release Group
---Release
-Gold Games 4 (Compilation = yes)
--Original Release (Windows)
---Initial Release Germany (Compilation Case 1)
---Initial Release USA (Compilation Case 1)
---Initial Release UK (Compilation Case 1)
-Die By The Sword (Compilation = no)
--Original Release (Windows)
---Initial Release USA
---Initial Release UK
---Kixx Budget Release USA
---Bloody Classics Budget Release UK
---Gold Games 4 Release USA (from "Initial Release USA" of compilation "Gold Games 4")
---Gold Games 4 Release UK (from "Initial Release UK" of compilation "Gold Games 4")
--Original German Release (Censored) (Windows)
---Initial Release Germany
---Green Pepper Budget Release Germany
---Gold Games 4 Release Germany (from "Initial Release Germany" of compilation "Gold Games 4")
As you can see, I solved another (fictional) corner case here: the German release of a compilation contains the severely censored German release of a game while the international releases of this compilation contain the uncensored version.
All read and understood? Comments welcome.
Let's start with the basics. Since every compilation has its own release history, it needs its own database entry at game level. On the other hand, every game release with one or more DLCs bundled is technically a compilation, too, which would severely clutter up our game list with entries that most often don't have, or deserve, its own release history because they are more or less randomly bundled up in different regions, even at different retailers. But since we are serious about documenting gaming history, we should be attempting to also document the DLC crazyness somehow. So, what to do?
As stated above, the first step is real compilations getting their own database entry at game level, with all the bells and whistles of having their own RG's and Rs. To qualify for this, a compilation shall contain the following items, at least:
1) Two stand-alone games
2) One stand-alone game with at least one significant add-on (The discussion about what defines a significant add-on, we will do in another thread dealing with add-ons in general.)
Every compilation entry will be marked as such by a switch, so we can filter our data displays later on.
The linking between the compilation and the bundled games happens at the R level. When a user enters a R for the compilation, he will be able to select a compilation case for this R which will help us, as always, to better customize our data displays. Right now, we have the following cases identified:
When this compilation case is set, the user will be able to mirror the compilation release data under its bundled games, thus creating a mirrored R at each respective game RG. We should introduce a policy to ensure we don't get a mess with these entries, such as only allowing these data to be entered for all games within the compilation, and / or only allowing a change for any of the "daughter releases" via the compilation "mother release".Case 1 --> Compilation
This is the usual case. Two or more games are released as a collection which is marketed as such with its own name. Example: Gold Games 2.
Case 2 --> Original release with bonus games included
This is the case for new game releases that include bonus games or add-ons, for instance a sequel containing the first game as a bonus. The package is marketed as the game newly released.
Case 3 --> Original release with bonus games integrated
This is like Case 2, only that the bonus game(s) are integrated into the gameplay of the newly released game. Example: Day of the Tentacle, which contains Maniac Mansion on a computer inside the game.
Case 4 --> Re-Release with bonus games included
This is also like Case 2, only that it's a re-release of a game with bonus game(s) (mostly add-ons) included that the original release had not in.
Case 5 --> DLC Release
This is actually a Case 2, but is separate here to distinguish between the real Case 2 examples and this DLC plague that haunts us for some years now.
Linking the games at R level also solves the problem of different releases of one compilation containing different game setups.
As you may have guessed, the setting of the compilation case at R level, and the mirroring of R data is independent of the game entry being a compilation. This enables us to document all these DLC bundle releases without cluttering up our game lists too much. Just enter a new R for a normal game, and mirror its R under the DLC game entries. Or it enables us to fully document Rs that have promo material included, like demos of other games. Or we won't have to create a G entry for every covermount of every press issue, if we don't want to.
Furthermore, this data setup enables us to solve another corner case: the nested compilation, or compilation-compilation, if you will. I recently saw this quite a lot, as the Stronghold Collection (a compilation of all(?) Stronghold games) gets bundled with other games quite often in Germany recently. Here, any R of the new compilation would be mirrored under the Stronghold Collection, then be re-mirrored under the Stronghold games included there. This may be an exercise in UI design, but it seems solveable nonetheless.
We recently discussed more corner cases in the German forum, but I don't want to overpower you right now.
Let me close this long post with an example (partly fictional) data modelling:
-Game
--Release Group
---Release
-Gold Games 4 (Compilation = yes)
--Original Release (Windows)
---Initial Release Germany (Compilation Case 1)
---Initial Release USA (Compilation Case 1)
---Initial Release UK (Compilation Case 1)
-Die By The Sword (Compilation = no)
--Original Release (Windows)
---Initial Release USA
---Initial Release UK
---Kixx Budget Release USA
---Bloody Classics Budget Release UK
---Gold Games 4 Release USA (from "Initial Release USA" of compilation "Gold Games 4")
---Gold Games 4 Release UK (from "Initial Release UK" of compilation "Gold Games 4")
--Original German Release (Censored) (Windows)
---Initial Release Germany
---Green Pepper Budget Release Germany
---Gold Games 4 Release Germany (from "Initial Release Germany" of compilation "Gold Games 4")
As you can see, I solved another (fictional) corner case here: the German release of a compilation contains the severely censored German release of a game while the international releases of this compilation contain the uncensored version.
All read and understood?
Comments welcome.
