Data Model: platforms

[MZ per X]

Let's talk about platforms.

We had a discussion in the German forums about a new kind of platform model.

The traditional model is that of MobyGames, and many others. We have consoles like the PlayStation, we have operating systems like Windows, we have OS-independent software platforms like Browser, and we have mixed cases like DOS, which actually means MS-DOS on IBM-compatibles.

But what about MS-DOS on non-IBM-compatibles? What about other DOSes like CP/M? What about Linux games on other hardware than x86? Were there PC Booters on other than IBM-compatible PCs?

All these questions led me to a suggestion for a new platform model: the separation of hardware and software, i.e. every game gets a hardware and a software platform assigned to it.

Let's look at some examples to illustrate the change. I will "translate" some of the old Mobygames platforms to the new model:

Browser ---> HW-independent + Browser
DOS ---> IBM-compatible PC + Microsoft Desktop OS (with tech spec)
Windows ---> IBM-compatible PC + Microsoft Desktop OS (with tech spec)
Dreamcast ---> Dreamcast + Console OS
Linux ---> OS-supported hardware + Linux (Here we need a background connection between Linux and all its supported HW platforms.)
PC Booter ---> IBM-compatible PC + OS-independent
Windows Mobile ---> OS-supported hardware + Windows Mobile OS (with tech spec)
Windows Phone ---> OS-supported hardware + Windows Mobile OS (with tech spec)

Then imagine a user searching for all games on the HW platform "IBM-compatible", or on the SW platform "Microsoft Desktop OS". Which games would he/she get with the new model?

What do you think? Is this too much, or is it worthwhile?

Please comment!

[Rola]

Interesting question. While the new approach looks more flexible at first, isn't it a bit less intuitive? When it comes to platforms people think in terms of brands (sometimes there are extreme cases: "I played this game on Dell" )

One thing for sure: many people searching for old MS-DOS game may not realize it was released as booter, so it won't appear in the search results if they didn't select "PC booter"...

I'm too young to help you researching those old systems...

[Ultyzarus]

It could be less intuitive when one is not familiar with some platforms or OS. I wouldn't know what to do with any PC (or the likes) game from before 1995. All those DOS, PC Booter and other games just confuse me XD
On another hand, it may be useful for some Releases types, namely official emulators.

It would be easy to have:

Wii -> Virtual Console
PSVita -> PSOne Classics
PS3 -> PS2 Classics

and so on...

If done correctly this could be a major + for Oregami, but as plain text like this it just seems like a confusing mess to me

[Tracy Poff]

and we have mixed cases like DOS, which actually means MS-DOS on IBM-compatibles.

Actually, not so much--DR-DOS would run most any software designed for MS-DOS (including Windows!), and non-IBM-compatible computers like the Tandy 1000 also included DOS.

All these questions led me to a suggestion for a new platform model: the separation of hardware and software, i.e. every game gets a hardware and a software platform assigned to it.

This is an interesting suggestion. I've been giving it some thought, and I see one problem with it: in the vast majority of cases each software platform will be tied to exactly one hardware platform, and vice versa. There's no reason to force to user to specify that Mario is for the platform NES + Console OS. (And, of course, there's not actually an OS to begin with. For an even more extreme example, consider the Odyssey, which doesn't even have anything that could rightly be called software.)

I can't think of any real practical benefit to users to allow them to search for "IBM-compatible" or some vaguely undefined "Microsoft Desktop OS". Can you provide some more information about how you see this being useful?

That said, just because I can't think of a practical benefit from a user's standpoint, that doesn't necessarily mean it's not a worthwhile thing to do. A database should have, ideally, a single data entity representing each logical entity. From a database perspective, keeping hardware and software separate would allow you to have, for example, peripherals tied to "IBM-compatible PC", which could be selected regardless of OS, and something like 'required directx version' tied to the OS, rather than the hardware. That is useful.

