Final documentation: Game releases
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. |
GameToGameConnection
| attribute | type | description |
|---|---|---|
| Game Relationship Type | Data List 32 | see below |
| Commercial Add-on | boolean | The most important purpose of the GameToGame connection is a fast and simple way to connect add-ons with their base game, while a more detailed connection will later be possible at RG level. But in order to get on top of the flood of DLC and fan created content, we are in dire need of ways to put every add-on into perspective. The first step of ordering add-ons is the mandatory separation of significant from insignificant add-ons that Data List 5 offers, while the second way is the commercial/authorized switches that we have here in the GameToGame connection. They should be mandatory, too. The switch for a "Commercial Add-on" shall be set when the add-on/patch/mod has been developed by full-time developers in their working hours, in contrast to hobbyists sacrificing their spare time. |
| Authorized Add-on | boolean | The mandatory switch for a "Authorized Add-on" shall be set when the add-on/patch/mod has been officially recognized by the publisher/developer of the base game as being an add-on to it. Standard case here is, of course, that the publisher of the base game also published the add-on. |
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 stand-alone releases that don't fall under the other types of this list, or when a new release of a previously released game breaks 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 / Patch / Mod (significant) | This is the case for important add-ons. As it seems hardly possible to sanely separate the classical add-on (additional content) from patches / mods / etc., we just don't do it and treat every such non-stand-alone release the same. This case 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 / Patch / Mod (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. And as we kind of open up the flood gates for user created content and the mod community with accepting insignificant add-ons, we will have more switches elsewhere in the data model to further separate the wheat from the chaff, and give the users more opportunities to customize their data displays. | |
| 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 |
Data List 32: Game Relationship Type
| id | key | text | Comment |
|---|---|---|---|
| 1 | is sequel | The game continues the story of the linked game, i.e. it directly refers to the events of it, and develops the further events based on it. | |
| 2 | is prequel | The game explains what happened story-wise before the linked game, i.e. it tells the story that led up to the events of it. | |
| 3 | is side story | The game fleshes out a story that the linked game just mentioned in some, more or less, short way, but didn't explore deeper. | |
| 4 | is successor | The game is marketed as a follow-up release to the linked game within a game series, i.e. Final Fantasy II is a successor to Final Fantasy I. | |
| 5 | is add-on | The game entry is an add-on / patch / mod to the linked game, i.e. can't be played without it. | |
| 6 | is episode of | Episodic games get a "mother" entry at game level, and separate "child" entries for all the episodes. The connection between children and mother is done with this relationship. If there's releases in the form of franchise-->season–>episode, we could probably also do that with a nested "is episode of"-relationship, i.e. the season entries become children of the franchise entry, and the episode entries become children of the season entry. | |
| 7 | is based on | The game is a clone / remake of the linked game, but somehow broke the different game criteria. This is especially useful for freeware clones of successful games like Tetris, Breakout, etc.. If there will be a superior genre classification system later on, this relationship may become obsolete. |
Open issues
References