Sorting out the platform mess

 

Introduction

It's no secret that every game needs some hardware (HW) to run on, and most of them also need some basic software (SW) like an operating system (OS) on top of that HW. But the traditional platform model we see at many, if not all, video gaming sites out there is a wild mix of HW and SW. You see consoles like the PlayStation, OS's like Linux or Windows, "platform-independent" SW like a Browser, or even Arcade boards lumped together into one single layer of platform data. This get-together of all the different technical platforms in one place leads to quite some problems when it comes to documenting game releases.


When you see a platform like "PC", "DOS", or "Mac" the next time you visit another gaming-related site, please take a moment to try to research what those even mean. Most likely you will come to the conclusion that "PC" incorporates all games released for Microsoft's desktop OS's since the 80s, "DOS" covers all the games released for MS-DOS on IBM-PC-compatible HW, and "Mac" refers to every machine called "Macintosh" from the beginning, regardless of the Apple OS installed. While this is not ideal, as there is much more to "PC" than IBM machines, and much more to "DOS" than Microsoft, the majority of the users is happy with it, because only few have ever heard of DEC PDP, CP/M, or the old Mac OS. And user happiness is something to be considered when planning for Oregami, because we don't want to turn it into an expert-only project.

So we thought hard about how to improve on the existing platform models while not putting the non-expert users off, and came to a first conclusion in that we'll need to make the platforms available to our users, which they can find on the box their game came in. Thus, if a collector can read "Amiga" or "IBM PC" on a game box, he / she should be able to find these platforms within Oregami. But on the other hand, we want to implement a platform model that's more fine-grained and more suited to the rich history of gaming HW, so the experts among us may bath in all the data they're interested in. Can both of these feats be achieved together? We strongly think so.

An updated approach

Let's start with our ideas for an updated platform model, i. e. let's first describe the expert side of things.Deep down below the following examples, we will come back to the user experience.
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 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.

 

Thinking through examples

Having said all that, let's take a look at some examples, and how they fit into this model:

 

1. Typical consoles and handhelds

Examples:

• The GE "PlayStation" would be defined by the HWP "PlayStation Console" and the SWP "PlayStation BIOS".
• The GE "PlayStation 3" would be defined by the HWP "PlayStation 3 Console" and the SWP "FreeBSD OS".

Starting out easy, this is the typical console or handheld example. The console hardware is defined as HWP, and gets all their different models and emulators assigned as sub-platforms, like the HWP "PlayStation Console" would get all the different PSX models and all the PSX emulators in its different versions as sub-platforms. With all these sub-platforms in place, we will later be able to track which PSX game doesn't play well on which model of the console, and which emulator version supports which game. And as the PSX just has a BIOS, and no OS, we will fill the SWP with the value "PlayStation BIOS".

Modern consoles mostly have a real OS working below the BIOS, so we'll use that as SWP instead. Exemplary, the PlayStation 3 has a FreeBSD variant called "CellOS" installed on it, so we would define "FreeBSD OS" as SWP for it, then add "CellOS" as a sub-platform to it.

 

2. DOS / PC wars of the 80s

Examples:

• The GE "DOS PC" would be defined by the HWP "IBM PC compatible HW" and the SWP "MS-DOS OS".
• The GE "IBM PC compatible booter" would be defined by the HWP "IBM PC compatible HW" and the SWP "No installed OS required".
• The GE "Kaypro II" would be defined by the HWP "Kaypro Z80 Machine" and the SWP "CP/M OS".
• The GE "DEC Rainbow (CP/M)" would be defined by the HWP "DEC Rainbow 100" and the SWP "CP/M OS".
• The GE "DEC Rainbow (MS-DOS)" would be defined by the HWP "DEC Rainbow 100" and the SWP "MS-DOS OS".
• The GE "CP/M @ Z80 Machine" would be defined by the HWP "Z80-compatible HW" and the SWP "CP/M OS".
• The GE "MS-DOS @ x86 Machine" would be defined by the HWP "x86-compatible HW" and the SWP "MS-DOS OS".