Therefore, counter-suggestion: separate these at the database level, but have clients present them to the user in a unified way. That way it's necessary only to select for example NES or Dreamcast for console games, but it shall be possible to pick PC+linux or PC+DOS where applicable.

I do have one platform-related query, which I suppose I'll tack on here: if a game is associated with a particular platform, shall this mean that the publisher (or whoever) claimed that the game was intended for this platform when releasing it, or that it can be run on that platform? For instance, a game's box might claim it's for Windows, when it's really for DOS. It is a question of compatibility, or advertising?

[idrougge]

and we have mixed cases like DOS, which actually means MS-DOS on IBM-compatibles.

Actually, not so much--DR-DOS would run most any software designed for MS-DOS (including Windows!), and non-IBM-compatible computers like the Tandy 1000 also included DOS.

That's why I think there should be a unified platform called "PC", plain and simple. That does not include Tandy 1000, because it is not what one means when one says "PC", and only implicitely includes DR-DOS because DR-DOS was an MS-DOS-compatible system. An IBM PC with CP/M 86 is not the same thing as "PC", the gaming platform.

All these questions led me to a suggestion for a new platform model: the separation of hardware and software, i.e. every game gets a hardware and a software platform assigned to it.

This is an interesting suggestion. I've been giving it some thought, and I see one problem with it: in the vast majority of cases each software platform will be tied to exactly one hardware platform, and vice versa. There's no reason to force to user to specify that Mario is for the platform NES + Console OS. (And, of course, there's not actually an OS to begin with. For an even more extreme example, consider the Odyssey, which doesn't even have anything that could rightly be called software.)

Exactly.

I can't think of any real practical benefit to users to allow them to search for "IBM-compatible" or some vaguely undefined "Microsoft Desktop OS". Can you provide some more information about how you see this being useful?

I come from the opposite direction; I don't want to split hardware and software because they come as one in gaming situations. If you have a PC, you want PC games, and PC developers (such as Id or Origin) develop for IBM compatibles running a backwards-compatible Microsoft desktop OS. Therefore, the combination "IBM compatible with Microsoft desktop OS" should be referred to as the unified platform "PC". Splitting IBM/DOS/Windows into four distinct systems is a mobyism dating back to Mobygames's days as a PC-only site. And that fact is another reason to treat all these "systems" as one.

I do have one platform-related query, which I suppose I'll tack on here: if a game is associated with a particular platform, shall this mean that the publisher (or whoever) claimed that the game was intended for this platform when releasing it, or that it can be run on that platform? For instance, a game's box might claim it's for Windows, when it's really for DOS. It is a question of compatibility, or advertising?

See above. DOS and Windows are two versions of the same system as far as games goes, which your game box proves.

I have been spending Linux some thought, and while it is the absolutely strongest case for a dual-layer system of hardware platform and software platform (being a multi-platform OS), but I still think it's just as elegant to treat Linux as a distinct platform rather than a software platform because doing otherwise would lead to NES + Console OS and similar kinds of obesity in other parts of the system.

[Tracy Poff]

That's why I think there should be a unified platform called "PC", plain and simple. That does not include Tandy 1000, because it is not what one means when one says "PC", and only implicitely includes DR-DOS because DR-DOS was an MS-DOS-compatible system. An IBM PC with CP/M 86 is not the same thing as "PC", the gaming platform.

I don't agree with this, quite. I think that there are some fundamental questions of how we are going to model platforms that will have to be answered, before we can totally solve this, though.

I come from the opposite direction; I don't want to split hardware and software because they come as one in gaming situations. If you have a PC, you want PC games, and PC developers (such as Id or Origin) develop for IBM compatibles running a backwards-compatible Microsoft desktop OS. Therefore, the combination "IBM compatible with Microsoft desktop OS" should be referred to as the unified platform "PC". Splitting IBM/DOS/Windows into four distinct systems is a mobyism dating back to Mobygames's days as a PC-only site. And that fact is another reason to treat all these "systems" as one.

