Data Model: platforms

[MZ per X]

Opinions on my new approach?

No objections from my side.

The renaming of the subplatforms is okay, as long as this doesn't limit the use of these structures to what the name implies later on.

[gene]

I added a general and an exemplary "command flow" to my latest draft of the GamingEnvironment model.
That looks ok to me.

One thing that came to my mind when I wrote this down: I might strip out our complicated "transliterated string stuff" in the "first" (next) run. This would simplify development very much. We could later add transliteration features to the model. I want our software get up and running

[MZ per X]

I added a general and an exemplary "command flow" to my latest draft of the GamingEnvironment model. That looks ok to me.

For a start, it looks okay. For the future, it might be that the HardwarePlatform is already in the database, so we wouldn't need to create it. And of course the SWP is mandatory, too, for a GE.

One thing that came to my mind when I wrote this down: I might strip out our complicated "transliterated string stuff" in the "first" (next) run. This would simplify development very much. We could later add transliteration features to the model. I want our software get up and running

Okay, but please don't simplify too much, or we'll end up with what's already out there.

[gene]

Where exactly in our data model do we want to collect the information about "release dates" of hardware platforms/models?

E.g. let's look at the "Playstation 1" at Wikipedia. They define the release date for every HardwareModel:

PlayStation
JP: 3 December 1994
NA: 9 September 1995
EU: 29 September 1995
AU: 15 November 1995

PS one
JP: 7 July 2000
NA: 19 September 2000
EU: 29 September 2000

The same is done for the Amiga 500
Release date April 1987 (Netherlands), October 1987 (US)

Will we do this the same way? A release date on our "HardwarePlatform" level does not make sense.

So I would try to define a "regional release date" on the HardwareModel level.
Opinions?

Edit:
Is every release date a "full date"? Or may it also be "only a year" oder "year and month" ?

[MZ per X]

Will we do this the same way? A release date on our "HardwarePlatform" level does not make sense. So I would try to define a "regional release date" on the HardwareModel level.

I'm all for it, this is a regional connection with release date and probably local release name in it.

One level above, at the HWP, we should probably define something like a first release year (region-free ), for easy determination of the platform's age. And although we will need regional naming here, too, it probably doesn't make sense to add the regional release date to this regional connection, as we would have redundancy to the hardware model dates then.

Is every release date a "full date"? Or may it also be "only a year" oder "year and month" ?

Everything seems possible, especially for older hardware.

[gene]

Ok, here we have a first running version where you can add HardwareModels !
https://dev.oregami.org/gamingEnvironments

Great fun to use!

[MZ per X]

Great fun to use!

Indeed, thanks. And we don't have to click on "Show entry" after an edit any more which is very convenient.

What I would like to point out is the scope of the data level "HardwareModel".

This name sounds like we could use it for true hardware documentation, and thus add stuff like "European PlayStation 1 in green", "European PlayStation 1 in pink" and "European PlayStation 1 in black" to this data level. But no, it's different.

When you re-read my blog post about platforms, and there especially the paragraph about compatibility at the bottom, you will notice that this data level is defined to track game compatibility. For that purpose, it doesn't matter if a European PlayStation model came in a green, pink or black case. So, the data level "HardwareModels" is not really meant for single models of a HWP, but for game compatibility groups of models like "European PlayStation".

Having said that, it means that the concept of GE-->HWP-->HW_Model is part of our video game documentation, not of our future hardware documentation. A true documentation of hardware in all needed granularity (which we need to aim for, too, for non-profit reasons) will happen elsewehere in our future data model.

[gene]

What I would like to point out is the scope of the data level "HardwareModel".

This name sounds like we could use it for true hardware documentation, and thus add stuff like "European PlayStation 1 in green", "European PlayStation 1 in pink" and "European PlayStation 1 in black" to this data level. But no, it's different.

Well, that's really a very important point.
But that also gives me a bit of a headache: How can we make this fact clear to our users? And how can even experts distinguish between a "HardwareModel" that we do want here and and a "wrong HardwareModel" ?

Another question I do have:
In your glorious post you also mention emulators: "Below every HWP, we will use it for documenting specific models of that HWP, or software that emulates it."
Are we really serious about entering emulator software as "Hardware Models" ? I do understand what you mean, but during development this seemed a bit strange to me.
And: What about HardwareModels like the "C64 Mini" oder "SNES Mini" ? What type of HardwareModel are those?
Do wa have to distinguish between "pure software emulator" and "specific hardware with included software emulator"?

[MZ per X]

But that also gives me a bit of a headache: How can we make this fact clear to our users?

Maybe we should rename this data level back to sub-platform again, and add a fourth level beneath it for the true hardware model documentation. This fourth level doesn't need to be very sophisticated for now (i.e. name, picture, description), but people will understand everything better when it's there. And starting from this fourth level, we can later build our hardware documentation from the bottom up.

And how can even experts distinguish between a "HardwareModel" that we do want here and and a "wrong HardwareModel" ?

When I modelled the first HWP's here, I already noticed that this is awfully complicated (Just take a look at the ARM world.). I think we just need to accept that fact. Modelling our GE's, HWP's and sub-platforms will be subject to many discussions, changes, try and error. When Oregami will start, there will be basically only experts around, but later we should offer a detailed onboarding experience for new users to introduce them to the depths of our data.

Are we really serious about entering emulator software as "Hardware Models" ? I do understand what you mean, but during development this seemed a bit strange to me.

It seemed like a natural fit to me, because if HardwareModels are defined for tracking game compatibility, this facility should be easily re-usable for emulator compatibility, so I thought. Problem here is that many emulators emulate more than one HWP, or HWP and SWP together like DOSbox, which boils down to m:n connections. So I suggest we leave them out for now, and define later how to fit them in. Thinking about game preservation and such, emulators might even be too important to hide them so deep within our data model.

And: What about HardwareModels like the "C64 Mini" oder "SNES Mini" ? What type of HardwareModel are those? Do wa have to distinguish between "pure software emulator" and "specific hardware with included software emulator"?

We defined an additional attribute for emulator releases, so why not define something for emulator hardware, too?

[gene]

Ok, I removed the "Emulator version" (which was meant for pure software emulators) in the documentation and replaced it with a new entry for "Hardware with Emulator":

This entry represents all published special hardware devices that make games, that were previously available on the original hardware (console or computer) playable on a specific new game hardware using an internal emulator.
Examples: NES Mini, SNES Mini, C64 Mini.

Looks like this in our dev app:

[MZ per X]

Looks good, thanks.

What strikes me is that the SNES Mini comes with Starfox 2 preinstalled, a game which was never released before. What an interesting case for data modelling:

1) Create a game entry for Starfox 2

2) Create a release group with GE "SNES" under the Starfox 2 entry called "SNES Mini Version"

3) Create a game entry (Compilation) for the SNES Mini

4) Create a release group with GE "SNES" under the "SNES Mini (Compilation)" entry called "Initial worldwide release" (It may be that we would need more than one RG for different regional releases (for instance for different game selection in different regions)).

5) Mirror the hardware release dates as releases of the SNES Mini under the compilation RG, which are then again mirrored as emulator releases under the Starfox 2 RG (Even if the "SNES Mini Compilation" G entry had different RG's, we would only need one RG for Starfox 2, if they released the same version of it all over the world.)

Many things are possible with our data model.