Open Registry of Game Information 

  • Data Model: platforms

  • Talk about specific features of our upcoming online game database.
Talk about specific features of our upcoming online game database.

Moderators: MZ per X, gene

 #38406  by MZ per X
 05 Mar 2017, 22:30
TerokNor wrote: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.
Macintosh is a nightmare, too, no doubt about this. I have to admit that I gave up in frustration on researching this model family, to return later. So I will just give a quick guess on the needed GEs here, you probably already named them:

Classic 68K Mac
Classic PPC Mac
OS X @ PPC Mac
OS X @ x86 Mac
(Windows @ x86 Mac)
(Linux @ x86 Mac)
(Linux @ PPC Mac)

Again, I'm against doing an all-inclusive GE, for the same reasons like in the PC case, but I'm all for doing a "Macintosh" GEG to encompass the above four GEs, and I'm all for offering a generic Macintosh GE like discussed above, maybe even one for Classic MacOS and one for OS X. Let's take a look at the transitionals:

68K to PPC: This depends on what GE the game in question was released for, i. e. what was advertized on the box. I'm no Mac expert, but I assume that there's been only "Mac" shown on nearly all the boxes of that time. So, the separation would have to follow the system requirements shown on the box, which makes three cases then:

1) PPC-Mac excluded ---> GE is Classic 68K Mac
2) 68K-Mac excluded ---> GE is Classic PPC Mac
3) Everything else ---> double listing, i.e. technical multi-platform release

Of course, we would connect the two classic Mac GEs with a general downward compatibility, to show that ~all games released for Classic 68K Mac also run on a Classic PPC Mac.

PPC to x86: This is similar to the above, it's just that I guess there would be no general downward compatibility from Intel down to PPC.

1) PPC-Mac excluded ---> GE is OS X @ x86 Mac
2) x86-Mac excluded ---> GE is OS X @ PPC Mac
3) Everything else ---> double listing, i.e. multi-platform release (this time not only technical in a Oregami sense like above, but a real one by fat binaries)
 #38407  by MZ per X
 06 Mar 2017, 11:11
MZ per X wrote:3) Everything else ---> double listing, i.e. multi-platform release (this time not only technical in a Oregami sense like above, but a real one by fat binaries)
Just to avoid misunderstanding, double listing doesn't mean doubled data. There's still just one release in the database, but this release gets connected to two release groups.
 #38408  by MZ per X
 06 Mar 2017, 21:51
TerokNor wrote:And once we move into modern mobile platforms, it becomes *really* complicated. ...
And it becomes even more complicated with Windows Store apps.
Yeah, the future is here, because they learned from the past. Quoting from the "Platform Independence" section of my GE blog post:
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!
We will soon hit a wall with our endeavour to document the GEs as a combination of hardware and software, because the world will move on and leave that concept behind. The future comes in software platforms, where the hardware running this stuff is either unknown or just not important any more, because games are released for the software platform and run on every GE where that platform runs. This is already known from Browser games, or ever heard of Snaps for Linux? Go look.

So, I strongly suspect that Android, Windows Apps, and Snaps, are the beginning of where we just say: Hey, GE = SWP, while the HWP for all three is just "All supported hardware". Because everything else might be just pointless. OTOH, I invented a data structure to map the compatibility of SWPs to HWPs, this structure is what we will be gardening then, because there is the possibility to connect Windows Apps to the Xbox, for instance. :)

But in the beginning, there will be games not running on every supported HWP, or every version of the SWP. These incompatibilities can be tracked using the data structure we use e.g. for Windows OS versions.
 #38409  by MZ per X
 08 Mar 2017, 21:19
TerokNor wrote:For many games (i.e. thousands and thousands), each has its own unique hardware and no system software. How would GEs apply here?
Could you elaborate on that, or give me a link for further reading?
 #38410  by hydr0x
 08 Mar 2017, 21:57
MZ per X wrote:
TerokNor wrote:For many games (i.e. thousands and thousands), each has its own unique hardware and no system software. How would GEs apply here?
Could you elaborate on that, or give me a link for further reading?
He's talking about Arcade games of which most, up to the 90s, had a completely individual PCB design per game, with no common architecture between games. So yes, strictly speaking, a different hardware platform per game.
 #38422  by MZ per X
 26 Mar 2017, 21:06