Well, the problem with this is that Windows software will not run on DOS. And you can't just stick a PC booter in the drive and type A:\BOOT.COM, either. Of course, 16-bit Windows software won't run on modern 64-bit Windows, too, so it is not, in general, either backwards or forwards compatible.

A benefit of being explicit that, for example, a particular game runs on DOS is that a user then knows that she can run the game using DOSBox. That's valuable information.

I have been spending Linux some thought, and while it is the absolutely strongest case for a dual-layer system of hardware platform and software platform (being a multi-platform OS), but I still think it's just as elegant to treat Linux as a distinct platform rather than a software platform because doing otherwise would lead to NES + Console OS and similar kinds of obesity in other parts of the system.

Well, I was kind of arguing against MZ per X's proposal of separating hardware from software, but let me take the other position and try to describe a slightly more detailed plan for how a split system might look, which I could support. First, I shall describe how it looks on the backend--on the database.

A game may have various system requirements. Among them we are concerned with two: required hardware platform and required software platform. Each of these shall be optional, but we will require that at least one be set, for each release.

Hardware platforms shall include NES, IBM-compatible PC, PC-98, Commodore PET, etc. Perhaps it will be reasonable to include some entry like ARM v5 tablet, too, but let us ignore for the moment these less well-defined cases.

Software platforms shall include DOS, Windows, Flash, Java, the Z-machine, BASIC, etc. Possibly it will be better to include many, many platforms, like DOS 3.3, DOS 6.2, Windows 2, Windows 3.11, Windows 95, Windows XP, etc. Let us ignore the precise details, for now.

So, a game may select just NES as a hardware requirement, and no software requirement. Done.

Or, a game may select IBM-compatible PC as a hardware requirement, and Windows 3.11 as a software requirement.

Or, a game may select Java as a software requirement, and no hardware requirement.

Attached to these hardware/software platforms should be details ('tech specs') like "Requires USB", attached to the IBM PC and "Requires Win32s" attached to Windows 3.11.

It is appropriate to tie these together in this way: though the PC-98 with Windows 95 could run regular Windows software in addition to software specifically written for the PC-98, no PC-98 game will ever require USB. No Windows 95 game will ever require Win32s. No Windows 3.11 game will ever require DirectX.

On the front-end, the client software may be designed so that when the user selects to add a game for the NES, it does not prompt for a software requirement, and so that a user selecting to add a game for the IBM-compatible PC is presented only with appropriate OS choices. This is simply a user interface issue. It would even be entirely possible to produce a client that simply presents a list like "NES, Windows 3.1, Linux on x86, etc." so that the user does not even realize that the hardware and software platforms are treated separately internally.

How do you think this looks, then?

[Ultyzarus]

That sounds like the best proposition yet. I had trouble understanding all the details the way MZ per X and idrougge put it since I'm not too savvy in the area of PC and the likes, but I this one seems just comfortable enough to include all the different options without mind-f***ing the basic users.

Keep on exchanging like that!

[MZ per X]

How do you think this looks, then?

Good it looks.

This is simply a user interface issue. It would even be entirely possible to produce a client that simply presents a list like "NES, Windows 3.1, Linux on x86, etc." so that the user does not even realize that the hardware and software platforms are treated separately internally.

This is key IMHO, as it contains the best of both worlds. In the German discussion I had the idea to give the user the possibility to choose between an easy platform model, and a full two-way model. But even better would be our platforms consisting of a hardware and software component internally, which wouldn't be easily recognizable for the (inexperienced / casual) user.

Having said that, and despite what I said in the other thread, I think that we should base our modelling on one requirement: Let the user find the platform at Oregami which he finds on his game box.

We should also offer pre-defined searches for platform families like UVL does.

