Data Model: platforms

[idrougge]

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.

Why should this differ from 386-486-Pentium; i.e. simple tech specs?

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.

What's the point in this? The fact that one platform is backward-compatible is implicit here. What I thought we were trying to cover is the fact that the same Gamepak can be run on both an original Gameboy and a Gameboy Colour while taking advantage of the colour display of the latter. That you can run a PS2 game on a PS3 should be outside the scope of Oregami.

[MZ per X]

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.

While I generally like this idea, I somehow came to the conclusion that we shouldn't do "PC" as a gaming environment, because...

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. Spanning from the mid 80s to today's Windows versions is too far a stretch, I think, which would create more problems than it would solve. DOS is a platform long gone, a young Windows player might never know it existed at all. When this new Windows user browses Oregami, he would find the blockiest CGA games from the DOS era side by side with the bleeding-edge Windows AAA titles, and all of this on a single platform consisting of tens of thousands of games. I don't like that thought at all. Furthermore, when I think of a "MS-DOS" platform, and see eXo's work (eXoDOS), I get the warm feeling of seeing a more or less "completed" DOS platform on the horizon, a feat which we won't accomplish for Windows for decades to come.

That doesn't mean that we can't pre-define a "PC" platform (consisting of DOS/Windows/Booters) within our search engine for people who want this.

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.

Why should this differ from 386-486-Pentium; i.e. simple tech specs?

In the end, it won't be too different from tech-specs. I did it as sub-platforms for expandability's sake: Oregami needs to become a gaming hardware database, too, more or less so. Or let's say that hardware shall be an aspect that needs to be quite visible for outsiders, for one reason: When I checked our charter draft with German financial authorites, I was told the German non-profit law is a bit behind on software and Internet, and to secure the non-profit status we should make room on our site for things that can be touched, too. Sounds strange, but okay, I don't see a drawback in allowing users to contribute some more information about gaming hardware than they could elsewhere.

That you can run a PS2 game on a PS3 should be outside the scope of Oregami.

I disagree here. It is very valuable information for a PS3 owner to see which games can be run on his platform. I don't understand why this should be out of scope for Oregami?

[Ultyzarus]

That you can run a PS2 game on a PS3 should be outside the scope of Oregami.

I disagree here. It is very valuable information for a PS3 owner to see which games can be run on his platform. I don't understand why this should be out of scope for Oregami?

The problem here is that it depends on the model. I own a first model PS3 that is fully retro-compatible, but I know the latest ones either can't play ps1 games or ps2 games, not sure which... There is also a similar issue with the Xbox 360, as first models can't read recent games because they don't have a Blue Ray(I think it's that format) drive.
And we haven't even touched the issue of retrocompatibility for Xbox games. I believe that the 360 can play some games, but not all of them... Weird machine

[MZ per X]

The problem here is that it depends on the model. I own a first model PS3 that is fully retro-compatible, but I know the latest ones either can't play ps1 games or ps2 games, not sure which... There is also a similar issue with the Xbox 360, as first models can't read recent games because they don't have a Blue Ray(I think it's that format) drive. And we haven't even touched the issue of retrocompatibility for Xbox games. I believe that the 360 can play some games, but not all of them... Weird machine

Yeah, that's precisely the kind of problems that the above mentioned "sub-platform compatibility" tries to solve.

[MZ per X]

Okay, one of the big gaps in the platform model we didn't really discuss, yet, is: multi-platform operating systems like Linux. I thought about these while writing a new blog post about platforms, and came to the following conclusions:

A multi-platform OS supports varying hardware platforms with every new version of it. There's two main cases involved here, first one is that a new OS version supports a new platform, second one is that support for an old, obsolete platform has been removed in a new OS version. Unfortunately, there's gray areas, too. We've seen cases, where the support for a platform within Linux was broken for several releases, and nobody noticed or cared. And this down to the level, that the code for some platforms not even compiled.

That just means that not every platform Linux officially supports is actually tested for every release, and thus working. In the end, it means that every platform port of Linux, or other multi-platform OS's for that matter, is a tiny OS in itself. And Linux is a collection of smaller OS's that share technical concepts and basic code, and therefore are released together under a common brand.

So what does that mean for Oregami?