The 80s are a true nightmare when it comes to video game documentation, and that for a simple fact: many games released for home computers in this era had the bad, but mostly necessary habit of partly or completely bypassing the machine's OS, and directly interacting with BIOS and / or HW. This was due to the OS eating up too much ressources which were needed for fast and beautiful games, or not having all the hardware access features needed for the games. These limitations resulted in many games not running on machines with slightly different HW than what they were coded for, even when the same CPU or OS did its service there. As I said, a nightmare.

Back then, many companies came up with their very own home computer and software for it, and the subsequent battles for market leadership saw two clear winners: Microsoft with MS-DOS, and IBM with its Personal Computer (PC). Both, when combined with its many clones, were one of the standard gaming combinations of the 80s and early 90s with many,many gamesreleased for it, and this so much so, that when there is talk about the DOS gaming platform even today, this HW/SW combination is spoken about most of the time. And while I mentioned our basic rule of "A GE is what gamers can read on their game box!" above, it is precisely this rule that needs to be broken here, because it won't get us far.

The game publishers of the time were quite creative when it came to the advertizing of what GE their game was released for, this being especially true for the MS-DOS PC's. The labels on their game boxes started with a simple"PC" or "IBM", combined these two to "IBM PC", often used the more verbose "IBM PC & Compatibles", used hardwaremodels or processorgenerations, mentioned the OS, or combined some of the before mentioned methods. So you see, creating a GE for every of these label classes would be rather pointless. Instead as a first step, we will do what other sites do here, and define a GE called "DOS PC", with a HWP "IBM PC compatible HW" that embraces all of its different models, and all of its many clones, and a SWP "MS-DOS OS" which sums up all the different versions of Microsoft's OS. Both the HWP and SWP will also get DOSBox as a sub-platform, because this program emulates both MS-DOS and the respective HW. As a second step, we will have to think about ways to show the user our GE "DOS PC" when he enters "IBM", "386, or "AT" into our site search.

With the eventual standard out of the way, we can take a look at all those HW / SW combinations that didn't quite succeed.

There were games seeing a release that completely ignored the machine's OS, either because they directly accessed the BIOS and / or HW, or because they brought their own little OS with them on the medium. These games are commonly called booters, and the majority of them were released for IBM PC compatibles, too. This means that we would create a GE "IBM PC compatible booter" first, and assign the HWP "IBM PC compatible HW" to it, and a generic SWP called "No installed OS required" or something like that. If the need arises, we will create booter GE's for other HWP, too.

And then there's the rest. I'm not talking about Apple, Atari, or Commodore home computers from the 80s here. These are all quite good documented, with huge game libraries, so won't be too much of a problem to get into our platform model. I'm talking about the more obscure hardware releases, the CP/M running machines with Zilog Z80 CPU, or the non-IBM-PC-compatible boxes with x86 HW. As we need to document those, too, we'll need to remember the basic rule of thumb for new GE's: a GE is basically what a collector can read on his game box. Following that, we'll have to divide the above machines in two cases:

The first case is systems that explicitly had games released for it. Those machines will get their own GE at Oregami, some examples of such HW can be seen here. There is, for instance, the Kaypro II there, a Z80 machine running on CP/M OS. For this computer we would create the GE "Kaypro II" consisting of the HWP "Kaypro Z80 Machine" (because Kaypro later produced x86 boxes, even IBM compatibles, too), and the SWP "CP/M OS". Another interesting machine is the DEC Rainbow 100 which even had two CPU's in it, a Z80 controlled by CP/M, and a 8088 of the x86 family controlled by CP/M-86 or MS-DOS. When you take a look at this Infocom price list from the year 1988, you'll notice that Infocom had, respectively, two DEC Rainbow releases at sale: a CP/M and a MS-DOS option, which makes two GE's for Oregami. The first is "DEC Rainbow (CP/M)", the second naturally "DEC Rainbow (MS-DOS)", both of which featuring the "DEC Rainbow 100" as HWP, but differing in the different OS's as SWP.

