Open Registry of Game Information 

  • Das ist es also, das Forum :)

  • Hier kann jeder Fragen zum Projekt stellen oder seine eigenen Ideen präsentieren.
    Keine besonderen Rechte erforderlich, um hier Beiträge zu schreiben!
Hier kann jeder Fragen zum Projekt stellen oder seine eigenen Ideen präsentieren.
Keine besonderen Rechte erforderlich, um hier Beiträge zu schreiben!

Moderators: MZ per X, gene

 #36092  by hydr0x
 09 Jul 2012, 19:14
Es freut mich dass ihr das öffentliche Forum und die Projektwebseite jetzt endlich realisiert habt :) Auch wenn ich natürlich eine "Konkurrenz"-Seite betreibe wünsche ich euch trotzdem eine erfolgreiche Umsetzung. Mehr Konkurrenz für MobyGames ist immer was gutes :mrgreen: Ich weiß ja aus Erfahrung wie langwierig die Erstellung des Datenmodells ist, bin also mal gespannt wie das bei euch so läuft.

Eine Frage hätte ich jedoch direkt mal. Warum kann man als registrierter Nutzer nur lesen aber nicht posten? Ums Verbergen geht es offensichtlich nicht, worum also dann? Habt ihr Angst dass die Themen mit zu vielen unqualifizierten Beiträgen vollgemüllt werden?

Jan
RetroCollect.com
 #36093  by gene
 09 Jul 2012, 19:35
Herzlich willkommen 8)

Auch wir sind gespannt, wie sich unser Projekt entwickeln wird. Sehr aufregend! :D
Zur Frage "warum kann man nicht überall posten" hatten wir uns generell gedacht, dass es vielleicht etwas zu "unsortiert" wird, wenn jeder User an jeder Stelle einfach mal so etwas posten kann. Das muss dann natürlich nicht gleich "unqualifiziert" sein, aber es könnte die Versuchung entstehen, mal eben schnell etwas zu posten (Frage, Idee, Meckern) ohne dass die Motivation besteht, sich etwas länger an unserem Projekt zu beteiligen.

Durch den "öffentlichen" Bereich bleibt der Entwicklungs-Bereich hoffentlich qualitativ "besserer", was auch das Einlesen für Interessierte vereinfacht.
Der öffentliche Bereich ist hingegen für Alle die Möglichkeit, ihre Ideen und Wünsche zu äußern, ohne dass der "offizielle" Entwicklungsbereich dadurch unübersichtlich wird.

Aber hey - auch diese Frage von dir ist absolut berechtigt und vielleicht überzeugst du uns ja auch dieses Mal mit deiner Anmerkung, evtl. Alles für registrierte User freizugeben.
Zur Erklärung für die anderen: Jan war derjenige, der mich darauf gestoßen hat, dass unsere Arbeit doch eigentlich öffentlich einsehbar sein müsste. Danke nochmal dafür! :D

Übrigens gibt es keine "superharten" Kriterien oder so, wann wir jemanden für den Entwicklungs-Bereich freischalten. Meiner Meinung nach sollten so viele Leute wie möglich mithelfen, aber es sollte wirklich ein gewisses Interesse vorhanden sein, unser Projekt etwas länger zu begleiten.
 #36094  by hydr0x
 09 Jul 2012, 19:43
Ich sag's mal so. Lese ich jetzt einen Punkt zu dem ich gerne etwas sagen würde dann müsste ich ein Thema zum gleichen Thema im öffentlichen Bereich eröffnen, handelt es sich dabei um was sinnvolles so müsste in Zukunft jemand beim einlesen in das Thema beide Themen parallel lesen. Deswegen mein Einwand. Und ganz ehrlich, wenn ich extra ein Thema eröffnen muss um auf einen Punkt einzugehen dann werde ich das eher nicht machen. Denn wie du ja selbst weißt, ich bin kein Mitarbeiter sondern nur ein interessierter Begleiter :)