I spent a lot of thought on platforms the last days, and I think it's all coming together somehow, so I will update the data model soon. Then I plan to introduce you to other parts of the platform model like general platform compatibility (i.e. all Nintendo DS games run on Nintendo 3DS), game-specific platform compatibility (i.e. some GameBoy games run colored on GameBoy Color), and sub-platforms. Much food for thought.

[Ultyzarus]

How do you think this looks, then?

Good it looks.

This is simply a user interface issue. It would even be entirely possible to produce a client that simply presents a list like "NES, Windows 3.1, Linux on x86, etc." so that the user does not even realize that the hardware and software platforms are treated separately internally.

This is key IMHO, as it contains the best of both worlds. In the German discussion I had the idea to give the user the possibility to choose between an easy platform model, and a full two-way model. But even better would be our platforms consisting of a hardware and software component internally, which wouldn't be easily recognizable for the (inexperienced / casual) user.

Having said that, and despite what I said in the other thread, I think that we should base our modelling on one requirement: Let the user find the platform at Oregami which he finds on his game box.

We should also offer pre-defined searches for platform families like UVL does.

I spent a lot of thought on platforms the last days, and I think it's all coming together somehow, so I will update the data model soon. Then I plan to introduce you to other parts of the platform model like general platform compatibility (i.e. all Nintendo DS games run on Nintendo 3DS), game-specific platform compatibility (i.e. some GameBoy games run colored on GameBoy Color), and sub-platforms. Much food for thought.

A good example of Case 4. of your platform compatibiliy is the PSVita, that run all Downloadable PSP games, but not the physical PSP media since it doesn't support UMDs at all.

[idrougge]

That's why I think there should be a unified platform called "PC", plain and simple. That does not include Tandy 1000, because it is not what one means when one says "PC", and only implicitely includes DR-DOS because DR-DOS was an MS-DOS-compatible system. An IBM PC with CP/M 86 is not the same thing as "PC", the gaming platform.

I don't agree with this, quite. I think that there are some fundamental questions of how we are going to model platforms that will have to be answered, before we can totally solve this, though.

Let me support my claim by pointing out that the number of magazines called "DOS Gamer" and "Windows Games" is close to zero, while there is a plethora of PC Gamer, PC Gaming, PC Format and PC Fun magazines. These magazines all cover IBM-compatible PCs running the mainline Microsoft system, and very seldom feature letters from confused readers wondering if it's a magazine for Linux on ARM or Concurrent CP/M on Sirius 9000.

I come from the opposite direction; I don't want to split hardware and software because they come as one in gaming situations. If you have a PC, you want PC games, and PC developers (such as Id or Origin) develop for IBM compatibles running a backwards-compatible Microsoft desktop OS. Therefore, the combination "IBM compatible with Microsoft desktop OS" should be referred to as the unified platform "PC". Splitting IBM/DOS/Windows into four distinct systems is a mobyism dating back to Mobygames's days as a PC-only site. And that fact is another reason to treat all these "systems" as one.

Well, the problem with this is that Windows software will not run on DOS. And you can't just stick a PC booter in the drive and type A:\BOOT.COM, either. Of course, 16-bit Windows software won't run on modern 64-bit Windows, too, so it is not, in general, either backwards or forwards compatible.

It's a feature, not a bug. You can't run 486 software on your 286, or put a 5,25" floppy in a 3,5" drive, but it's still the same basic platform. The fact is that you can stick a "PC booter" (another Mobyism, we never talk about Atari ST booters or C128 booters) in most PCs with a floppy drive and it will boot. You will have a hard time finding a similar system with the same amount of forward and backward compatibility. For example, 32-bit Windows software runs on 64-bit Windows. CGA games usually run on VGA cards. MS-DOS software runs on Windows 95, and Windows 3.0 software runs under Windows XP. In fact, I quite recently successfully ran a 1991 MS-DOS game under Windows XP on a Pentium IV without major problems. Try that on a Mac.

A benefit of being explicit that, for example, a particular game runs on DOS is that a user then knows that she can run the game using DOSBox. That's valuable information.