The second case is the real underdogs, the long tail of personal computing of the 80's, machines that were so unsuccessful that they not even had games explicitly released for them, and that I don't even have an example right now. If we want to document these, too, at one sunny day in Oregami's far future, we will create generic HWP's for them, divided by CPU, and assign these boxes there as sub-platforms. So, basically, there will be two generic HWP's called "Z80-compatible HW" and "x86-compatible HW", and for manufacturers who produced more than a few machines, we will create specific HWP's like the Kaypro example above. Since CP/M ran on almost every Z80 machine, and MS-DOS on almost every x86 machine, we will create two respective GE's called "CP/M @ Z80 Machine" and "MS-DOS @ x86 Machine", with which we will be able to track the game compatibility of these machines later on. These two generic GE's will even feature some game releases, some of which you can see on the above Infocom price list at line eight.

So much for the HW mess of the 80's, I am in good faith that we will be able to broadly document it with our updated platform model.

 

3. Rise of Windows

Examples:

• The GE "MS Windows PC" would be defined by the HWP "x86 compatible HW" and the SWP "MS Windows PC OS".
• The GE "MS Windows NT @ DEC Alpha Machine" would be defined by the HWP "DEC Alpha compatible HW" and the SWP "MS Windows PC OS".

The first half of personal computing of the 90's was also dominated by so-called IBM-PC-compatible hardware, despite IBM having long lost its market leadership. But with the introduction of the Microsoft Windows desktop line of OS's (since Windows 95), and its hardware abstraction layer coming with it, the focus of the HW vendors shifted from compatibility to an IBM PC to Windows compatibility. If Windows would run on your machine, your customers would have access to its huge software library, making this a prime selling argument.

And since Windows of the 90's was (almost) a single-platform OS, running (almost) exclusively on x86 HW, and all the Windows versions down to the DOS extension Windows 3.1 were widely downwards compatible to each other, we just need one GE at Oregami: the "MS Windows PC". This GE would be defined by the HWP "x86 compatible HW", not "IBM PC compatible HW" any more to reflect the above mentioned changes in the vendor landscape, and the SWP "MS Windows PC OS". We would then create sub-platforms to the SWP with all the different Windows, ReactOS, and Wine versions, with which we'll later track the compatibility of a certain game release across the Windows family. And what about a HW model that both runs MS-DOS as IBM-PC-compatible HW, and Windows as x86-compatible HW? Well, just connect it to both respective HWP's.

Generally lesser known to the informed public, the Windows sub-family NT supported much more than only x86-compatible systems, making these products multi-platform OS's (more on that issue below on Linux). Multi-platform support was later dropped with the release of Windows 2000. This means that, besides our mandatory "MS Windows PC", we will probably have additional GE's for Windows called "MS Windows NT @ DEC Alpha Machine" or something like that, if there ever shall be someone researching games for Windows NT on other platforms.

 

4. Linux and other multi-platform OS's

Example:

• The GE "Linux @ x86 Machine" would be defined by the HWP "x86-compatible HW" and the SWP "Linux OS".

Let's drop some additional words about Linux, or multi-platform OS's in general. According to its Wikipedia entry, Linux currently supports 28 different HW architectures, which is astounding, and a nightmare for every video game researcher. So, the big question to ask is whether a game which is "released for Linux" will run on any of these 28 platforms? The short answer to that is: most probably no.
From time to time I watch Linux development a bit, and witnessed cases while doing so, where an officially supported HW architecture was broken across several Linux releases to the point that it didn't even compile. Obviously nobody of the developers / users noticed, or nobody cared, because this is only possible if said platform wasn't tested for a long time. This is due to Linux being a collection of 28 different HW ports, or tiny OS's, which share basic technical concepts, and quite some common code. And every one of these ports is maintained by a different team, and thus is in different shape. And if a game shall be released for any of these Linux ports, it prolly would need re-compiling on the respective HW, which boils down to a theoretical 28 different releases of the game "for Linux" in the end. So, for Oregami, it's just not possible to have one single GE called "Linux", and then maintain a compatibility matrix incorporating all the different Linux versions on all their supported architectures for every game.