So könnte ich z.B. anmerken das euer dreigliedriges Datenmodell das (wie immer: meiner Meinung nach) das richtige Grundprinzip ist (sieht bei uns genauso aus), aber im Detail evtl. noch mehr Abstufungen nötig sein werden. Das Patchmodell ist da z.B. interessant. Man könnte z.B. auch diskutieren ob erst Land, dann Version, oder umgekehrt (euer Lotus Beispiel zeigt erst Land, dann V1 V2 usw.). Aus Erfahrung kann ich nur sagen: Beide Reihenfolgen sind eigentlich nötig, aber schwierig gleichzeitig umzusetzen, speziell bei Beibehaltung der 3. Normalform.
 #36096  by MZ per X
 09 Jul 2012, 20:26
Hey Jan! :)

Auch von mir noch ein herzliches Willkommen und ein Dankeschön, dass wir durch Dein "Einschreiten" den Anstoß zur Veröffentlichung unserer Arbeit bekommen haben. Ich bin der festen Überzeugung, das war der richtige Schritt.
hydr0x wrote:Und ganz ehrlich, wenn ich extra ein Thema eröffnen muss um auf einen Punkt einzugehen dann werde ich das eher nicht machen.
Du hast sicher recht. Wenn jeder posten könnte, hätten wir wesentlich mehr Beteiligung in den Fachforen. Aber wie gene schon sagte, haben wir keine Lust auf Drive-by-Poster, die zu Einzelaspekten einen kurzen Senf dazugeben, ohne sich wirklich mal in die Problematik hineinzudenken. Das Thema Datenmodell ist einfach sehr komplex.

Davon abgesehen hätte ich nix dagegen, Dir Schreibrechte zu geben, auch wenn Du kein offizielles Mitglied des Teams bist. Aber Vorsicht, Du hast noch ein eigenes Projekt zu betreuen! :mrgreen: Ich schaue übrigens seit unserem Kontakt immer mal bei Euch vorbei, ob Ihr Euren FAQ schon veröffentlicht habt.
hydr0x wrote:So könnte ich z.B. anmerken das euer dreigliedriges Datenmodell das (wie immer: meiner Meinung nach) das richtige Grundprinzip ist (sieht bei uns genauso aus), aber im Detail evtl. noch mehr Abstufungen nötig sein werden. Das Patchmodell ist da z.B. interessant.
Wir hatten anfangs noch mehr Abstufungen geplant, wir wollten den Versionsstand (Patchlevel) als vierte Datenebene einführen. Damit hätten wir wirklich fast alles abbilden können. Aber Theorie und Praxis sind halt öfter mal verschiedene Dinge, aber lies selbst. :)
 #36097  by hydr0x
 09 Jul 2012, 21:33
MZ per X wrote:Aber Vorsicht, Du hast noch ein eigenes Projekt zu betreuen! :mrgreen: Ich schaue übrigens seit unserem Kontakt immer mal bei Euch vorbei, ob Ihr Euren FAQ schon veröffentlicht habt.
Keine Sorge, FAQ kommt, genau wie ein paar andere "Textdokumente". Da die Nachfrage nach bestimmten nach fehlenden Platformen aber groß war hatte das Priorität. Zuletzt kam das Atari 2600 dazu, jetzt fehlt im Konsolenbereich nicht mehr viel. Ist bei uns ja "redaktionelle" Arbeit da nur komplette und verifizierte Systeme gelistet werden. Von daher stand das FAQ eher hinten an. Nicht weil es nicht wichtig wäre, sondern weil es keine Nachfragen in diese Richtung gibt.
Wir hatten anfangs noch mehr Abstufungen geplant, wir wollten den Versionsstand (Patchlevel) als vierte Datenebene einführen. Damit hätten wir wirklich fast alles abbilden können. Aber Theorie und Praxis sind halt öfter mal verschiedene Dinge, aber lies selbst. :)
Hab den Patchlevel ja erwähnt ;) Ich bezog mich allerdings vor allem auf das z.B. im Lotus-Beispiel aufgeführte Sammelsurium innerhalb von der 3. (unteresten) Ebene. Da hatte Gene so ein Modell gemalt wo dann UK V1, UK V2, DE V1 usw drin standen. Ist da mit V1 jeweils das gleiche gemeint? Oder war das einfach eine Nummerierung innerhalb von DE bzw. UK. Und wie werden dann UK V1 und UK V2 persistiert? Was wenn ich Infos zu V1 möchte, unabhängig ob es jetzt die UK V1 oder die DE V1 ist? Etc :)
 #36101  by MZ per X
 10 Jul 2012, 20:19