I never said that the system requirements shouldn't be kept count of, I just don't think that some parts of it should be moved out of system requirements and put as a platform just in order to appeal to the users of that platform.

That kind of valuable information, just as other valuable information such as minimum CPU, minimum RAM and supported graphics cards, has an obvious place in the "tech specs".

Keeping up with a moving target of an emulator doesn't make sense if our goal is to document games. The basic information is there, and can be filtered in all kinds of ways, but support for emulators is best left to the emulator scene while we concentrate on the task at hand: documenting releases of games. In any case, I wouldn't call compatibility with a specific emulator valuable information.

A game may have various system requirements. Among them we are concerned with two: required hardware platform and required software platform. Each of these shall be optional, but we will require that at least one be set, for each release.

This is one problem. In many cases, there is no software platform. And if there is one, it may be of no consequence to the player, such as Windows CE on a Dreamcast. It's like classifying middleware as a gaming platform.

One reason I suggested sub-platforms instead of the hardware platform—software platform pairs is that many platforms put little weight on software but have distinct variations (not in the least from a games publisher viewpoint) based on hardware differences.

Software platforms shall include DOS, Windows, Flash, Java, the Z-machine, BASIC, etc. Possibly it will be better to include many, many platforms, like DOS 3.3, DOS 6.2, Windows 2, Windows 3.11, Windows 95, Windows XP, etc. Let us ignore the precise details, for now.

So, a game may select just NES as a hardware requirement, and no software requirement. Done.

Attached to these hardware/software platforms should be details ('tech specs') like "Requires USB", attached to the IBM PC and "Requires Win32s" attached to Windows 3.11.

It is appropriate to tie these together in this way: though the PC-98 with Windows 95 could run regular Windows software in addition to software specifically written for the PC-98, no PC-98 game will ever require USB. No Windows 95 game will ever require Win32s. No Windows 3.11 game will ever require DirectX.

PC-98 is only meaningful as a distinct platform insofar as it runs PC-98 specific software. If software for "regular" Windows 95 runs on it, that software cannot be PC-98 software.

What you otherwise mention is PC-isms (for example, saying "DOS" and expecting everyone to say "Yes, that DOS, not DOS for PDP-8 or Apple DOS or CBM DOS"), which don't belong in the same namespace as distinct platforms.

On the front-end, the client software may be designed so that when the user selects to add a game for the NES, it does not prompt for a software requirement, and so that a user selecting to add a game for the IBM-compatible PC is presented only with appropriate OS choices. This is simply a user interface issue. It would even be entirely possible to produce a client that simply presents a list like "NES, Windows 3.1, Linux on x86, etc." so that the user does not even realize that the hardware and software platforms are treated separately internally.

I don't see the point in keeping track of always-blank fields such as "the OS which never existed for NES", just as keeping track of "the light pen that never was for the Ipad" or "support for VGA cards on Commodore 64". If the user adds a game, and selects the PC platform, he is presented with a set of appropriate hardware and software choices, just like you say. That's how Mobygames has always worked, and it has worked that way without introducing a software sub-platform. Moby's mistake was to start out as a PC-centric site, let's not repeat that mistake.

Likewise, introducing hardware requirements for software platforms makes no sense. In this case, I'm a subscriber of the Wikipedia idea of avoiding surprises.

[Tracy Poff]

The fact is that you can stick a "PC booter" (another Mobyism, we never talk about Atari ST booters or C128 booters) in most PCs with a floppy drive and it will boot.

Here you are making my point for me. A 'PC booter' is exactly 'just a PC game'. Which is why I suggest allowing the user to select just PC as the platform for such a game. It's not a game that requires DOS or Windows or anything else. We should not ever ask what version of DirectX the game wants, or if it requires a certain minimum version of DOS. It's just a PC game. And separating hardware from software lets us capture this.

