GamezWorld.de - Forum
Von Spielern für Spieler
Du bist nicht angemeldet.
Hallo zusammen,
ich wurde quasi von einem anderen Projekt kurzerhand abgeworben und bin nun bei TVTower gelandet. Mein konkretes Ziel hier bei euch soll die Erstellung eines Editors für die Spielsätze sein, die derzeit im XML-Format vorliegen und wohl noch aufwändig per Hand editiert werden. In Abstimmung mit Ron erschien ein Forenbeitrag als sinnvoll, um allen anderen aktiven Mitgliedern die Möglichkeit für Feedback zu geben.
Editor
Ich entwickele den Editor in Java und stelle den Quellcode als open source zur Verfügung. Das ermöglicht die Nutzung für nahezu alle relevanten Plattformen. Derzeit liegt nur ein GUI-Konzept bzw. Prototyp vor, um zum einen Feedback einzuholen, zum anderen damit ich einen Überblick bekomme, was alles benötigt wird.
Einen groben Eindruck bekommt man, in dem man sich die JAR-Datei herunterlädt und selbst startet (aktuelles Java vorausgesetzt). Wie erwähnt ist das nur eine leere Hülle, um eine Grundlage für Vorschläge/Diskussionen zu haben. Für einen schnellen Blick ein Screenshot:
Download:
http://www.devsource.de/tvtower/tvtdbedit/TVTDBEdit.zip
Feedback
Jede Frage, Anmerkung und Vorschlag ist gern gesehen. So wurde ich schon auf einige Dinge hingewiesen (Zuordnung von Episoden zu Serien, Abgleich mit IMDB/TMDB usw). Wer also Probleme im aktuellen GUI-Konzept sieht oder sich bestimmte Dinge noch nicht so recht vorstellen kann, einfach posten. Irgendwie muss man ja einen Anfang finden, nicht wahr.
Davon ab werde ich den Editor etappenweise entwickeln und die hier verlinkte JAR-Datei entsprechend aktualisieren. Wer Interesse hat, kann so die Entwicklung begleiten. Ich freue mich darauf, der ein oder andere von euch hoffentlich auch. Und wenn alle Stricke reißen, XML-Dateien lassen sich weiterhin mit einem Texteditor bearbeiten :)
Ansonsten sei der Vollständigkeit halber für alle Leser erwähnt, dass ich kein Mitglied des Entwicklungsteams bin - seht mich als freiwilligen Helfer und alten Gamer, der in jungen Jahren viele Stunden in MADTV verbracht hat.
Gruß
Mayo
Beitrag geändert von Mayo (03.11.2015 14:20)
Offline
Willkommen Mayo.
Auf die Knie fallend und einige Freudentänze aufführend. Freue mich sehr. Und ich bin sicher, DAS hilft.
Und somit fange ich direkt mit Anmerkungen an.
Download werde ich noch machen. Die Zeit finde ich sicher. Bis dahin mein erster Eindruck nur auf dem Screenshot basierend.
Da ich mich in die XML eingearbeitet habe, möchte ich direkt sagen: Zu nah am Code. Imho muss da noch der Dolmetscher rein. Die GUI sollte sehr einfach und verständlich sein. Einfach so, dass jeder der sie nutzt nicht einmal ahnt, was Du in Wirklichkeit geschaffen hast.
So nach dem Motto: Cool. Das ist ja einfach. Hat bestimmt nur eine halbe Stunde gedauert, das hin zu zimmern.
Denn aus der Sicht des Laien Spielers: Mir fehlt ein Film. Oh cool es gibt einen Editor. Geil Tippe ich schnell ein. Starten, geht bestimmt schnell. Ähh, database, mayo, Fake, 001 oder 128, 02.... Was? Was willst Du denn? Och nö, so wichtig ist es mir auch nicht...
Und dementsprechend: Keine Code Wörter in der Auswahl. Keine DB, keine Code Gruppierung.
Einfach RL Sprache bei allem.
Du kannst Dir sicher sein, dass ich Dich mit Beiträgen unterstütze. Motzend und konstruktiv. Und mit dem Respekt, dass ich verstehe, was es an Zeit kostet und das es Dein Werk ist.
Deswegen herzlich willkommen. Schön, dass Du da bist. Und wenn ich Dir gedanklich helfen kann. Sehr gerne. Auch wenn ich die neue Version leider noch nicht gespielt habe. Die stelle ich mir dann als Perle zurück, damit ich was beitragen kann.
Offline
Willkommen dahier!
Ich werde die nächsten Tage sicher immer mal Wünsche auflisten.
@Sprache
Mir wäre es lieb, wenn es irgendeine Möglichkeit gäbe, daß die Menüsprache durch die Benutzer verändert werden kann.
Durch Klick oder Einlesen der jeweiligen Sprachdatei oder eine andere Möglichkeit.
@Komplexität
Um TheRobs Bedenken bezüglich "zu nah am Code" aufzugreifen:
Ich fände es gut, wenn der Editor über zwei Ebenen verfügen würde.
Einmal die einfache, die für Spieler dasein soll, die ihre eigenen Filme eintragen wollen.
Da gibt es nur eine einfache Maske für Titel, Text und Akteure nebst Schiebereglern oder Zahlenfeld für Kritk, Tempo etc.
Für Werbung, Drehbücher und Nachrichten ähnlich.
Die zweite Ebene des Editors wäre dann die Entwicklerebene. Dieser würde Mayos Screenshot oben entsprechen.
Kann auch sein, daß dafür zwei Editoren günstiger wären... ??
Nun, ich hoffe, daß wir hier nicht am Ende die eierlegende Wollmilchsau fordern. 
Offline
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.
Offline
Ich habe mit Mayo ja schon ein wenig EMailverkehr gehabt (ich hoffe Dir hats auch gefallen ;-)), deswegen nun nur noch Reaktion auf die hier vorgebrachten Bemerkungen.
@Assistenten und "Was ist notwendig"
Nun, erstmal vorweg: eine Zielgruppe muss nicht angegeben werden. Sie dienst eher der Manipulation des vorherrschenden Klischees. Fuer Filme wird in der Datei "config/programmedatamods.xml" fuer jede Zielgruppe festgelegt, in welchem Masse ihr bestimmte Genre liegen - und ob es hierfuer gute und schlechte Uhrzeiten gibt.
Die Zielgruppe ist nunmehr fuer Dinge wie "Teenie-Slasher", Teenagerkomoedien (Scream, American Pie). Auch kann sich eine Dauerwerbesendung an Manager richten ...
Kurzum: Die Zielgruppe ist eine "erweiterte" Eigenschaft.
Was m.E. benoetigt wird:
Titel
Beschreibung
Cast (Mehrfachnennung - bei verschiedenen Jobs - moeglich, Drag'n'Drop-Sortierung bzw "hoch/runter"-Pfeile praktisch)
Drehjahr
Herstellungsort
Hauptgenre
Subgenre (Mehrfachauswahl moeglich)
Flags (FSK18, Dauerwerbesendung, B-Movie ... im Basismodus evtl nicht alle anzeigen)
Episoden (wuerde ich im Basismodus auch anzeigen)
Der erweiterte Bereich bietet dann alle Modifikatoren (Preis, Alterung ...) sowie den Zugriff auf Effekte (Newsfreigabe) und alle Flags.
Beim Erstellen von News hingegen, gehoeren die Folgenews ja zu einer "Standardaktion", hier sollten also die "Newstrigger" auch im Basismodus zu sehen sein.
Weiterhin zu bedenken ist, dass wir ueberlegen muessen, was immer "erweitert" ist. Halt im Hinblick darauf, dass bei allen Editoransichten eine gewisse Konsistenz herrscht. Ob dies aber bei "Werbung" (die relativ wenige Daten erfordert) schick und praktikabel ist...weiss ich nicht.
Generell wird die "Werbung" wohl eigentlich am einfachsten zu erledigen sein.
@Wuensche an den Editor
Weil Gast2 dies ja nun "haendisch" erledigt hat: Was haltet ihr von weiteren Assistenzfunktionen - wie der "relativen Anpassung aller Eintraege"? Konkret meine ich, dass man den "Profit" aller Werbevertraege mit einem Faktor multiplizieren kann - damit sollte ein Balancing vielleicht praktikabler zu erledigen sein (die Feinjustage dann, nach der groben Neuausrichtung).
@Import von IMDB/TMDB...
Hier sollte darauf geachtet werden, dass als "Standard" die Bereiche "title_original" statt "title" usw. ausgefuellt werden. Auf explizite Nachfrage der Nutzer kann dies aber umgestellt werden ("Bestaetige bitte, dass es Dir rechtlich gestattet ist, Originalnamen zu nutzen..." - oder aehnlich).
Interessant koennte hier ein Feature gestaltet werden, was in eine "zzz.xml" alle Objekte exportiert (nur per GUID referenzieren) dort aber dann die Originaltitel reinschreibt - sozusagen alle Objekte mit Originaldaten "erweitert".
bye
Ron
Offline
Von meiner Seite besteht kein Wunsch nach Assistenten.
Nur die normale Sprache. Ich persönlich glaube, dass man zu viele Menschen mit technischer Sprache abschreckt. Wir wollen ja Input. Und da ist mir Dein Screenshot noch zu techniklastig.
Keine Ahnung. Hmmm. Zahnarzt? Wenn man bei dem sitzt, will man eigentlich wissen, was Sache ist. Aber die meisten sprechen Zahnarztmüll. Schön, dass es in die Akte passt. Und die Fach... von der Krankenkasse verstehen es auch. Aber der Patient?
Kannst Du nachvollziehen, was ich meine?
Offline
Nur die normale Sprache. Und da ist mir Dein Screenshot noch zu techniklastig. Kannst Du nachvollziehen, was ich meine?
Ich weiß was Du meinst, ist der gleiche Effekt wie bei mir an der Arbeit, wenn einer der Seniorentwickler versucht dem Vertriebsteam technisches Hintergrundwissen zu vermitteln. Nur sehe ich derzeit dieses Problem im Editor nicht so recht. Wenn man z.B. den Eigenschaftsdialog für Personen öffnet, werden dort als Formular ganz alltägliche Informationen abgefragt - Vorname, Nachname, Geschlecht, Geburtstag. Das GUI-Konzept sieht vor, dass mit jedem Reiter, denn Du weiter nach hinten wechselst (was Du nicht tun musst), die Themen komplexer werden.
Auf dem zweiten Reiter findet man in Listenform alle Persönlichkeitswerte wie Charisma, Prominenz, Humor usw. Alles wie ich finde noch unkritisch.
Erst auf dem dritter Reiter, der hier "Advanced" heißt, könnte es technisch werden. Aber da muss der Anwender auch nicht hinwechseln. Oder man blendet die Reiter im Standard aus und man kann via Optionen den Profimodus aktivieren, um sie wieder einzublenden.
Im Idealfall sind alle Pflichteingaben (zum Anlegen einer Person) auf dem ersten Reiter zu finden. Welche Felder dort am Ende nun genau stehen, dass muss ich mit euch dann absprechen. Es kann durchaus sein, dass man die ID und 1-2 anderen Felder auf hintere Tabreiter verschiebt.
Ich habe eher das Gefühl, dass Du die englischen Begriffe als "technisch" erachtest, weil sie Dir in der XML-Struktur begegnen. Als ersten Start werde ich mal die Personen in Angriff nehmen, so dass man mal eine der XML öffnen und die Daten sehen kann. Dann schauen wir uns das am Besten nochmal an. Es hilft vielleicht, das am konkreten Beispiel zu erörtern.
Beitrag geändert von Mayo (03.11.2015 00:26)
Offline
Oder man blendet die Reiter im Standard aus und man kann via Optionen den Profimodus aktivieren, um sie wieder einzublenden.
Das würde ich gutheißen.
Was haltet ihr von weiteren Assistenzfunktionen - wie der "relativen Anpassung aller Eintraege"
Daß damit die Einträge (Faktoren) aus den .xmls des /config-Ordners ersetzt werden?
Wirklich hilfreich wäre für mich das, was eine Tabelle kann:
Formeln für die Berechnung von Werten einzutragen.
Zu Illustration nochmal die Werbungstabelle:
http://filehorst.de/d/bwunodiw
Ungefiltert, wünsche ich mir eine ähnliche Ausgabe.
Was nützlich wäre:
Ich möchte eine automatische Markierung von z.B. aller Werbungen mit min_image 12 und dann eine Umwandlung in z.B. min_image 13. Oder das max_image auf 53 setzen. Oder die Strafe (penalty) um den Faktor 1,5 erhöhen...
Kurz, ich würde mir weniger eine generelle Veränderung durch die Assistenzfunktionen wünschen, denn eine gezielte.
Offline
> Oder die Strafe (penalty) um den Faktor 1,5 erhöhen...
Das ist die Sache, die ich meinte. Statt absoluter Angaben, relative Angaben machen zu koennen.
Interessant ist sowas generell bei Zahleneingabefeldern. Steht da 1.5 und man tippt nun *1.5 dazu...sollte es 2.25 werden
@mayo
Die Personen gibt es in zwei "Klassen". Eventuell sollte der Registerreiter 1 die Daten der Insignificants anfordern. Ist dannReiter 2..3 ausgefuellt, wird daraus ein Promi.
Wir koennten aber auch ueberlegen, die Klassifizierung in der DB aufzuheben und sie nur in der Spiellogik zu verwenden.
bye
Ron
Offline
Lest mal meine Idee in diesem Post,
darin habe ich einen Vorschlag formuliert, das
bisherige 2 Klassen-System für Personen zu verändern.
Offline
Die Personen gibt es in zwei "Klassen".
[...] Vorschlag formuliert, das bisherige 2 Klassen-System für Personen zu verändern.
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.
[aus anderem Thread] Die Unterscheidung bei "unbekannt" und "bekannt" auf spiellogischer Ebene ist, dass fuer "Promis" zusaetzliche Daten gespeichert werden (bzw notwendig sind).
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 
Offline
Ja ein paar der "Namen" in der DB koennen wir gern abaendern, die stammen von STARSCrazys damaliger "v3"-Struktur (von mir war "v2"). Da kam auch die "insignificants" und "celebrities"-Unterscheidung.
Bei mir wird intern "TProgrammePersonBase" und "TProgrammePerson" genutzt. Basis ist der "unbedeutende" (mit sowenig Daten wie moeglich) und der Celeb ist dann eine normale Programmperson.
Koennen wir nur zugern "umstellen".
@Creator / Created_By
Auch das koennten wir gern umbenennen in "creator_name" und "creator_id" (finde ich eindeutiger ;-)). Die "ID" ist die "Foren-User-ID". Der Name .. ja ... der Name halt.
beide Werte sollten wir aber "kommasepariert" machen (und dementsprechend real vorhandene "," escapen). Es kann ja vorkommen (siehe therob.xml) dass mehrere Autoren an einem Eintrag arbeiten.
bye
Ron
Offline
Bitte keine Werte mit Kommas getrennt in XML-Tags ablegen, wenn Änderungen geplant sind. Dann lieber eine XML konforme Struktur wählen, z.B.
<person>
<creators>
<creator id="4711" name="Paule">
<creator id="0815" name="Max">
</creators>
</person>oder um zu Personen konform zu bleiben
<person>
<creators>
<creator id="4711">
<nick_name>Paule</nick_name>
</creator>
<creator id="0815">
<nick_name>Max</nick_name>
</creator>
</creators>
</person>Ich persönlich präferiere bei der Definition von Daten immer gleichbleibende Strukturen. Bei mir wäre <creator> nichts anderes als eine Ableitung von <person>, da ein Ersteller zufälligerweise auch eine Person (mit ggf. ID, Vorname, Nachname, Spitzname usw) ist. Dank der Flexibiltität des Formats muss man ja für <creator> nur jene Elemente nutzen/füllen, die auch Sinn ergeben.
Im Ergebnis muss man sich einerseits nur ein Format einprägen und hat es anderseits auch beim Erstellen und Laden derselben dank OO-Programmierung wesentlich einfacher. Spart einiges an IF-Konstrukten. Win-Win-Situation.
Soll aber nicht heißen, dass ihr alles umstellen müsst. Mir ist das letztendlich egal, ich muss am Ende nur wissen, wie die Struktur sein soll. Aktuell - solange die Änderungen nur geplant sind - arbeite ich weiter mit den vorliegenden XML-Dateien. Ich ziehe dann gern jederzeit nach, wenn sich Änderungen ergeben.
Beitrag geändert von Mayo (03.11.2015 20:41)
Offline
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.
Offline
Die ganze "creator"-Sache hat momentan nur zwei potentielle Nutzen:
- bestimmte "Autoren" exkludieren/inkludieren ("nur Daten von user 'test' nutzen")
- im Editor zu filtern
Innerhalb einer MySQL-DB (siehe "REST-Api"-Ziel) ist der creator/author notwendig, damit (nach Authentifizierung) geklaert werden kann, wer welche Eintraege bearbeiten darf (sozusagen die ACL).
Und natuerlich, damit wir wissen, wer wann welchen Eintrag verbockt hat :-)
Dementsprechend gaebe es fuer mich (imho sozusagen) nur die Moeglichkeit einer einzigen ID-Angabe, und eines "Freitextes" fuer den Nutzernamen (bspweise bei Gasteintraegen die vom "Team" eingetragen werden).
Wir brauchen also an der Stelle nix verkomplizieren - derzeit betrifft es nur 2 Eintraege von Gast2/TheRob.
@gleichbleibende Strukturen
Dann koennte man vielerorts auch
<?xml version="1.0" encoding="utf-8"?>
<entry ty="x">
<field ty="bla">value</field>
<field ty="blubb">value</field>
</entry>machen - dann kann alles in hash-arrays/maps gespeichert werden.
Ohne Editor ist aber halt eine gewisse "Sparsamkeit" beim Format vielleicht wichtiger, als ein "wiederkehrendes Element" (was aber dafuer mehrere Zeilen benoetigt).
Soll aber nicht heissen, dass ich dein mitdenken und "abstrahieren" nicht zu schaetzen weiss ... find ich "jut".
Edit:
@Version
Ja sehe ich genauso ... auch wenn das Umstellen von "insignificant" auf "normale person" transparent innerhalb v3 (spielintern) geschehen kann ...
Fuer dich waere die "fruehstens zu unterstuetzende Version" dann die, mit dem ersten Editorrelease, bei dem auch Daten gespeichert wuerden.
Ich denke ja sowieso, dass beim ganzen Integrieren der Effekte/Modifier noch die eine oder andere Umsetzungsfrage aufkommt.
bye
Ron
Offline
Ohne Editor ist aber halt eine gewisse "Sparsamkeit" beim Format vielleicht wichtiger, als ein "wiederkehrendes Element"
Bitte sag mir nicht, dass es jemanden gibt, der tatsächlich die gesamte Struktur eines Eintrags Zeichen für Zeichen abtippt - immer und immer wieder. Da kopiert man sich hoffentlich einen bestehenden Eintrag und ändert nur die Werte ab. Beim Kopieren müsste es unerheblich sein, ob 3 oder 10 Zeilen. Ich muss deswegen ja nicht mehr tippen/tun.
Fuer dich waere die "fruehstens zu unterstuetzende Version" dann die, mit dem ersten Editorrelease, bei dem auch Daten gespeichert wuerden.
Es sind keine Release-Zyklen notwendig. Der Editor ist so konzipiert, dass man ihn sehr früh (quasi schon heute) nutzen kann, statt erst wenn er komplett fertig ist. Er manipuliert nur jene XML-Strukturen die er kennt und lässt von allem anderen die Finger davon. Sprich er lädt die XML in den DOM/Parser, ändert seine Sachen gezielt ab und speichert alles zusammen zurück in die Datei. Das einzige was mit allen Strukturen passiert ist a) beim Laden werden sie auf Korrektheit der XML-Notation geprüft und b) beim Speichern wird die Formatierung wie z.B. Einrückungen (für bessere Lesbarkeit im Texteditor) gleichgezogen. Beides ist sicherlich auch für unbekannte Strukturen wünschenswert.
Ansonsten kann ich hier schon Personen laden, ändern und speichern auch wenn der Bereich <functions> nicht implementiert wurde. Ich habe den Download mal aufgefrischt für jene, die Langeweile verspüren und Lust haben, mal herumzuspielen. Bitte ausschließlich Kopien von XMLs nutzen - da ich selbst nur rudimentär getestet habe.
Beitrag geändert von Mayo (03.11.2015 21:48)
Offline
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?
Offline
<functions> ist wie du richtig erkannt hast eigentlich eine Bitmaske. Die Speicherart stammt - wie erwaehnt - aus V3 (und somit STARSCrazys Feder, allerdings teils mit mir ausgekaspert).
Statt einer Auswahlbox, wuerde ich dort also mit Checkboxen arbeiten - so dass jeder Job "anklickbar" waere.
Generell koennte diese Funktion _eigentlich_ nicht mehr notwendig sein, da sie von bestehenden Filmen automatisch bei "Produktion" des Films ausgefuellt wird. ABER. Falls man wirklich vorgeben moechte, welchen Beruf jemand "erlernt" hat, sollte das ja doch moeglich sein (Eigenproduktion: "Neulinge" haben geringere Einfluesse auf das Ergebnis).
@price_mod
Einfach ein "Multiplikator" fuer Gehaelter. Standard ist also 1.0 (100%) aber er koennte auch nur die Haelfte kosten (0.5) oder das 3fache (3.0) - Schaetze alles zwischen 0 und 10 sollte moeglich sein. Einen weiteren Minimalfilter kann ich vom Programm vorsehen - damit keiner kostenlos arbeitet. Vielleicht 25% ?
@dob/dod
Ich wuerde - im Gegensatz zu einigen Eintraegen in der DB - komplette Daten fuer Geburtstag (und wenn vorhanden Todestag) im Editor abfragen. Also Jahr, Monat, Tag. Die Engine fuellt zwar fehlende Daten "automatisch" auf (1. Januar XXX), dennoch waere es wohl sinnvoll, dass gleich "vollstaendig" auszufuellen.
@Screens
Sieht doch schon ganz schick aus ... und der Basiseingabemodus braucht doch noch paar Daten ;-)
Basiseigenschaften (TProgrammePersonBase):
- Nachname
- Vorname
- Spitzname
- job (Bitmaske)
(- jobsDone - koennte man dazu nutzen, jemand "eher" zum Promi werden zu lassen)
- canLevelUp - bleibt die Person fuer immer "unwichtig"
- countryCode
- gender
- fictional
Irgendwo muessen wir also noch die "bleibt Normalo / canLevelUp"-Checkbox/Auswahlbox unterbringen. Falls "jobsDone" mit rein kommt, dann in einer der "erweiterten" Registerreiter.
bye
Ron
Offline
Modifizierte Tabreiter für Personen:
"Can level up" erstmal neben dem Personentyp (Amateuer, Celeb). Ich vermute die Option bezieht sich auf den Wechsel von Amateur zu einer Berühmtheit? Oder ist CanLevelUp bezogen auf die Attribute einer Person?
Jobs als Liste mit Haken für aktuell ausgeübte und erlernte Berufe. Darunter habe ich mal den "price_mod" als Gehalt von 0-100% gepackt. Darunter habe ich mal einen Textbereich vorgesehen, wo man kurz und knapp erläutert, was für Auswirkungen die Jobs im Spiel bei der Person haben. Ähnlich ist das bei allen Eingabefeldern - dort sollten am Ende hilfreiche Tooltipps hinterlegt werden, damit man für "Can level up" einen kurze Erklärung erhält.
Bei den Datumsangaben würde ich wie im Spiel verfahren - Tag/Monat nicht als Pflichteingabe sehen, sondern bei Bedarf mit 01.01.yyyy ergänzen. Kann der Editor natürlich machen.
Offline
CanLevelUp bezieht sich auf Amateur->Celeb
@Attribute
derzeit gibt es noch "XP", man koennte hier ueberlegen, ob man dem Bearbeiter erlaubt, "Vor-XP" mitzugeben (fuer Celebs). Also Erfahrung ohne eigentlich dahinterstehende Produktionen. Derzeit wird dass nicht nach aussen weitergegeben.
@Jobs
Denke wir brauchen an der Stelle nicht unbedingt spezifische Hinweise. Die erledigten "Jobs" sorgen halt fuer eine Art "Grundkenntnis" des Jobs ... sozusagen "Expertise". Viel mehr ist die Bitmaske aber dafuer gedacht, eine grundliegende Eignung fuer einen Job aussagen zu koennen.
Normalerweise muesste fuer jeden Job eine individuelle Eignung definiert werden, aber ich abstrahiere das alles unter dem Sammelbegriff "XP". Ob jemand als Moderator geeignet ist, ist eher von Dingen wie "Erscheinungsbild" (appearance) und dem "Skill" abhaengig.
Wie du aber bereits sagtest, ist das ja alles recht flink anpassbar, sehe da also kein Problem, dass alles noch auszudiskutieren und abzuaendern.
@derzeitige Editorfassung
Was steht hinter dem Punkt und Gaensefuesschen?
Edit:
Sortierung der Personen nach "Nummer" scheint wohl "string" basiert zu sein (198, 199, 2, ...)
bye
Ron
Offline
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.
Ist auch an eine Auflistung aller Personen gedacht?
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.
Offline
@Job-Attribute:
Wir koennen das gerne "umaendern". Denn wie gesagt, fuellen sich die Job-Flags automatisch mit durchgefuehrten Produktionen.
Was wir also machen koennten ist eine Mischung aus beidem: "Moderator" anklicken und "Aussehen / Charisma" geht automatisch auf 1 (oder bleibt, wenn manuell bereits hoeher gesetzt) _und_ der Flag wird gesetzt.
Warum teilen? Man moechte ja manchmal auch einen Moderator haben, der von den Standards abweicht (appearance = 0 - unscheinbares Maeusschen).
bye
Ron
Offline