hydr0x wrote:Da die Nachfrage nach bestimmten nach fehlenden Platformen aber groß war hatte das Priorität.
Das verstehe ich sehr gut. Direkt am fachlichen Content zu arbeiten macht viel mehr Spaß als diese verwaltungstechnischen Dinge. :)
hydr0x wrote:Ich bezog mich allerdings vor allem auf das z.B. im Lotus-Beispiel aufgeführte Sammelsurium innerhalb von der 3. (unteresten) Ebene. Da hatte Gene so ein Modell gemalt wo dann UK V1, UK V2, DE V1 usw drin standen. Ist da mit V1 jeweils das gleiche gemeint? Oder war das einfach eine Nummerierung innerhalb von DE bzw. UK.
Mit V1 ist dort nur die Erst-Veröffentlichung (VÖ) jedes Landes gemeint, mit V2 beispielsweise eine spätere Budget-VÖ. Das heißt nicht, dass V1 UK exakt der gleiche Karton /die gleiche Version wie V1 DE ist.
hydr0x wrote:Und wie werden dann UK V1 und UK V2 persistiert? Was wenn ich Infos zu V1 möchte, unabhängig ob es jetzt die UK V1 oder die DE V1 ist? Etc :)
Wir haben ja als mittlere Datenebene die Veröffentlichungsgruppe (VÖG), wo es pro Plattform mindestens eine geben muss. Dort werden gleichartige VÖ zusammengefasst. Wenn sich also V2 UK signifikant von V1 UK unterscheidet (Remake oder Enhanced Version), dann bekommen alle V2 ihre eigene VÖG. Ebenso, wenn sich die V1 UK signifikant von der V1 DE unterscheidet (z. B. durch Zensur). Dann bekommen die deutschen VÖ ihre eigene VÖG.

Unterscheiden sich V1 UK und V1 DE nicht signifikant, dann müssen die Unterschiede über die üblichen Verdächtigen herausgearbeitet werden: Fotos und Beschreibung des Packungsinhalts, Screenshots der beiden Lokalisierungen, Informationen zum enthaltenen Patchlevel mit Patchtabelle, etc..

Wenn Du Dich für das Konzept der VÖG tiefer interessierst, dann schau Dir mal das Datenmodell der X-Wing / TIE-Fighter-Serie an, dass ich im Wiki gerade ausarbeite. Uff, diese Spieleserie hat es in sich! Aber die VÖG habe ich schon fertig. :)
 #36109  by hydr0x
 11 Jul 2012, 20:58
MZ per X wrote:Das verstehe ich sehr gut. Direkt am fachlichen Content zu arbeiten macht viel mehr Spaß als diese verwaltungstechnischen Dinge. :)
Ach nö, Atari 2600 recherchieren war jetzt nicht grade spaßig ;) Aber die User haben halt die Macht und haben klar gesagt was sie aktuelle gerne sehen wollen :mrgreen:
Mit V1 ist dort nur die Erst-Veröffentlichung (VÖ) jedes Landes gemeint, mit V2 beispielsweise eine spätere Budget-VÖ. Das heißt nicht, dass V1 UK exakt der gleiche Karton /die gleiche Version wie V1 DE ist.

Unterscheiden sich V1 UK und V1 DE nicht signifikant, dann müssen die Unterschiede über die üblichen Verdächtigen herausgearbeitet werden: Fotos und Beschreibung des Packungsinhalts, Screenshots der beiden Lokalisierungen, Informationen zum enthaltenen Patchlevel mit Patchtabelle, etc..
Okay, letzteres finde ich eben genau noch sehr schwammig. Ihr habt also quasi eine flache Struktur (sagen wir mal eine Liste), in der dann einfach alle "insignifikanten" Varianten innerhalb einer VÖG ohne Hierarchie gelistet, sind, ja? Ich bin mir nicht sicher ob das für die ein oder andere Funktionalität ausreicht.
Wenn Du Dich für das Konzept der VÖG tiefer interessierst, dann schau Dir mal das Datenmodell der X-Wing / TIE-Fighter-Serie an, dass ich im Wiki gerade ausarbeite. Uff, diese Spieleserie hat es in sich! Aber die VÖG habe ich schon fertig. :)
Keine Sorge, ich hab mir die Themen schon vorher angeschaut ;)
 #36110  by MZ per X
 11 Jul 2012, 21:20