A game may have various system requirements. Among them we are concerned with two: required hardware platform and required software platform. Each of these shall be optional, but we will require that at least one be set, for each release.

This is one problem. In many cases, there is no software platform. And if there is one, it may be of no consequence to the player, such as Windows CE on a Dreamcast. It's like classifying middleware as a gaming platform.

Allow me to quote you quoting me: "Each of these shall be optional, but we will require that at least one be set, for each release." In other words, in the case that there is no software platform, no software platform is set. That includes situations like CE games on Dreamcast.

PC-98 is only meaningful as a distinct platform insofar as it runs PC-98 specific software. If software for "regular" Windows 95 runs on it, that software cannot be PC-98 software.

The point of my statement was that not all 'tech specs' apply to all combinations of hardware and software. But aren't you just agreeing with me, here? "PC-98 is only meaningful as a distinct platform insofar as it runs PC-98 specific software." Indeed, since the PC-98 ran PC-98-specific software, it should be counted as a separate platform. Of course we don't say that random Windows software was released for OS/2, either, but we don't say that OS/2 isn't a real platform, just because it also ran Windows software.

I don't see the point in keeping track of always-blank fields such as "the OS which never existed for NES"

Well, since every game will have the same fields, by necessity, it means that a game for the NES would have an empty 'software platform' field, in the same way that a game for the Z-Machine would have an empty 'hardware platform' field. That's happening in the database, but the user never has to see it, as I said. And the reason this is worthwhile is...

just as keeping track of "the light pen that never was for the Ipad" or "support for VGA cards on Commodore 64". If the user adds a game, and selects the PC platform, he is presented with a set of appropriate hardware and software choices, just like you say.

Since some tech specs apply to software, and some to hardware, it seems sensible to separate hardware from software. Sine the C64 has no VGA card, we would not attach a VGA card spec to it. Nor any light pen spec to the Ipad. And, importantly, if a user adds a game for MS-DOS, she should not be then asked "Which version of DirectX, if any, did this DOS game require?" And we prevent such a thing by treating DOS and Windows as separate things. We can't "present the user with a set of appropriate hardware and software choices" unless we actually know what hardware and software we're talking about.

That's how Mobygames has always worked, and it has worked that way without introducing a software sub-platform. Moby's mistake was to start out as a PC-centric site, let's not repeat that mistake.

You know, I loved Mobygames, but so many things there were deeply stupid that I'd avoid suggesting that we do anything the way Mobygames did, unless I had a reason to believe it was the right way. In this case, I believe that Mobygames's platform system wasn't the right way.

Likewise, introducing hardware requirements for software platforms makes no sense. In this case, I'm a subscriber of the Wikipedia idea of avoiding surprises.

The principle of least surprise is a good one. It doesn't really apply, here, since it means that a user's action should do what they expect it to. But if I try to stretch it to fit: would you be more surprised to be asked whether a game ran on DOS or Windows, or to be asked if your DOS game required DirectX?

[MZ per X]

Okay, so I completely re-did the data model for platforms. Please take a look at the lower left corner of this page.

a) Every RG will have a new mandatory property called "Gaming Environment" [GE]. I chose a new name for this, because I wanted to distinguish between the real platforms (hardware and software), and the environment a game runs on which, in many cases, is a combination of both hard- and software.

b) A GE will have two mandatory properties, a hardware and a software platform. As there's more than one reason why either the HW or SW platform might be "empty", both properties are mandatory, so we can track the reasons. For example, if a game doesn't need a software platform, it could be that it just needs no OS, or the OS is built into a console, or whatever. So instead of having an empty software platform, we can save the reason for its emptyness.

c) Two GEs can be connected with compatibility information. (Connection 9 in the model)

The easy part of this is general compatibility, say every Nintendo DS game running on the Nintendo 3DS. For general compatibility, we would create a connection between these two platforms, and state the full compat type (1 or 2 of the list), done.

