Data Model: platforms

[gene]

I started to collect GamingEnvironments for Oregami.

Take a look at this Google Spreadsheet:
https://docs.google.com/spreadsheets/d/ ... sp=sharing

[gene]

Shouldn't we have a "release year" for GamingEnvironment and Platforms ?
When I look at Wikipedia e.g. the list of consoles and homecomuters all state a "release year", because it is interesting to the reader!

GamingEnvironment: new attribute "FirstReleaseYear"
HardwarePlatform: new Connection to "Region" with attribute "ReleaseYear"
SoftwarePlatform: new attribute "ReleaseYear" (do we need a region here?)

[MZ per X]

Shouldn't we have a "release year" for GamingEnvironment and Platforms ?

Yes, we should.

GamingEnvironment: new attribute "FirstReleaseYear"
HardwarePlatform: new Connection to "Region" with attribute "ReleaseYear"
SoftwarePlatform: new attribute "ReleaseYear" (do we need a region here?)

I think we should do the following:

Add a "FirstReleaseYear" for the GamingEnvironment, and for HardwarePlatform and SoftwarePlatform, as a quick way to see the age of the item.

The regional ReleaseYear should be added at SubPlatform level, because there's the hardware models and detailed software versions. Do you think that's okay?

[gene]

Shouldn't we have a "release year" for GamingEnvironment and Platforms ?

Yes, we should.

GamingEnvironment: new attribute "FirstReleaseYear"
HardwarePlatform: new Connection to "Region" with attribute "ReleaseYear"
SoftwarePlatform: new attribute "ReleaseYear" (do we need a region here?)

I think we should do the following:

Add a "FirstReleaseYear" for the GamingEnvironment, and for HardwarePlatform and SoftwarePlatform, as a quick way to see the age of the item.

The regional ReleaseYear should be added at SubPlatform level, because there's the hardware models and detailed software versions. Do you think that's okay?

Yes, that seems OK for me
I added the "FirstReleaseYear" on all three stages. Do we need a new "connection" between GE and Hardware- and SoftwareSubPlatform for the regional year?

[gene]

I started to collect GamingEnvironments for Oregami.

Take a look at this Google Spreadsheet:
https://docs.google.com/spreadsheets/d/ ... sp=sharing

I think it's better to write down these things in our Wiki.
So I created this page:
http://wiki.oregami.org/display/OR/Gaming+Environments

Anybody wants to help me to collect GamingEnvironments, HardwareSubPlatforms (=Models) and release years?
This data will be used by me in my technical prototype app to insert first "real" game data with release information.

[MZ per X]

I added the "FirstReleaseYear" on all three stages. Do we need a new "connection" between GE and Hardware- and SoftwareSubPlatform for the regional year?

No, for regional releases we will need a new connection between "Region" and Hardware- and SoftwareSubPlatform.

[gene]

I added the "FirstReleaseYear" on all three stages. Do we need a new "connection" between GE and Hardware- and SoftwareSubPlatform for the regional year?

No, for regional releases we will need a new connection between "Region" and Hardware- and SoftwareSubPlatform.

Ah, my fault, that was exactly what I meant

[MZ per X]

So I worked a little in the wiki at the Gaming Environments, and spotted the list of PlayStation models. And it dawned on me that we cannot possibly list every of these models as a HardwareSubPlatform, which we would need to do for documenting regional releases of every model.

The HardwareSubPlatform is an important data structure mainly used for documenting game compatibility. But there's no use in mapping every PS game's compatibility to every of the PS models. That would be overkill, I suppose, and would need people to test the games on every model.

Instead, we should list the hardware revisions A, B, and C of the PlayStation as HardwareSubPlatforms. That's something that makes sense for mapping game compatibility to.

As regards the hardware models and its regional releases, we'll have to invent a new data layer, I suppose.

[MZ per X]

Terok Nor added the MobyGames platforms (Name and ID) to our list of Gaming Environments. Big thanks for that!

[TerokNor]

It's a work in progress, about 50 are still missing.

[TerokNor]

Now it's complete - all 201 Moby platforms accounted for. Happy new year!

[gene]

Now it's complete - all 201 Moby platforms accounted for. Happy new year!

That's great, thanks for your effort!

Happy new year

[TerokNor]

Now that I've done some more reading about the GE model, several possible problems came to my mind. Let me try to put my thoughts into words:

I can think of many possible cases where a user will most likely not know which exact GE to select. The first reason: not enough information is available. Imagine that there is a very rare and obscure 1985 PC game of which we only have a front box image that says "IBM PC". There are no system requirements to be seen (maybe they are on the bottom of the box). So which is it? Self-booting? DOS? We have no way of knowing. Same if a mid-90s game just says "PC" (is it DOS or Windows?) To document such a game, we would have to be able to select "IBM PC compatible HW" for the hardware platform and "Unknown" for the software platform.

Besides not enough information about the game being available, maybe we as database modelers don't know enough about the platform. Think of Japanese computers: who knows how a PC-98 or an FM-Towns really works? A Sharp MZ or X1? Do the games self-boot? Do they require an OS? What if there's more than one type of OS? There are certainly experts who know that and research can always be done. What if we don't find an expert or the platform is so obscure that all information is in a language none of us speak? There still must be a way to enter an X1 game into the database regardless. Setting fields to "Unknown" might be an answer.

Next thought: separating GEs for the same hardware by OS (i.e. "DOS PC" and "MS Windows PC") solves certain problems as discussed earlier. However, it will also lead to some bloat. Think of any transitional period for a computer platform (software or hardware changing). In the mid-to-late 90s, many PC games were released with both DOS and Windows binaries in the same box and on the same disc. Prominent examples include Master of Orion II, Fallout, Dungeon Keeper, Oddworld: Abe's Oddysee, Sierra SCI games and I'm sure there are many more. These would all have to be added twice, even though what you bought was simply one game in one box.