Following that, we will firstly focus on the most successful Linux port for gamers, the port for x86-compatible computers. Later on, if the need arises, we can expand our coverage to other Linux ports. Said x86 GE for Linux could be named "Linux @ x86 Machine" or similar, and would also have "x86-compatible HW" as HWP, just like Windows above because Linux runs on the same boxes, and "Linux OS" as SWP, with all its different versions as sub-platforms. This pattern goes for other multi-platform OS's as well, say FreeBSD or MorphOS, just to name a few.

 

5. The Amiga ecosystem

Examples:

• The GE "Amiga" would be defined by the HWP "Amiga M68K Machine & Compatibles" and the SWP "AmigaOS".
• The GE "AmigaOS 4 @ PowerPC Machine" would be defined by the HWP "Amiga PowerPC Machine & Compatibles" and the SWP "AmigaOS 4".
• The GE "CDTV" would be defined by the HWP "CDTV console" and the SWP "AmigaOS".
• The GE "Amiga CD32" would be defined by the HWP "Amiga CD32 console" and the SWP "AmigaOS".
• The GE "MorphOS @ PowerPC Machine" would be defined by the HWP "PowerPC-compatible HW" and the SWP "MorphOS OS".
• The GE "AROS @ x86 Machine" would be defined by the HWP "x86-compatible HW" and the SWP "AROS OS".

A Commodore Amiga 500+ was my first very own home computer, and thus holds a special place in my heart. But I have to admit that I never really did research about this family of computers, prolly because I gave my machine away for nothing some 20 years ago, long before I developed a deeper interest in video game documentation and hardware. This situation needs to be remedied, and a first step in the right direction is my research as to how the whole Amiga hard-/software ecosystem fits into Oregami's GE model.

With the first looks into the Amiga models released over the years, and the many different variants of its exclusive OS AmigaOS, there's one thing immediately coming to mind: a striking similarity of this home computer family with the IBM PC / MS-DOS family discussed above. Both featured a steady flow of different models with improving hardware, a single-platform OS that improved with it, and a huge game library that was widely compatible among the models / OS versions, when respecting the minimal system requirements, of course. We even have three (main) graphics architectures in both worlds, the famous CGA / EGA / VGA in the PC world, and the OCS / ECS / AGA chip sets in the Amigas. This similarity means that, like the IBM PC / MS-DOS case above, we will just need one GE to represent this huge amount of games. Let's call it "Amiga", and assign a HWP called "Amiga M68K Machine & Compatibles" to it, as well as its well-known "AmigaOS" as SWP. The HWP will get all the Amiga models by Commodore and all the clones by other companies assigned to it, the SWP all the Kickstart (ROM-resident part of AmigaOS) versions until 3.9.

The informed reader may wonder about AmigaOS 4 and the newer AmigaOne machines that are sold even today. These machines are a notable exception to the one GE rule for Amiga, because they basically used the brand for boxes that were very different to the machines by Commodore, the most glaring difference being a new processor architecture used, the PowerPC. AmigaOS was ported to the new architecture, and support for the old Motorola-based models was dropped. So, this is just a new GE that shares the brand Amiga with the main one. Let's call it "AmigaOS 4 @ PowerPC Machine", where the HWP would be "Amiga PowerPC Machine & Compatibles", including some special configurations of older Amigas with PowerPC accelerator card, and the SWP would be "Amiga OS 4".