The not-so-easy part is game-specific compatibility, say some Gameboy Color games offering a black-white mode for use at the classic Gameboy. For these cases, we would first connect the two GEs stating a specific compat type (3 or 4 of the list), say we connect Gameboy and Gameboy Color using "Specific Compat upwards". Then we would connect this specific compatibility entry to all the games that support it (Connection 11 in the model), done.

d) Both HW and SW platforms will have a sub-table with sub-platforms of different types attached to it. For HW, this could be regional clones, for SW it could be OS variants, or emulators. The SW sub-platforms get its own link to the RG to map software compatibility. Via Connection 10 in the data model, we could save all the software compatibility states we'd need for any game. We'll see if such link is needed for HW sub-platforms, too.

Let's look at a combined example for all this, let's take the complicated DOS/Windows case.

a) Two GEs are created: "MS-DOS PC" and "Windows PC"

b) Both GEs have "IBM-compatible PC" as their HW platform, while one has "Microsoft DOS" as SW platform, and the other "Microsoft Windows".

c) The two GEs are connected with "Full compatibility downwards", i. e. DOS games run on Windows, but not the other way round. I know that not every DOS game runs on every Windows version, but I chose full compat nonetheless, because probably every DOS game runs on some version of Windows at least.

d) Both SW platforms get all their OS variants as sub-platforms, for example "Microsoft Windows" gets Win95, Win 98, Win98 SE, Win XP, etc. attached to it. So, if a user enters a Windows game, he will be able to enter all the Windows versions that game runs on. If one enters a DOS game, the database will not only offer the DOS versions for entering OS compatibility information, but also all the Windows version, because of the full compat entry between these two GEs.

Well, I'm quite sure I didn't make myself clear about these complicated stuff, so please ask all the inevitable questions.

[hsssh]

Would different models of consoles count as separate platforms? I had no personal experience with this, but I heard that newer models of PS3 can't play PS2 games while first model has no problems with that, some chip was changed in later models, or something, that caused this problem. So how compatibility would be linked in such case? Maybe just some extra note that it works only with certain models of the console? Because I imagine it might get messy with trying to document and link various models of consoles.

[MZ per X]

Would different models of consoles count as separate platforms?

Basically, no. These would be sub-platforms of the type "Hardware Model", or "Regional Clone", or similar.

I had no personal experience with this, but I heard that newer models of PS3 can't play PS2 games while first model has no problems with that, some chip was changed in later models, or something, that caused this problem. So how compatibility would be linked in such case? Maybe just some extra note that it works only with certain models of the console? Because I imagine it might get messy with trying to document and link various models of consoles.

This would be no different than the DOS/Windows example, I think.

a) We'd have two GEs, "PlayStation 2" and "PlayStation 3".

b) Both would have a hardware platform with the same name as the GE, and "Built-in OS" as software platform.

c) The two GEs would be connected with "Full compatibility downwards", as the PS3 can usually play every PS2 game.

d) Then we would create at least two sub-platforms for the PS3, one for the first model, one for later models. I am not sure about the messiness of this, or how the two generations could be differentiated from each other, though. But with these sub-platforms we could, then, save compatibility information for every PS2 game.

[idrougge]

The fact is that you can stick a "PC booter" (another Mobyism, we never talk about Atari ST booters or C128 booters) in most PCs with a floppy drive and it will boot.

Here you are making my point for me. A 'PC booter' is exactly 'just a PC game'. Which is why I suggest allowing the user to select just PC as the platform for such a game. It's not a game that requires DOS or Windows or anything else. We should not ever ask what version of DirectX the game wants, or if it requires a certain minimum version of DOS. It's just a PC game. And separating hardware from software lets us capture this.

But: Since MS-DOS is not an operating system in the same sense as Windows NT or even Atari TOS, the distinction is not so clear, especially if you in front of you have a floppy-based PC with two games: One has a custom bootblock, and one has COMMAND.COM and an AUTOEXEC.BAT. In both cases, you insert the disk and the game boots. Or you have a bootable game which comes with an installer.