And let me throw one really strange example into the mix: The Elder Scrolls Adventures: Redguard. The box says "Windows 95". The game requires a 32-bit Windows (i.e. Win 95 or above) to install. Once installed, however, the game itself is 100% pure DOS (i.e. it runs in Win9x' DOS mode)- copy it to a DOS machine and it will run fine. So is this a "DOS PC" or a "MS Windows PC" game?

Let's think of Macintosh: three different CPU architectures, several generations of OS. So it would probably need to be at least three GEs: 68k Mac, PPC Mac, x86 Mac. Possibly we would have to distinguish Classic OS and OS X on PPC, i.e. Classic PPC Mac and OS X PPC Mac. So how did the transitional periods work here? The PPC versions of Classic OS were 68k-backwards compatible through emulation in the OS: so a game released during the transitional period only had one binary for one architecture - no need to list anything twice (but see above: what if we don't know if it's 68k or PPC for a 1994 Mac game?). It's different with PPC-to-Intel, though. No backward compatibility here, so most games got released as "fat binaries" - one executable file that runs on both architectures. Again everything would have to be listed twice, even though this time it's literally the same *file*, not just the box or the disc.

And once we move into modern mobile platforms, it becomes *really* complicated. Android runs on three different architectures (MIPS, x86, ARM). Fat binaries are possible, but also a manifest with links to several thin binaries with only the one for the proper hardware being downloaded. But Android apps can also run in a Java virtual machine, so the hardware can also be irrelevant. Most commercial games probably run on all three architectures, but it's very possible that games exist that don't. Several GEs would have to be added for many games. And with the mobile market being as it is - dozens (or even hundreds) of games added and/or removed from the app stores daily - finding the necessary information to fit a certain game into the GE model could be extremely difficult if not impossible, depending on the game.

And it becomes even more complicated with Windows Store apps. They run not only on different architectures (x86, x64 and ARM), but also hardware as varied as desktop PCs, mobile devices and Xbox One. Now we have a console in the mix, so the simple equation "console GE = console hardware + console software" doesn't really work anymore if the same file also runs on a Windows 10 PC. I haven't been able to find out whether fat binaries or a manifest model is used (maybe both), but it seems to me the same problems apply as with Android, only even more complex.

Next, Arcade games. Bundling something like Sega Model 3 (or other relatively modern systems like System 16, CPS-2, Naomi, Atomiswave, Chihiro, etc.) is a nice idea, especially for systems where the arcade operator literally just has to exchange a cartridge or disc to install a new game. But these systems only cover a fraction of all arcade games. For many games (i.e. thousands and thousands), each has its own unique hardware and no system software. How would GEs apply here?

I'm not sure what I'm arguging for (or against), but I wanted to put this out here for discussion.

[MZ per X]

Thanks for your valuable input, much appreciated!

I lay ill this week, so I don't have the brains to think about these problems right now, but I will get to it.

[MZ per X]

Sorry for the late reply, but real life quite owns me at the moment. First of all, this is great input, so thanks again.

I can think of many possible cases where a user will most likely not know which exact GE to select.

You are right that this is a serious problem. Even more so, I think that users not knowing which GE to select may come in lesser numbers than users not willing to do the research. But nonetheless, we need such generics for the unknown technical setup case alone, so we need to deal with its outcome as well.

On the social side, if we introduce such generic GEs, they will be heavily used by people who want to enter their game releases quickly. So we kind of open the flood gates with this. But as I wrote in my blog post about the GE model, Oregami shall not become an expert-only project, so this is okay. The deeper research and use of the GE model is for the experts, and with the generic GEs, both sides may be happier.

On a crazy note, we could even turn this from a bug to a feature, and let new users choose from the generics ONLY. This way, the transition from another site may be easier, because the GE model looks familiar then to the newbie. If we recognize the newbie being ready for the next level, or he/she finds the switch all by himself, we can show him/her the rabbit hole. OTOH,we should make it very clear from the beginning, that Oregami has some kind of a scientific approach behind it, and serious contributing to Oregami will have quite a learning curve.

Another possibility would be to make the learning curve steep by continous back and forth with an approver, with the generic GEs being kind of a last resort. But IMHO this puts too much burden on the approvers, and turns off too many newbies, so is not a good idea. And when speaking about contributors leaving, we obviously need a better way to deal with abandoned submissions than MobyGames. I don't know the current amount of days, before Moby deletes a submission sent back to a contributor, but deleting is a no-go to me. Instead, we should open up the submission for other people to take over and complete.

On the technical side, your suggestion of intoducing a HWP called "Unknown hardware" and a SWP called "Unknown software" seems good to go to me.

Next thought: separating GEs for the same hardware by OS (i.e. "DOS PC" and "MS Windows PC") solves certain problems as discussed earlier. However, it will also lead to some bloat.

This was one of the main reasons why Iggy voted for an all-inclusive Microsoft-PC GE, spanning many, many decades of game development. I think we need to draw the line between DOS and Windows, because things have to end somewhere, and an all-inclusive GE would be too big to handle well.

But if we decide to draw this line, we need to do it with consequence, even if that means that every PC release of this time becomes a multi-platform release in our GE model. This may be bloat, yes, but imagine a user interested in the Windows platform only, and another one interested in the DOS platform only. For both, we need the distinction.

On a more general bloat note, we have similar problems with multi-platform OSs like Linux. Here we need many different GEs for every supported processor family (Linux@ARM, Linux@x86, Linux@WhatNot). So, if a game is released "for Linux", it may theoretically run on every of these Linux@ GEs. For this type of game documentation nightmare, I invented the GEGs, the Gaming Environment Groups, where we exemplary would collect all the Linux@ GEs within a Linux GEG. The user should then be able to switch his views and searches to GEG-based, taking away a lot of complexity. With a GEG, we would even be able to realize Iggy's dream of a joint Microsoft@x86 platform.

And let me throw one really strange example into the mix: The Elder Scrolls Adventures: Redguard. The box says "Windows 95". The game requires a 32-bit Windows (i.e. Win 95 or above) to install. Once installed, however, the game itself is 100% pure DOS (i.e. it runs in Win9x' DOS mode)- copy it to a DOS machine and it will run fine. So is this a "DOS PC" or a "MS Windows PC" game?

This is clearly a Windows game only, because it was released for this GE.

The DOS roots of this game are a case for our cross-platform compatibility model, please see the Gameboy Color example (Black/White mode) in my blog post about the GE model (quite down below). We would connect the two GEs "DOS PC" and "Windows PC" with a game-specific upward compatibility (which means that games released for Windows run under DOS under certain circumstances). Then, the users could enter DOS compatiblity information for Redguard, stating that one only needs to copy the files over to make it work.

Also, this reminds me a bit of emulator releases, where a game developed for an ancient GE is released for a newer GE using an emulator. Maybe, we even could treat such cases similar to emulator releases, because the game can only be played using the DOS emulator built into Windows after installation. Just to give some perspective, an emulator release, in the Oregami data model, shall be connected to both the release group for the new and the old GE, so people can see that this game was re-released when browsing through the releases for the original GE. For Redguard, this would mean a new release group for DOS PC being created, although the game was never officially released for this GE.

So much for now, still thinking about the other issues.