Okay, this seems a bit like old handheld games. Here we don't have another option than to create generic GEs, I suppose.

For Arcades this would be something like "Arcade / Custom Board" with "Custom Arcade Hardware" as HWP and a fitting SWP for the case at hand. We would have all these games under one GE then, but would need to document the board hardware somehow. We could either use the data structure for usual system requirements of none-Arcade games for this, or even define every custom board as a hardware subplatform under the above mentioned HWP, and keep moving from there.

Not sure which way to go, this depends a bit on how we end up documenting hardware in general. We'll see.
 #38428  by hydr0x
 04 Apr 2017, 18:51
Yeah, unfortunately they are doing it completely wrong. They list the whole system as a "game" for the platform dedicated console. There is no meaniningful/relational way to list the games available on the system, nor is there even a way to list games or versions only released for them separately. There is also no way to link related dedicated platforms or store their shared technical properties (e.g. all Tiger LCD games).
 #38429  by MZ per X
 05 Apr 2017, 14:12
I wouldn't call this "completely wrong", I'd rather say it's appropriate to their current limited data model. People obviously want to contribute that stuff, so they found a way to cram it in.

They will probably list all the included games as alternative titles to the "game" entry, so these can later be found in the search. For relations between those entries they will prolly use their game group feature, as in there will be a game group called "Tiger LCD Games" which incorporates all the relevant entries.
 #38430  by hydr0x
 05 Apr 2017, 15:57
MZ per X wrote:I wouldn't call this "completely wrong", I'd rather say it's appropriate to their current limited data model. People obviously want to contribute that stuff, so they found a way to cram it in.
Well, their limited data model can't handle this kind of thing. So yes, they did the best they could without having to design new aspects of the model, but that's it. Imho, that's still wrong, even if it was their only feasible option.
They will probably list all the included games as alternative titles to the "game" entry, so these can later be found in the search. For relations between those entries they will prolly use their game group feature, as in there will be a game group called "Tiger LCD Games" which incorporates all the relevant entries.
Yes, most likely, you can use groups/tags to circumvent any flaws in the design, but then you end up with - I'm exaggerating here of course! - with a flat list of game entries with properties.
 #38431  by gene
 25 Apr 2017, 22:25
I would like to make a completely different remark on this topic.

Up to now we did not think about "credits for gaming paltforms", did we?

What I mean is:
We could (should?) also give credit to the people and companies who were involved in the research, development, manufactoring and perhaps more aspects of Hard- and Software-Platforms.

Think about it!
 #38432  by MZ per X
 26 Apr 2017, 10:00
gene wrote:We could (should?) also give credit to the people and companies who were involved in the research, development, manufactoring and perhaps more aspects of Hard- and Software-Platforms.
We should. Companies okay, but I must admit that I never saw people credits for a console or an operating system in the wild. Except Linux, for open source projects you usually find a credits file or something.

Do you have a link to a credits set for, say, Windows or a popular console? It must be thousands of people!
 #38433  by gene
 26 Apr 2017, 21:46
MZ per X wrote:Do you have a link to a credits set for, say, Windows or a popular console? It must be thousands of people!
No, I don't have such a thing :-)
It just came to my mind during the creation of the Oregami Context Map.
 #38434  by hydr0x
 27 Apr 2017, 15:46
MZ per X wrote: We should. Companies okay, but I must admit that I never saw people credits for a console or an operating system in the wild. Except Linux, for open source projects you usually find a credits file or something.
The question is if you do actually need real "credits" to link a person as a developer for a console (or even a game). You could still attach e.g. Ralph Baer as the Odyssey designer even if there is no paper to prove it. Just mark these kinds of "credits" and, ideally, link some secondary sources to it.
 #38520  by gene
 26 Sep 2018, 16:49
I have started a technical redesign of our Gaming Environment context.
Image

The biggest difference to the previous approach lies in the division into several different "aggregates". The reason for this is that in Domain Driven Design there is a rule according to which objects outside a bounded context may refer to objects inside only via the ID of the root object of the aggregate. Until now, the root object for the only aggregate was our gaming environment. However, many things will have to refer to hardware (sub-)platforms from "outside". Hence this separation.

At the same time I have made renaming:

previous name / new name

Hardware Sub-Platform / Hardware Model
Software Sub-Platform / Operating System


Opinions on my new approach?