Also: My point has always been that all games running on the most popular OS on IBM compatibles are "PC" games, since there is a clear continuum from the IBM 5150 all the way to Windows 8.

PC-98 is only meaningful as a distinct platform insofar as it runs PC-98 specific software. If software for "regular" Windows 95 runs on it, that software cannot be PC-98 software.

The point of my statement was that not all 'tech specs' apply to all combinations of hardware and software. But aren't you just agreeing with me, here? "PC-98 is only meaningful as a distinct platform insofar as it runs PC-98 specific software." Indeed, since the PC-98 ran PC-98-specific software, it should be counted as a separate platform. Of course we don't say that random Windows software was released for OS/2, either, but we don't say that OS/2 isn't a real platform, just because it also ran Windows software.

OS/2 is only a gaming platform insofar as games being released specifically for OS/2. And since OS/2 isn't part of the mainline PC platform, I wouldn't add an OS/2 game by first selecting the PC platform. It's a special shelf in the shop, right next to the Mac games, even though you could run Civilization V for OSX on a Hackintosh.

I don't see the point in keeping track of always-blank fields such as "the OS which never existed for NES"

Well, since every game will have the same fields, by necessity, it means that a game for the NES would have an empty 'software platform' field, in the same way that a game for the Z-Machine would have an empty 'hardware platform' field. That's happening in the database, but the user never has to see it, as I said.

I thought database software had come so far by now that it can be specified which fields should be inherited by another field. But never mind, that's a backend problem.

just as keeping track of "the light pen that never was for the Ipad" or "support for VGA cards on Commodore 64". If the user adds a game, and selects the PC platform, he is presented with a set of appropriate hardware and software choices, just like you say.

Since some tech specs apply to software, and some to hardware, it seems sensible to separate hardware from software. Sine the C64 has no VGA card, we would not attach a VGA card spec to it. Nor any light pen spec to the Ipad. And, importantly, if a user adds a game for MS-DOS, she should not be then asked "Which version of DirectX, if any, did this DOS game require?" And we prevent such a thing by treating DOS and Windows as separate things. We can't "present the user with a set of appropriate hardware and software choices" unless we actually know what hardware and software we're talking about.

From a gaming perspective, I don't see why the fact that some requirements are soft and some hard makes a case for separate hardware and software platforms when they in the end form a unified gaming platform.

We will nevertheless encounter this on a multitude of platforms because availability of hardware and software varies over time. There seems to be a concensus that Windows 95 and Windows 7 are the same platform, but that's still over a time-span of 15 years or so, with wildly varying hardware and software requirements. This doesn't mean that I think that users should be forced to select an Active X version for MS-DOS games, but there must be another solution which doesn't rely on a division between "this version of mainline PC gamer OS" and "that version of still backwards compatible mainline PC gamer OS". Javascript, while not something I approve use of for image loading, seems like a solution for this.

Moby's mistake was to start out as a PC-centric site, let's not repeat that mistake.

You know, I loved Mobygames, but so many things there were deeply stupid that I'd avoid suggesting that we do anything the way Mobygames did, unless I had a reason to believe it was the right way. In this case, I believe that Mobygames's platform system wasn't the right way.

We both agree there, but I feel that carrying on the distinction between compatible PC OSes is a pure Mobyism.

Likewise, introducing hardware requirements for software platforms makes no sense. In this case, I'm a subscriber of the Wikipedia idea of avoiding surprises.

The principle of least surprise is a good one. It doesn't really apply, here, since it means that a user's action should do what they expect it to. But if I try to stretch it to fit: would you be more surprised to be asked whether a game ran on DOS or Windows, or to be asked if your DOS game required DirectX?

I don't see why that should happen. The moment a user selects MS-DOS a a requirement, he is presented with lots of options for light pens. And the moment he selects Windows XP, he can choose between DirectX versions but never Glide.