Commodore also released two CD-ROM multimedia consoles to the public which were based on Amiga technology. The first one, released in 1991, was called CDTV, an abbreviation of Commodore Dynamic Total Vision, and basically consisted of an Amiga 500 with a CD-ROM drive, built into a nicely designed case and controlled with a game-pad-like remote control. The system ran an enhanced AmigaOS 1.3, and had a manageable library of some dozens of games going for it. The successor of the CDTV was already released two years later. It was called Amiga CD32 and was the first 32-bit console on the Euopean market. This machine was built on top of the Amiga 1200 with AmigaOS 3.1 technology, but had a special additional chip named Akiko which should ease the use of 3D graphics. Although the game library was bigger than that of the CDTV, the Amiga CD32 didn't sell well due to some problems, and therefore couldn't rescue Commodore from disappearing. As these two consoles had all their games specifically released for it, even on a medium that was quite uncommon to other Amiga models, they will get their own GE each. First one gets the GE "CDTV" with the HWP "CDTV console", the second box gets the GE "Amiga CD32" with the HWP "Amiga CD32 console", while both get the SWP "AmigaOS" assigned.

The last touch of the lively Amiga community that shall be covered here, is two more alternative OS's. Besides the above mentioned AmigaOS 4, the single-platform MorphOS and the multi-platform AROS deserve a mention in this section. MorphOS is an attempt to create an OS for modern computers that can run legacy Amiga software. It is currently only available for the PowerPC architecture, and achieves its binary Amiga compatibility by a built-in emulation of the Motorola 68K architecture, which the classic Amigas were equipped with. This OS would get its own GE called "MorphOS @ PowerPC Machine" with a HWP "PowerPC-compatible HW" and a SWP "MorphOS OS". AROS, on the other hand, doesn't aim for binary compatibility with AmigaOS, but for API compatibility and portability. This means that developers can re-compile their old Amiga software on AROS-supported modern architectures without deeper problems, creating a new release of the software in the process for this new architecture. If the software is a game, it can then be contributed to Oregami using one new GE per supported architecture. An example would be the GE "AROS @ x86 Machine" with the HWP "x86-compatible HW" and the SWP "AROS OS" assigned.

So much for the rich and prospering Amiga family, I truly hope that Oregami will feature rather complete libraries of all its games and HW one day.

 

6. Platform independence

Examples:

• The GE "Browser / HTML" would be defined by the HWP "All compatible HW" and the SWP "HTML Interpreter".
• The GE "Z-Machine" would be defined by the HWP "All compatible HW" and the SWP "Z-Code Interpreter".

When someone uninformed reads the term "platform-independent" games for the first time, two things may come to his / her mind: these games don't need HW to run on, or these games run on any HW. Both assumptions are not true, of course. But what does platform independence mean, then, and how to press it into Oregami's GE data model?

Well, I started this longish post stating the fact that every game needs some HW to run on, and many of them need some software like an OS, too. In such setups, the OS is mostly responsible for giving the games standardized access to the machine's HW, meaning that if you want to release your game on a different OS, you'll have to rewrite it to the HW access possibilities of that other OS, simply spoken. So, if you want to release 100 games on another OS, you'll have to rewrite each and every one of them, which makes 100 additional game releases.

But let's now put another layer of software between the OS and the game, which we shall call a "Virtual Machine" (VM) further on, and let's have this VM provide a specialized / simplified subset of HW access to the games written for it, so that all of these 100 games don't need to access the OS directly any more. If you now want to release your games for another OS, you'll just have to rewrite the VM for that other OS, and all of your games will also run there, as if by magic. So no additional game releases are needed in that case, your old releases just run on another platform. That's platform independence.

The most common VM today is a class of programs which you are probably currently using right now: a browser provides the possibility to access online contents in several different formats across many OS's. Some of these contents can be interactive, making all the browsers tools for platform-independent gaming. Or please take a moment to revisit the Infocom price list I linked to in an earlier example. How did Infocom manage to sell their games for such a wild variety of GE's? The answer is a VM: the Z-Machine. Infocom ported their Z-Machine to every major platform available at the time, and delivered it with their game releases. Genius!

