Introduction
This is the page finally documenting the data model for game releases, i. e. everything that publishers throw at us.
UML overview
Property details
Game
| attribute | type | description |
|---|---|---|
| Entry Type | Data List 5 | see below |
| Release Year | date | It's quite hard to browse the database of MobyGames by release year, because every game is showing up there which has a release in this year in the database. So I think we'll need an easy way to store the original release year of every game in Oregami's database, i. e. the year of the first release of any version of this game. We can later give the users the option to view their game lists by this year of original release, or by other release data like the original release year of a release group, or even every single release like Mobygames does. |
| Description | text | A short and sweet description of what this game is about. |
| Long Description | text | A long and comprehensive description of what this game is about. |
Release Group
| attribute | type | description |
|---|---|---|
| Title | text | |
| Reason | Data List 1 | see below |
| Description | text | |
Involved data lists:
Data List 1: Release Group Reason
| id | key | text | Comment |
|---|---|---|---|
| 1 | Original release | Every (planned) release of a game for a new platform requires a new RG. The standard case here is the first-time announcement, or release, of a game's full version for a new platform. RG's for unreleased games, i. e. games in development, cancelled games, or Vaporware, also get the reason "Original release", because development always aims for the original release of a full version. The information about the state of the release are stored elsewhere. | |
| 2 | Demo / Promo release | Release of a limited version of a game for promotional purposes. If a demo or promo version was released on a platform before the full version, a RG with the reason "Demo / Promo release" shall be chosen. This is even true if a platform saw a demo release only, like it is the case for many browser demos of Windows games, or games where development was cancelled after a demo release, because we want to clearly separate the demo versions from the full versions. | |
| 3 | Enhanced re-release | Enhanced release of a game that has already seen a Case 1 release. There's been quite some games in the past where the developers continued to work on the codebase after its first release. Be it to fix catastrophic bugs, severe performance issues, or complete the core content (The Fall), or be it to just improve upon a completed game even further and give users an enhanced experience (The Witcher). Enhanced re-releases are typically for the same platform as the initial release, otherwise it would be a Case 1 because of a new platform. We should develop some criteria for releases fitting this case or not. | |
| 4 | Remake | In contrast to Case 3, some games are not only enhanced, but remade. That means that the game is ported to a new graphics or gameplay engine, i. e. it is basically rewritten, but the gameplay stays mainly unchanged. Note: Similar to Case 3, Case 4 shall only be used when the remake is published for the same platform as the initial release, otherwise it would be a Case 1 because of a new platform, too. And the remake shall be marketed as such, i. e. the publisher should have sold the game as a remake of the initial release. This is to exclude games that play exactly like their predecessor, but are meant as a successor of the initial game, not as a remake. | |
| 5 | Heavily censored release | This is for game releases that have been so severely censored that they should not be grouped together in the same RG with the uncensored releases any more. Exemplary, some Command&Conquer games in Germany saw some heavy censorship. We should develop some criteria for releases fitting this case or not. |
Data List 5: Game Entry Type
| id | key | text | Comment |
|---|---|---|---|
| 1 | Game | This is the standard case. It is used for new games that don't fall under the other types of this list, or when a new release of a previously released game fulfills the different game criteria developed here. | |
| 2 | Compilation | This is the switch for game bundles. It shall only be used if two or more games are bundled together, or one game and at least one of its significant add-ons. This rule is to exclude minor compilations like included demos, or minor DLCs coming with the release. Furthermore, the compilation shall be marketed as just that, a bundle of games, and usually comes with its own title. This rule is to exclude re-releases of games with playable goodies included. The aforementioned "technical" compilations are dealt with elsewhere in the data model, at game release level. | |
| 3 | Add-on (significant) | This is the switch for full-price add-ons. It shall only be used when the release can't be played without the base game, and when it meets Oregami's significance criteria. Basically, significant add-ons will later be handled just like a normal game, i. e. will show up in default searches and game lists. | |
| 4 | Add-on (insignificant) | Releases which can't be played without a base game and do not meet the significance criteria are flagged here. These releases will be more hidden than the significant add-ons, i. e. the user will have to opt-in to see this stuff in searches and data lists. | |
| 5 | Episodic Game | This is for umbrella entries for games that are released in episodes. Examples would be Tales of Monkey Island, or Siege of Avalon. The "mother game" gets an entry at game level with the game type set to "Episodic game", all episodes get their own entry of type "Episode". Then they're connected using the usual add-on mechanisms, enabling us to either show the whole mother game, or every episode itself to the user. This way, we can even add releases of the whole episodic game to the "mother game" entry. | |
| 6 | Episode | see above |
Open issues
References