1) Since we need to be a technical database, too, we should be able to track hardware support of the OS's in our database. This can be achieved by a m:n-connection between the hardware and software sub-platforms.

-platform
--sub-platform

-x86
--8086
--8088
--80286
--80386

-PowerPC
--G1
--G2
--G3

-Linux
--Linux 3.1
--Linux 3.2
--Linux 3.3

2) When a game is released "for Linux", it is almost always released for a specific platform inside Linux, mostly for x86. Whether it runs on other Linux ports, remains to be tested. Most probably not, as the game needs to be recompiled on that other platform, which makes the end product like a new release.Think Android.

3) If we'd choose to create a GamingEnvironment "Linux" with the hardware platform "All compatible HW" and the software platform "Linux", our existing possibilities of tracking game compatibility wouldn't suffice any more, because we'd need to track "hardware platform + OS version" compatiblity for every Linux release group of a game. While it may be possible, the added complexity is not really needed IMHO.

4) Instead, we should stay true to the model we already discussed, and create a GamingEnvironment for every Linux port that has seen game releases, the first and foremost one being "Linux x86". This may clutter up the GE list, but severely eases the compatibility tracking issues. And for the bigger picture, we have the facility of GE groups, where we could create a group "Linux" that incorporates all the port GE's, or we can offer deep search and listing features for games that span several GE's.

So much for a video game reserarcher's nightmare, let's see how this turns out later.

[MZ per X]

We now have extensive documentation of our planned platform model, so it's ready to be coded, I think.

I did the final explanation in the Wiki, and wrote a detailed blog post with many examples.

Furthermore, I developed a basic issue tree within Jira, with this issue being the core.

Comments appreciated, as always.

[hydr0x]

As it ruined a good night's sleep for me over the weekend, I quickly wanted to to point out a horrible case for any platform model. I don't think your proposed model is able to fully represent it either, so hopefully this will give you a chance to rework it before it's too late. Then again, you might choose to ignore this special case.

I'm talking about the VC-4000 hardware family. See Wikipedia.

What's important there is the table. You have two dozen or so licensed systems of the same basic hardware, all of which are completely software compatible (which means, write an emulator for one, and you've emulated them all). However, to make things even worse, these systems used 6 different types of cartridges, NOT compatible with each other. You could potentially wire adapters to get them running though. So, basically, you have the same 1 platform, which uses 6 incompatible cartridge formats across two dozen actually marketed consoles, some of which were even sold in the same country.

[MZ per X]

Thanks for the heads-up, I'm still thinking about this.

A similar case seems to be the Arcadia 2001 family of consoles, which MobyGames added lately. Here is a good FAQ which even compares this family a bit to the VC-4000 one.

[gene]

I have a question concerning our data model for GamingEnvironments.
We have placed the attribute "type" (Data List 7) at the HardwarePlatform level:



If you don't remember:
The HardwarePlatform is placed under the GamingEnvironment (top) level, take a look here to see these different layers of platforms.

Now my question:
Shouldn't we place the "type" (Data list 7) on the top level, which means the GamingEnvironment layer? Is it really possible that for one GamingEnvironment the type of platform can be multiple types? Isn't that defined at the top level only?

[MZ per X]

We have placed the attribute "type" (Data List 7) at the HardwarePlatform level:

BTW, we have data list 26 for the SoftwarePlatforms.

Shouldn't we place the "type" (Data list 7) on the top level, which means the GamingEnvironment layer?

At this level, we have the GamingEnvironmentGroups with which we can group GEs together. Maybe we should invent a "GEG type" for this basic classification?

Is it really possible that for one GamingEnvironment the type of platform can be multiple types? Isn't that defined at the top level only?

I don't really understand the question. Data List 7 its not a tag list?

[MZ per X]

I'm talking about the VC-4000 hardware family. See Wikipedia.

What's important there is the table. You have two dozen or so licensed systems of the same basic hardware, all of which are completely software compatible (which means, write an emulator for one, and you've emulated them all). However, to make things even worse, these systems used 6 different types of cartridges, NOT compatible with each other. You could potentially wire adapters to get them running though. So, basically, you have the same 1 platform, which uses 6 incompatible cartridge formats across two dozen actually marketed consoles, some of which were even sold in the same country.

I nearly forgot about this.

