Page Comparison

...

First things first, every game needs an environment it can run in, an environment that consists of a HW and a SW component in most of the cases. Thus, the central data layer of Oregami's platform model shall be called "Gaming Environment" (GE). This data level is comparable to the "platforms" on other sites, as a GE is what games are released for. However, we avoid the word "platform" in the naming on purpose here, as we want to draw a clear line between the HW/SW combinations we will do, and the loose mix of HW/SW that other sites do.

The second layer of data below the GE is where the separation of HW and SW begins, as every GE will have one single "Hardware Platform" (HWP), and one single "Software Platform" (SWP) assigned to it as mandatory data. Here, we'll use the word "platform" for a piece of HW that games can run on, and for certain types of software that games need for running, but not for combinations of the two. There are cases where a HWP or a SWP is not needed, or unimportant for documentation purposes. Exemplary, PC booters (no SWP) or "platform-independent" games like browser releases (no HWP) come to mind. As both HWP and SWP are mandatory data for the GE, we will fill in the gaps with standardized entries for each case, like "No installed OS required" as SWP for booters, or "All compatible HW" as HWP for browser games.

The third data layer shall be called "sub-platforms", and will exist below every HWP and every SWP. This data facility is planned for holding very different data. Below every HWP, we will use it for documenting specific models of that HWP, or software that emulates it. Below every SWP, we can then document different versions of an OS or a browser, and also the software that emulates those. Later on, the sub-platforms will be used for tracking compatibility issues, too. Just imagine the Windows case, where the games don't run on every version of that OS, or the Amiga family of home computers, where not every game runs on every model.Generally speaking, these three layers

Generally speaking, these three layers of data is where the experts will flourish, and we will be able to better document the gaming platforms with them, especially when it comes to corner cases.

...

Yes, this is a valid concern. The video gaming platform landscape is as humongous as it is complex, so this cluttering up of our GE list is a necessary evil which we'll somehow have to work around for user experience. The answer that we came up with is an additional, fourth layer of data: "Gaming Environment Group" (GEG). We will add all these Linux GEs to a GEG called "Linux", and all the Arcade board GE's to a GEG called "Arcade", and so forth. If we then base our default data views and search options on the GEG level, we will give the casual user a graspable platform list for easy consumption, while giving the experts the optional possibility to base their views on the GE level.

Of course, we will put the GEG data level to further use, as this feature also enables people to get the bigger picture of all the releases a game has seen. Exemplary, we prolly would put all the four PlayStation consoles into a GEG called "PlayStation Console Family", and the PSP and PS Vita into a GEG called "PlayStation Handheld Family". If we'd then create another GEG called "PlayStation Family", and add all six Sony machines there, we would have the possibility to quickly show people that a game has seen a former release in the PlayStation world and, thus, chances are high it can be played at the newest flagship machine of that console family at one point in the future, too. Naturally, these additional GE's wouldn't show up on the default platform list.

Some final words about compatibility

...

First case, I already mentioned within example 3 above. The compatibility issues inside a single GE, like tracking the OS versions a Windows release runs out of the box on, will be met by the use of sub-platforms. We will be able to connect the releases of a game with every sub-platform of its GE, and store additional compatibility information like "Official support", "Startable", "Playable", or "Finishable" while doing so.

Second case is the Nintendo 3DS owner imagined above. In order to solve this case, we'll need to connect two GEs with compatibility information, where the main use case is general downward compatibility, which means that every game released for one GE runs on its successor, too. So exemplary, if the Nintendo 3DS owner wants to see every game release runnable on his machine, we will connect the two Nintendo handhelds with a "General Downward Compatibility".General Downward Compatibility".

Final, and most complicated, use case is game-specific compatibility among GE's, which means that only certain games from one GE's library are running on another GE, or even only on some sub-platforms of another GE. Here, we would first connect the two GE's in question with a "Game-specific Compatibility", then later flag all the games supporting this connection. To stay in our Gameboy example above, we would first connect the GE "Gameboy" with the GE "Gameboy Color" using a "Game-specific Upward Compatibility" called "Black/White mode". If a user later enters a GBC game, the system will ask her / him whether this game supports this specific compatibility or not, and flag the game accordingly if it does.

So you see, we have much in our pockets to improve on the existing models of platform documentation, but it will take some time coding it, and pulling a useable interface over the technical details. But it will be fun in the end, we promise.