Let's start the English discussions about the data model with an introduction to its basics: games and releases per platform. Building on this thread (and to keep it simple), I will post further pieces about compilations and add-ons soon, so please don't discuss those here in this thread.
The Oregami data model has three main objects: games (G), release groups (RG), and releases (R).
1) General remarks
The relationship between G and RG is 1-n. That means that one G can have multiple RG assigned to it.
The relationship between RG and R is m-n. That means that, naturally, one RG can have multiple R in it. But also, it means that one R can be assigned to multiple RGs, too.
Because for every platform a G was released on, it gets at least one new RG, that m-n relationship solves the case of multi-platform releases. Then, the data for a release are entered once, and get next linked to for instance two RGs, one for Windows and one for Mac.
For easier thinking, it sometimes helps to replace the RG with "platform".
2) Games
Every game gets its own database entry. Okay, this sounds easy, but note that for a G entry the following things just don't matter
1) Whether the game has been released or not.
2) Whether the game was only released within a compilation or for beta testing or whatever.
3) Whether the game was released as a book listing, platform independent (say Z-Code), or on whichever platform.
These cases we will document elsewhere in the model.
We will try hard to keep all Rs of a game under one G entry, only when a R of a game comes out that severely changes gameplay (so much so that a change of genre is required), it will get a new G entry.
By now, we have only very limited mandatory data for a G entry. The user will have to provide evidence that the game existed (i.e. was released, in development, or planned), provide one or more titles for the game so it can be found within the database, and genre classification maybe (which we will discuss in another thread).
3) Release Groups
The next layer of data under the game entry is the RG. In terms of Mobygames' data model (and that of many other projects out there) this would be the platform. But at Oregami we figured that grouping releases only by their platform won't be enough, you'll see why when looking at the cases where a new RG is due:
Case 1 --> Original release
First-time release of the game's full version for a platform. That's the standard case, every platform gets its own RG.
Case 2 --> Demo / Promo release
Demo, promo or shareware versions get their own RG, so we can document them separately from the full version.
Case 3 --> Enhanced re-release
Enhanced R of a game that has already seen a Case 1. This is specifically designed for cases like The Witcher - Enhanced Edition, or the infamous "bug-free" re-releases like The Fall - Last Days of Gaia - Reloaded. Generally spoken it's for re-releases that are so different than the original that they see their own press reviews for instance, but are not complete remakes.
Case 4 --> Remake
Release of a game's remake where the gameplay stays basically unchanged, but graphics / sound / UI have been adopted to modern hardware. Note: the remake shall be marketed as such.
Case 5 --> Heavily censored release
This is for game releases that have been so severely censored that they should not be grouped together with the uncensored releases any more, as more than one German release's cruel faith was.
As for mandatory data for a RG, we will need first and foremost RG title and platform, of course. But also a release switch (released or not released), and a censorship switch, both of which will help us to better control the further data attached to the RG. An optional description of the RG should contain the (sometimes significant) differences between the platforms and such.
4) Release
The last layer of data is the R. That is the thing a collector holds in his hands or has on his hard drive after purchase. This data layer will have the most data attached to it, not all of them already modeled by us.
That's why there's no mandatory data identified, yet, except a title for the R like "German initial CD-release (PC)" or such.
But pure is the theory, let's take a look at the release tree for a fictional game:
-RG
--R
-Original release (DOS)
--German initial release
--German budget release
--US original release
--US budget release
-Demo release (DOS)
--PC Player 08/1991 covermount
--PC Gamer 09/1991 covermount
-Unreleased Amiga port (Amiga) (release switch = no)
-Enhanced CD release (DOS)
--US initial release
--US initial release (alternate cover)
--US budget release (Kixx)
-Remake release (Windows)
--US initial release
--Polish initial release
-Censored German remake release (Windows) (censorship switch = yes)
--German initial release
--German budget release
-Flash teaser release (Browser)
--Kongregate.com release
--Newgrounds.com release
And so forth.
I hope that I made the basics quite clear, please throw your questions and corner cases at us now.
The Oregami data model has three main objects: games (G), release groups (RG), and releases (R).
1) General remarks
The relationship between G and RG is 1-n. That means that one G can have multiple RG assigned to it.
The relationship between RG and R is m-n. That means that, naturally, one RG can have multiple R in it. But also, it means that one R can be assigned to multiple RGs, too.
Because for every platform a G was released on, it gets at least one new RG, that m-n relationship solves the case of multi-platform releases. Then, the data for a release are entered once, and get next linked to for instance two RGs, one for Windows and one for Mac.
For easier thinking, it sometimes helps to replace the RG with "platform".
2) Games
Every game gets its own database entry. Okay, this sounds easy, but note that for a G entry the following things just don't matter
1) Whether the game has been released or not.
2) Whether the game was only released within a compilation or for beta testing or whatever.
3) Whether the game was released as a book listing, platform independent (say Z-Code), or on whichever platform.
These cases we will document elsewhere in the model.
We will try hard to keep all Rs of a game under one G entry, only when a R of a game comes out that severely changes gameplay (so much so that a change of genre is required), it will get a new G entry.
By now, we have only very limited mandatory data for a G entry. The user will have to provide evidence that the game existed (i.e. was released, in development, or planned), provide one or more titles for the game so it can be found within the database, and genre classification maybe (which we will discuss in another thread).
3) Release Groups
The next layer of data under the game entry is the RG. In terms of Mobygames' data model (and that of many other projects out there) this would be the platform. But at Oregami we figured that grouping releases only by their platform won't be enough, you'll see why when looking at the cases where a new RG is due:
Case 1 --> Original release
First-time release of the game's full version for a platform. That's the standard case, every platform gets its own RG.
Case 2 --> Demo / Promo release
Demo, promo or shareware versions get their own RG, so we can document them separately from the full version.
Case 3 --> Enhanced re-release
Enhanced R of a game that has already seen a Case 1. This is specifically designed for cases like The Witcher - Enhanced Edition, or the infamous "bug-free" re-releases like The Fall - Last Days of Gaia - Reloaded. Generally spoken it's for re-releases that are so different than the original that they see their own press reviews for instance, but are not complete remakes.
Case 4 --> Remake
Release of a game's remake where the gameplay stays basically unchanged, but graphics / sound / UI have been adopted to modern hardware. Note: the remake shall be marketed as such.
Case 5 --> Heavily censored release
This is for game releases that have been so severely censored that they should not be grouped together with the uncensored releases any more, as more than one German release's cruel faith was.
As for mandatory data for a RG, we will need first and foremost RG title and platform, of course. But also a release switch (released or not released), and a censorship switch, both of which will help us to better control the further data attached to the RG. An optional description of the RG should contain the (sometimes significant) differences between the platforms and such.
4) Release
The last layer of data is the R. That is the thing a collector holds in his hands or has on his hard drive after purchase. This data layer will have the most data attached to it, not all of them already modeled by us.
That's why there's no mandatory data identified, yet, except a title for the R like "German initial CD-release (PC)" or such.
But pure is the theory, let's take a look at the release tree for a fictional game:
-RG
--R
-Original release (DOS)
--German initial release
--German budget release
--US original release
--US budget release
-Demo release (DOS)
--PC Player 08/1991 covermount
--PC Gamer 09/1991 covermount
-Unreleased Amiga port (Amiga) (release switch = no)
-Enhanced CD release (DOS)
--US initial release
--US initial release (alternate cover)
--US budget release (Kixx)
-Remake release (Windows)
--US initial release
--Polish initial release
-Censored German remake release (Windows) (censorship switch = yes)
--German initial release
--German budget release
-Flash teaser release (Browser)
--Kongregate.com release
--Newgrounds.com release
And so forth.
I hope that I made the basics quite clear, please throw your questions and corner cases at us now.
