GamezWorld.de - Forum

Eigentlich stehen zwei Anführungszeichen um den Nickname (Eingabefeld). Sah aber nach zweimal hinschauen seltsam aus - daher aktuell entfernt (siehe Screenshot über Deinem Post).

XP statt Berufsausprägung:

Ich denke das ist eine gute Entscheidung, ich finde ihr habt schon jetzt mehr Einstellungen an einer Person, als ein Anwender tatsächlich setzen wird. Ich sehe jetzt schon den Knopf "Randomize" im Editor, der einfach Zufallswerte generiert.

Jobs/Attribute:

Ich selbst hätte es eher anders herum gesehen. Die Jobs sind maßgeblich und wirken sich auf die Attribute einer Person aus. Hake ich Moderator an, erhält die Person automatisch +1 Fame und +1 Appearance gutgeschrieben. Bei Director meinetwegen +1 Skill und +1 Power. Hake ich alle Jobs an, sollte die Person bei allen Attributen auf dem maximalen Wert stehen. Man würde so die Jobs zu "Templates" degradieren, um die korrekte Gewichtung aller Attribute untereinander zu vereinfachen. Ich behaupte das so gut wie kein Anwender weiß, dass ein Moderator spielintern auf Fame und Appearance angewiesen ist - sofern das nicht explizit im Spiel erläutert wird.

Deine Beschreibung liest sich etwas unpräzise, "grobe Eignung" wobei die Attribute mehr oder weniger zählen. Das erinnert mich an Rollenspiele wie ich sie hasse - 120 Charakterwerte - und am Ende stellt man fest, dass nur 10 davon kriegsentscheidend sind und die Skillpunkte in unnützem Beiwerk verbraten wurden. Manche aber schwören auf das Beiwerk, was ich gern als Ballast bezeichne :) - aber ich schweife ab, Konzentration auf den Editor.

Ich befürchte Du meinst irgendwas anderes, was ich nicht bedenke. Wenn Du auf den Screenshot im Eingangspost schaust: Ein Klick auf Personen im linken Navigationsbaum zeigt rechts in der Tabelle alle Personen an. Im Fall der <database.xml> sind das ca. 800-900 Einträge.

Wie Ronny schon bemerkt hat, ist die Liste aber derzeit nur rudimentär. Für eine erste Anzeige der Daten und das einfache durchscrollen ist sie praktikabel, bedarf aber zu gegebener Zeit noch etwas Zuneigung. So flexibel die Swing-Komponenten von Java manchmal sind, so arm an Funktionen ist der Standard.

Bin nun einige Tage viel unterwegs, melde mich Ende nächster Woche wieder. Sonst habe ich nachher noch ein schlechtes Gewissen zuviel Zeit von Ronny zu blockieren, die besser in die Entwicklung von TVT fließen sollte.

Dialog für Schauspieler

Die Schauspieler sind zu 90% implementiert, daher hier schon mal eine sehr konkrete Vorschau des Eigenschaftsdialogs:

(Rechtsklick -> Bild in neuen Tab öffnen für größere Ansicht)

Der erste Tab "General" (sehe grad das da fälschlicherweise noch "Properties" im Screenshot steht) sollte alles Wichtige beinhalten. Das ist entscheidend, denn alle anderen Tabs sind nur im Expertenmodus zu sehen. Bei dem Personentyp "Amateur" (Laiendarsteller trifft es als Begriff nicht so recht) sind zudem die Felder unterhalb des Trennstrichs deaktiviert. Noch weniger kann man kaum vom Anwender abfragen @TheRob.

Die Attribute als Zahlenbox in Kombination mit einem Slider - drängt sich förmlich auf. Zahlenraum ist auf 0-10 eingeschränkt. Das habe ich einfach mal anhand der niedrigen Werte in Ronnys XML angenommen.

Bei den Jobs (=functions) hatte ich erst eine Tabelle, wo man Einträge hinzufügt oder löscht, was einfach zu "fummelig" ist. Direkte Auswahlboxen erschienen mir einfacher und schneller zu bedienen. Ich habe hier erstmal 5 gleichzeitige Jobs vorgesehen. Wenn es tatsächlich mehr geben sollte, kann man noch weitere Auswahlboxen ergänzen. Das müssen dann aber wirkliche Multitalente sein ;)

Auf dem letzten Tab ist all das, was davor nicht unterzubringen war. Viel technischer Kram, IDs, Ersteller usw. Was noch fehlt ist Todestag und "price_mod". Todestag wird vermutlich auf dem ersten Tab benötigt? Und "price_mod" sagt mir nix, vermutlich auf dem letzten.

Hoffe es findet eure Zustimmung.

Persönliche Anmerkung zur Datenstruktur für Personen in der XML

• Wie erwähnt würde ich die Trennung von <celebritypeople> und <insignificantpeople> unter einem Knoten <persons> zusammenführen und die Unterscheidung zwischen Amateur und Star im <person>-Knoten selbst hinterlegen.

• Sofern als Grundlage für die Jobs (function) von Personen die Werte der Konstante TVTProgrammePersonJob herangezogen werden, hätte ich aufgrund der Skalierung der Werte auf Basis 2^n eine binäre Addition erwartet. Wie bei den Programmen für TargetGroups und PressureGroups. Stattdessen sind die Jobs einzeln in der XML abgelegt. Habe ich mich geirrt und <functions> sind was ganz anderes?

Anmerkung zur Abwärtskompatibilität:

Ich gehe davon aus, dass <version> eine Versionierung der Datenstruktur ist? Der Editor wird zukünftig alte Formate lesen, aber immer nur das neuste Format schreiben. Wenn Änderungen an den Strukturen vorgenommen werden, sollte man die Nummerierung bei <version> hochzählen. Trifft er eine Version an, die er nicht kennt, verweigert er die Zusammenarbeit mit der Datei.