hydr0x wrote:Ihr habt also quasi eine flache Struktur (sagen wir mal eine Liste), in der dann einfach alle "insignifikanten" Varianten innerhalb einer VÖG ohne Hierarchie gelistet, sind, ja?
So könnte man es sagen, ja. Aber welche Hierarchie fehlt Dir denn genau? Patchlevel? Erst- vs. Zweit- vs. Budget-VÖ?
hydr0x wrote:Ich bin mir nicht sicher ob das für die ein oder andere Funktionalität ausreicht.
Ich auch nicht. :) Deshalb bin ich gespannt, auf was für Sachen wir bei den Beispielmodellierungen noch so stoßen werden. Welche Funktionalitäten hast Du denn konkret im Sinn, die problematisch sein könnten?
 #36111  by hydr0x
 12 Jul 2012, 21:22
Spezielle Funktionen fallen mir jetzt nicht ein, aber das offensichtlichste Problem sind natürlich redundante Daten. DE V1 und DE V2 haben z.B. das gleiche Land, aber vielleicht auch den gleichen Alternativtitle, lokalen Distributor etc. Wenn das jetzt alles flach eine Liste ist funktioniert das sicher auch, aber diese Infos müssen mehrfach gespeichert werden was dann wiederum recht flott zu Inkonsistenzen führen kann.
 #36113  by MZ per X
 15 Jul 2012, 20:16
hydr0x wrote:... aber diese Infos müssen mehrfach gespeichert werden was dann wiederum recht flott zu Inkonsistenzen führen kann.
Du hast vollkommen recht. Ich hatte am Anfang noch von der theoretisch perfekten Datenbank geträumt, ohne Redundanzen und konsequent logisch abgebildet. Aber die Praxis besteht leider aus Kompromissen, wie das Beispiel Patchlevel sehr anschaulich gezeigt hat.

Sicher könnten wir jede Redundanz durch Einführung einer zusätzlichen Datenebene (wie zB das Land) verhindern. Aber erstens würde das die ohnehin hohe Komplexität der Datenbank noch potenzieren, zweitens wahrscheinlich dem Benutzer beim Erfassen seiner Spielesammlung noch mehr Mussdaten und Recherchen abfordern (abschreckend für manche) und drittens in meinen Augen dadurch auch die Fehlerquote und damit den Korrekturaufwand erhöhen. Die Leute wollen dann einfach schneller irgendwas bei den Mussdaten eingeben, um ihre VÖ reinzubekommen bzw. sie verstehen das Datenmodell nicht mehr. Oder wir sind nicht mehr in der Lage, das Datenmodell in eine einfach zu bedienende UI abzubilden.

Zur Zeit sehe ich die einfachere Lösung darin, bei den VÖ Redundanzen zuzulassen. Die Leute können schön ihre Daten pro VÖ eingeben, kriegen ihre Belohnung und Bestätigung dafür, und wir leiten sie mit Konsistenzprüfungen und intelligenten Eingabemasken mit Vorbelegungen zur korrekten Dateneingabe. :)

Hoffe ich zumindest.
 #36117  by hydr0x
 17 Jul 2012, 22:24
Klar, ist ja bei Datenbanken immer ein Kompromiss zwischen praktischen Zwängen und theoretischen Wünschen. Bei uns gibt es auch Redundanzen, wobei die tatsächlich mehr dem Überblick für Bearbeiter dienen. Ich glaube das Modell könnte auch noch völlig ohne Duplikate auskommen, der Code nutzt die Duplikate meist auch gar nicht, wenn dann nur um SQL-Joins zu vermeiden. Funktional also ersetzbar. Aber da hat natürlich auch jedes Projekt andere Gründe für bestimmte Ansätze. So müsst ihr ja wie du sagst dem Dateneintrag durch User Rechnung tragen. Wir haben da ja ein anderes eher redaktionelles System weitesgehend ohne webbasierte Eingabemasken. Dadurch sind ganz andere Usability-Anforderungen da.