The possibility of releasing games for VM's gives us problems when it comes to our GE model. Such games are not released for a HW / OS combination any more, but for a VM which itself runs on several HW / OS combinations. It's even possible to combine several VM's, such as when people use a Z-Machine interpreter written in JavaScript inside a browser to play games. Because of all this, the VM case needs some special handling within Oregami. I would suggest that we create a single GE for every VM we encounter, add a generic "All compatible HW" as the HWP, and create a SWP for every of those VM's.

Looking at the two examples above, this means that we would have two GE's called "Browser / HTML" and "Z-Machine", would add the HWP "All compatible HW" to them, and would use the SWP "HTML Interpreter" and "Z-Code Interpreter". All those other popular VM technologies, the most popular among them like Flash or Unity used mainly inside browsers, would get their own GE's. Below the SWP's we could then add all the different versions of the VM's to track compatibility. This way, we will be able to sufficiently document platform-independent games, which is a rich field of video gaming with tens of thousands of games released.

 

7. Thinking about the Arcade

Example:

• The GE "Arcade / Sega Model 3" would be defined by the HWP "ASB Sega Model 3" and the SWP "Sega Console BIOS".

Seen the movie "Wreck-it Ralph"? This important piece of art shed a spot light on a very important part of video gaming history: Arcade machines. Before this movie, young gamers may have never heard of this million dollar business of the 80s, where dozens of as-tall-as-a-man cabinets with video games in it were used by helplessly addicted youngsters. Quite some important video game franchises were first seen on an Arcade machine before being ported to capable home computers. Thus, documenting Arcade history within Oregami is a must.

The problem with this platform is its setup, and how to press it into our GE model. The Arcade companies manufactured hardware boards, not unlike mother boards for modern PC's, which had all the necessary components to run video games on it. These boards were built into beautiful cabinets with some control hardware like a joystick, one or more video screens, and a coin slot for earning money attached to it. The games were either built into the hardware board, or came on a medium like cartridge or disc. Thus, when we talk about Arcade game releases, we mean fully fledged cabinets with all the bells and whistles on it to attract the gamers. But what GE's do we talk about?

First thought I had was to create a GE called "Arcade Machine", and attach a HWP "Arcade Board" and a SWP "Arcade BIOS" or something similar to it, then add all the different boards as sub-platforms to the HWP. But that turned out to be too generic for the rich world of Arcade boards, as some of those had different revisions released, e. g. the steppings of Sega Model 3. So I think we need to move the boards one data level up, and define the board revisions as sub-platforms.

Finally, let's do an example, and choose the already mentioned Sega Model 3 for it. For this board family, we would define a GE called "Arcade / Sega Model 3", and attach a HWP called "ASB Sega Model 3" to it, where ASB is an abbreviation for Arcade System Board. I am unsure about the SWP, as I didn't find whether this board has a BIOS or not. It most probably has one, so we could create a SWP "Sega Console BIOS" or similar. This Arcade board was updated from time to time with more CPU and video power, so we would add these different board versions as sub-platforms to the HWP. If further research reveals details on a Sega BIOS for their Arcades, we would store these information as sub-platforms to the SWP.

As exhaustive as these examples may be, they cover only a fraction of the video game platform hotspots. There's much more to research and discuss, but I'm really looking forward to that once our system is up and running.

 

Returning to user happiness

With the examples out of the way, let's return to the user happiness / user experience side of things. After reading through those examples above, there may be one big concern raised: up to 28 Linux GE's in the database, a single GE for every Arcade board or VM software, dozens of GE's for home computers of the 80s? What a cluttering up of the GE list! How can you expect to NOT turn off the casual contributor this way?
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

The final words of this mammoth blog post shall be dedicated to platform compatibility. Imagine an owner of a Nintendo 3DS looking for all game releases running on her / his machine, or a Gameboy owner looking for all the Gameboy Color releases having a "Black/White mode". We should provide the 3DS owner with a view including all Nintendo DS games, and the GB user with a view including all the respective GBC games. But to do all that, we will need to store compatibility data within Oregami, for three main use cases.
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".

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.