It is obvious that all the different systems sold are at our sub-platform level, so we need the different compatibility families at the HWP and GE level. We can then group these together within a GEG, but the question I'm unsure about is the software compatibility. Do we need to represent it in our data model? If so, we could re-use the GE compatibility connection for this, and invent a new compatibility type.

[gene]

Is it really possible that for one GamingEnvironment the type of platform can be multiple types? Isn't that defined at the top level only?

I don't really understand the question. Data List 7 its not a tag list?

We agreed to this logical structure:

Layer 1: Europe/American Homecomputer like C64 / Amiga / Atari
.\__ Layer 2: Commodore Amiga
... \__ __ Layer 3: Amiga 500


Then we have the physical data model:

GamingEnvironment: Commodore Amiga
.\__HardwarePlatform: Amiga 500
.\__HardwarePlatform: Amiga 600
.\__HardwarePlatform: Amiga 1200

(there is no GamingEnvironmentGroup for Amiga? But that's another topic)

Now my question again:
Shouldn't we assign the field "platform type" on the "GamingEnvironment" level: Commodore Amiga?
In the current data model the field is assigned to the HardwarePlatform level. I mean every Amiga model is of the type "Europe/American Homecomputer like C64 / Amiga / Atari" ?!

[MZ per X]

We agreed to this logical structure:

Layer 1: Europe/American Homecomputer like C64 / Amiga / Atari
.\__ Layer 2: Commodore Amiga
... \__ __ Layer 3: Amiga 500

This is an old version.

Then we have the physical data model:

GamingEnvironment: Commodore Amiga
.\__HardwarePlatform: Amiga 500
.\__HardwarePlatform: Amiga 600
.\__HardwarePlatform: Amiga 1200
(there is no GamingEnvironmentGroup for Amiga? But that's another topic)

This is our physical data model until now:

The Amiga world should look like this:

GamingEnvironment: Commodore Amiga
.\__HardwarePlatform: Amiga M68K Machine & Compatibles
.\______HardwareSubPlatform: Amiga 500
.\______HardwareSubPlatform: Amiga 600
.\______HardwareSubPlatform: Amiga 1200
.\__SoftwarePlatform: AmigaOS
.\______SoftwareSubPlatform: Kickstart 1.0
.\______SoftwareSubPlatform: Kickstart 2.0
.\______SoftwareSubPlatform: Kickstart 3.0

I'm not sure about a GEG for Amiga. Maybe merge Amiga, CDTV and CD32 into one big Amiga world GEG?

Shouldn't we assign the field "platform type" on the "GamingEnvironment" level: Commodore Amiga? In the current data model the field is assigned to the HardwarePlatform level. I mean every Amiga model is of the type "Europe/American Homecomputer like C64 / Amiga / Atari" ?!

You see above that the HardwarePlatform level is more general than A500 or A600, so a classification at this level would still make sense.

But you're right that we're missing a classification at GE level. Technically, this could also be done as a GEG with a certain flag. What do you like more, a data list at GE level or special GEG's for this purpose?

[MZ per X]

Gene is currently coding the Gaming Environments, but had problems understanding the data layers, because they're not really well defined, I must admit. That's because there's so different GE's out there.

But let me try to give two basic entry points for modelling a new GE:

1) The first and foremost entry point is the GE itself:

A GE basically is a combination of hardware and software that games are released for.

I know that this definition is as soft as butter, but I'm afraid it's all we can get. There's of course the need for us to be creative here: Just because some DOS games had a sticker with "XT & compatible" written on it, doesn't make this its own GE. Or TheLegacy has the Limited Edition of Dungeon Master for Amiga 1000 in its database, with "Amiga 1000" as platform. No, that's not enough for a new GE.

A GE is an important piece of data within Oregami, because it is what the Release Groups are linked to. So we need to consider all the data linked to the RG, too, when creating a new GE. Reviews and Previews, walkthroughs, screenshots, what is the GE that all these data are for?

2) If we have trouble finding the right GE, we can use entry point 2, the sub-platform:

A sub-platform basically is a hardware model or a software version.

Once we identified the models/versions, maybe it will be easier to model from the bottom up to the GE.

[gene]

A GE basically is a combination of hardware and software that games are released for.
...
A sub-platform basically is a hardware model or a software version.

Great that we figured that out in IRC !