Sorting out the platform mess
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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".
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".
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".
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".
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".
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".
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.
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.