Sollten Änderungen vorgenommen werden, dann wäre es gut, wenn in einer Formatversion möglichst alle Änderungen in einem Rutsch abgedeckt werden. Das verhindert, dass sich der Code unnötig aufbläht. Sprich wenn abseits von <person> noch andere Bereiche überarbeitet werden sollen, ggf. gleich mit berücksichtigen.

Das war mir beim Einlesen der Daten bereits seltsam vorgekommen, dass unterschiedliche Datenstrukturen für beide Personentypen verwendet werden. Der Beitag von Teppic trifft es  auf den Punkt. Ob eine Person "berühmt/bekannt" ist oder nicht, spiegelt bereits das Attribut "fame" wieder. 0-100 ist zudem  immer eine sehr einfach zu merkende Min/Max-Regel, da man intuitiv an Prozente denkt. Selbst wenn "Fame" nicht geeignet ist, würde ich dennoch beide Strukturen zusammenführen und intern über ein Attribut unterscheiden.

Man kann einfach die Werte bei Laien weglassen. Wenn ich keinen Geburtstag angebe, fehlt der Wert letztlich auch bei den Berühmtheiten.

Berühmtheit:
<person id="ronny-gertkalischke" fictional="1" creator="5578" created_by="Ronny">
  <first_name>Gert</first_name>
  <last_name>Kalischke</last_name>
  <functions>
     <function>1</function>
     <function>2</function>
  </functions>
  <details gender="1"  birthday="1943" deathday="2014" country="NL" />
  <data prominence="1" skill="2" fame="1" ... />
</person>

Laiendarsteller:
<person id="ronny-gertkalischke" fictional="1" creator="5578" created_by="Ronny">
  <first_name>Gert</first_name>
  <last_name>Kalischke</last_name>
</person>

Wenn der "Fame"-Wert allein nicht ausreicht (z.B. fame=0 für Laie), kann man im Knoten <person> noch Attribute oder Unterknoten als Flags mit führen, welcher Typ von Person es ist. Der Editor abstrahiert das eh, für den gibt es schon nur eine Klasse "Person", dessen Lade-/Speichermethoden die einzigen sind, die etwas von unterschiedlichen Strukturen wissen. Solltet ihr euch für andere Strukturen entscheiden, kann das in wenigen Codezeilen angepasst werden.

Oder um im Entwicklerjargon zu sprechen, die Berühmtheit ist lediglich eine Ableitung/Vererbung von Laie, die wiederum eine Ableitung/Vererbung von Person ist. Am Ende teilen sich alle dieselbe Struktur jeweils angereichert mit Zusatzinformationen.

p.s. was mich zudem stutzig machte war, dass es an einer Person sowohl das Attribut "creator" wie auch "created_by" gibt. Wäre von der Formulierung her für mich dasselbe. Dachte immer, dass in "creator" der Spitzname des Spielsatzerstellers drin steht. Dem scheint wohl nicht so. Kommt wohl eher der Name des Papas von der Person rein

Ihr seit flott, das muss ich sagen. Nun denn.

Mehrsprachigkeit

Zum einen wird der Editor natürlich mehrsprachige Spielsätze unterstützten. Zum anderen wird der Editor selbst im ersten Schritt in Englisch umgesetzt, da das heutzutage der kleinste gemeinsame Nenner ist. Es sei denn ihr entscheidet mehrheitlich, dass der Editor zuerst auf Deutsch entwickelt werden soll. Mir ist beides recht. Auf jeden Fall soll der Editor später eine Mehrsprachigkeit spendiert bekommen. Das Feature macht aber erst Sinn, wenn nicht mehr soviel verändert wird, sprich die Entwicklung ruhig vonstatten geht. Andernfalls ist die Gefahr zu hoch, dass bestehende Sprachdateien inkompatibel werden oder man große Teile ständig neu übersetzen muss.

"Sicht zu technisch"

@TheRob, was Du ansprichst wären eine Art Assistenten, die bestimmte Aufgaben trivialisieren - z.B. einen Film anzulegen. Hier wird es schwierig werden, genau zu definieren, was das Minimum an Metadaten ist. Wenn ich einfach nur Titel, Schauspieler und drei Werte angebe, reicht das am Ende tatsächlich für ein passables Spielerlebnis? Was passiert im Spiel, wenn man die Zielgruppen für einen Horrorfilm einfach weglässt (=alle) und er automatisch auch für Kinder tauglich ist? Ist das nicht gerade das A und O im Spiel, dass ich z.B. Horrorfilme nicht ins Kinderprogramm werfen sollte? Und wenn doch die Einschaltquoten den Bach runtergehen, plötzlich Werbeblöcke unter die Mindestzuschauerzahl fallen. Sind Spielsätze noch spannend, wenn man Ereignisse und Skripts komplett weglässt?

Kein einfaches Thema und gerade für den Anfang noch etwas haarig. Am Ende befürchte ich, dass ein guter Spielsatz nicht mit drei Klicks zusammengestellt werden kann, sondern durchaus von dem Ersteller ein paar Kenntnisse der Spielmechaniken abverlangt.

Um kreativ zu sein: Ich kann mir schon vorstellen, dass man im Menü einen Haken bei "Assistent" setzt und der Editor Werte vorbelegt und ggf. in Abhängigkeit automatisch setzt. So könnte er in dem Modus bei der Genreauswahl "Horror" intern automatisch die "Kinder" als Zielgruppe abwählen. Da finden sich bestimmt unzählige Beispiele, dem Anwender zu helfen.