GamezWorld.de - Forum
Von Spielern für Spieler
Du bist nicht angemeldet.
@Mayo
Joop.
Lass Dir die Zeit die Du brauchst. 
Ohne Dich wäre nicht mal ansatzweise Licht am Horizont in Sachen Editor.
@Filter
Ich habe so nach und nach gesehen, was so alles bei Dir schon mit im Plan ist.
Weiß jetzt grad nicht genau, welche Filter nützlich wären...
Ob jede Eigenschaft und jeder Flag gefiltert werden sollte...
Ich kann's Dir ja die Tage mal für die Werbung referieren, wenn's interessiert. Vielleicht ist das ja dann analog für die anderen Daten möglich.
Die Werbung ist insofern komplexer, als da mehrere Werte berechnet werden.
Es wäre schon interessant, wenn ich die gefilterten Werte mit Multiplikatoren versehen könnte.
@Werteveränderung
Bei der Werbung gibt es z.B. die Zuschauerzahl. Die fließt aber nur als Prozentzahl in die Berechnung ein. Die Prozentzahl ist dann wieder die Berechnungsgrundlage für geforderterte Quoten und Prämien.
Das dürfte dann nicht jeweils einzeln veränderbar sein. Wäre aber schön, wenn der Editor selbst die Berechnungen durchführen könnte. Bisher machte das bei mir eine Tabelle und ich habe alles per Hand in die Daten übertragen.
Muss ich Dir wohl mal die Tabelle rüberstellen, um das zu veranschaulichen.
Was aber auf alle Fälle sehr nützlich wäre, würde es einen Filter geben, der beispielsweise nur die Werbung für die Zielgruppe Jugendliche anzeigt und nur bei diesen die Prämien um einen Faktor verändert.
Im Einzelnen würde ich das aber nochmal zusammensuchen.
Kein Ding (bin hier ja auch familaer und arbeitstechnisch eingespannt - hab so ca -4h pro Woche Zeit :-)).
Hoffe es geht beim Editor mit der gleichen Geschwindigkeit wie zum Start voran - denn dann sollte es ja nicht mehr viele Wochen dauern bis ein "einfacher Einsatz" moeglich ist.
Falls es dir moeglich ist, sollte mit Gast2 abgesprochen werden, ob "Alle Eintraege bearbeiten"-Funktionen ihren Weg reinfinden koennen.
Genauer: Alle Werte X aller News mit 1.2 multiplizieren - oder aehnliches, so dass ein "rundum"-Balancing weniger Handarbeit ist. Was genau wir braeuchten, weiss er wohl besser. Aber am Ende waere ein solcher "Batch-Anpasser" wohl pro Aehnlich aufzubauen:
[Eigenschaft/Feld-Dropdown] [Rechenart-Dropdown] [Wert/Eingabe] [OK]
Eigenschaft/Feld-Dropdown
-> Auswahl der Zahlenfelder (i.e.S. auch die Genre - damit liesse sich ein +1 fuer alle integrieren ;-)). Beispiel: Topicality, price_mod, ...
Rechenart
-> +, -, *, /
Man koennte noch ueberlegen, ob es einen Simplen "UND"-Filter gibt (aehnlich der Thunderbird-Filter). So dass man einstellen kann "Genre </>/= X".
Ist aber eigentlich nur notwendig, wenn spezifische Aenderungen fuer viele Sachen durchgefuehrt werden muessen - denke auch da kann Gast2 mehr zu sagen.
Das obige ist aber alles "Zucker", und mehr als "Extra/Bonus" zu sehen. Vorrang hat, dass dir das Entwickeln mehr Spass als "Druck" macht.
bye
Ron
Lebenszeichen! Entschuldigt die Wartezeit. Bin nun wieder im Lande und mache am Editor weiter - die Projektarbeiten haben mich länger aufgehalten als geplant 
@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
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.
Erstmal vorweg:
Sieht fein aus, wie das wächst.
Danke.
Frage:
Ist auch an eine Auflistung aller Personen gedacht?
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
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.
<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
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?
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.
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
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.
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.
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