[Blog] Binary-Tools 2.0 Entwicklung

  • Guten Nachmittag,


    ein paar vereinzelte Leute wissen, dass wir im Moment dabei sind, unsere Toolseite Binary-Tools etwas aufzupäppeln, aka komplett neu schreiben. Da mir beim Programmieren manchmal etwas öde wird, und ich mir nicht vorstellen kann, dass alleine in meinem meist dunklen Kämmerchen vor mich hinzucoden die beste Variante ist, um eine Toolseite zu schreiben, habe ich mich dazu entschieden, eine Art Entwicklerblog zu schreiben. Hier.

    Bitte hier keine Antworten posten, sonst wird das etwas unübersichtlich.

    Eure Antworten, Kommentare, and so on, könnt ihr gerne hier posten: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog


    Eine Warnung vorweg: Ich programmiere nicht regelmäßig an Binary-Tools. Jenachdem, wie ich Zeit und Lust habe. Es kann gut passieren, dass ich hier wochenlang nichts schreibe. Das heißt dann nicht, dass ich die Entwicklung eingestellt habe, sondern, dass ich im Moment keine Lust oder Zeit dafür habe.


    Einige Screenshots, die ich hier im Verlauf des Threads eventuell poste, sind übrigens eher nie finale Versionen. Nicht wundern, wenn ab und zu ein Platzhalter ins Bild rutscht und alles hin und wieder "etwas" unfertig aussieht. Ist ja ein Blog, keine Toolvorstellung.


    FAQ:


    Q: Kann man im Moment sehen und nutzen, was aktuell vorhanden ist, so eine Art Open Alpha?

    A: Nein, nur ggf. ein paar Screenshots. Vielleicht irgendwann später.


    Q: Warum macht ihr alles von neu? o.O

    A: Kurzfassung: Das aktuelle BT ist über 6 Jahre alt und enthält Codezeilen, die ich geschrieben habe, als ich gerade gelernt habe, was ein Array und ein Objekt ist. Auf gut Deutsch, inperformanter Spaghetticode ohne Ende. War anfangs auch nie als öffentliche Toolseite geplant. Ich hab großteils keinen Plan, wo ich was ändern müsste, um zu bewirken was ich will, ohne alles kaputt zu machen.

    Außerdem: PHP 5.x, MySQL 5.5 - habe ich beides nicht mehr auf meinem Rechner.


    Q: Quellcodeverwaltung?

    A: Jep.


    Q: Wer ist wir?

    A: Unity und ich. Ich habe zwar das meiste inhaltliche an Binary-Tools gemacht, aber er das meiste äußerliche (Layout & Design). Außerdem kommen ein paar Tools von ihm (Karte und Dorfplaner, z.B.). Der Name sagt euch nix, er spielt ewig nicht mehr, und hat nie wirklich aktiv gespielt. Ist einfach ein Kindheitsfreund von mir.


    Q: Wann ist es fertig?

    A: Keine Ahnung. Wirklich nicht. Wahrscheinlich 2020 oder so. Ich weiß auch noch nicht, ob wir alle Tools neu schreiben, manche sind echt unnütz. Aktuell stehen 28 Tools auf meiner Todo, vier davon nahe an final, zwei InDev, 22 nicht mal angefangen. Und die Tools sind ja nicht das einzige, das anfällt.


    Nochmal:

    Bitte hier keine Antworten posten, sonst wird das etwas unübersichtlich.

    Eure Antworten, Kommentare, and so on, könnt ihr gerne hier posten: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog


    mfg,

    Be2-e4

  • Guten Nachmittag,


    erst einmal ein kurzes Resumée, was wir mittlerweile fertiggestellt haben. Wir arbeiten da schon seit 27. Mai dran, ein bisschen was ist da schon zustande gekommen.


    Für die etwas Bewanderteren: Wir nutzen Spectre.css & TypeScript. Ok, theoretisch haben wir TypeScript Support, ich habe bis jetzt noch alles in pure JS geschrieben, sonst machen wir alles selbst. Hat keine wirklichen Gründe, ich hab einfach nur Spaß daran. Und das ist immerhin mit das wichtigste, oder?


    Bisherige, grundsätzliche (nicht-codeinterne) Unterschiede zur alten Version sind:

    1) BT2.0 hat die Möglichkeit, auch Tools für andere Spiele als die Travianserie zu hosten.

    2) BT2.0 unterstützt Mehrsprachigkeit, d.h. die Toolseite wird es bei Release auf englisch & deutsch geben, wenn sich Übersetzer aus anderssprachigen Communities finden, auch in anderen Sprachen.

    3) BT2.0 hat eine bessere Integration von Anleitungen für die Tools und ich habe mir fest vorgenommen, für jedes Tool eine zu schreiben.

    4) Die Tools sollten einheitlicher aussehen.


    Aktuell haben wir 6 Tools, von denen vier schon gut nutzbar sind. Zwei davon stelle ich heute kurz vor, die anderen beiden im nächsten Post, die letzten beiden im übernächsten und dann geht es mit den eigentlichen aktuellen Blogs los.


    Ausbildungsrechner

    Detaillierte Anleitung bereits verfügbar.

    Eine verbesserte Version des alten Ausbildungsrechners von Binary-Tools. Grundsätzlich tut er noch das gleiche und berechnet die Anzahl der Truppen, die man in einer bestimmten Zeit ausbilden kann. Es gibt allerdings ein paar Änderungen:

    - Das neue Design ist ... kleiner. Und wie ich finde deutlich übersichtlicher. Und nutzt nicht mehr die alten T3(.6) Grafiken.

    - Die neue Version kann auch Späheroffs berechnen, statt nur Off & Deff.

    - Man kann die Schmiedestufe jetzt genau einstellen, statt nur 0 oder 20.

    - Es gibt einige Statistiken mehr, die angezeigt werden: Ressourcen, Offkraft, Deffkraft und Kornverbrauch jeweils insgesamt, pro Stunde, pro Tag, pro Ressource und pro Kornverbrauch.

    - Anstatt der Zeitspanne lässt sich auch die Truppenmenge eingeben - es wird dann berechnet, wie lange es dauert, diese auszubilden.

    - Man kann mehrere Intervalle mit unterschiedlichen Konfigurationen zusammen addieren. Wenn ihr zum Beispiel an Tag 50 wissen wollt, wie groß eure WW Off noch wird, könnt ihr einfach zwei Intervalle nutzen: Eins für die 30 Tage bis die Tier 3 Items erscheinen und eins für danach (um den Anstieg des Helmbonus korrekt miteinzuberechnen). Als Nebeneffekt lassen sich damit auch zwei Offs desselben Volkes ziemlich übersichtlich miteinander vergleichen.


    Screenshots:


    Ressourcenausbaurechner

    Detaillierte Anleitung bereits verfügbar.

    Eine verallgemeinerte und verbesserte Version des Getreideausbaurechners von Binary-Tools. Wie in der alten Version berechnet es die optimale Reihenfolge, in der man die Infrastruktur eines (Haupt-)Dorfes ausbaut, also, wann man Veredler und Botschaft baut. Der Unterschied ist, dass man jetzt auch für Nicht-15er-HDs brauchbare Ergebnisse bekommt (9er, 7er und 6er HDs haben schließlich signifikante HLE Felder, die im alten Tool nicht berücksichtigt worden sind).

    Wesentliche Neuerungen:

    - Design überarbeitet

    - Berücksichtigt nun Holz-, Lehm- und Eisenfelder

    - Hat sowohl schön kompakte Ansicht der Baureihenfolge als auch detaillierte Ansicht mit jedem Schritt

    - Man kann HLE Veredler deaktivieren, dann werden sie nicht in die Berechnung einbezogen


    Screenshots:


    mfg,

    Be2-e4

  • Guten Nachmittag,


    die beiden nächsten Tools in der Sammlung sind der Katapultrechner und Special Achievements.


    Vorher noch ein kurzes "Übrigens": Alle Tools haben im Moment nur Travian Kingdoms Support. Das werde ich bis zur finalen Version aber natürlich noch anpassen und das sollte auch nicht allzu lange dauern. Ich plane T:L Support bei der Programmierung der Tools mit ein: Truppen- und Gebäudestatistiken werden zentral an einer Stelle geladen, Formeln in eine zentrale Formelsammlung ausgelagert und die Icons zentral über eine scss Datei eingebunden. Das bedeutet, dass ich im Optimalfall nur diese drei zentralen Stellen abhängig von der aktuell ausgewählten Spielwelt machen muss, damit alle Tools automatisch bei Bedarf an T:L angepasst sind.

    Support für Ägypter und Hunnen bei Truppenberechnungen ist ein minimal anderes Thema - an einigen Stellen (z.B. Ausbildungsrechner) war ich bisher etwas faul und habe die Völkerauswahl hardcodiert in den Templates stehen. Aber das anzupassen wird auch nur eine Sache von einer halben Stunde für alle Tools oder so - denn sobald die Völker ausgewählt sind, werden die Truppendaten über die zentrale Stelle geladen und stehen damit zur Verfügung.

    Lediglich Support für die Midgame Artefakte aus T:L ist ein etwas aufwändigeres Thema - aber sollte auch nicht allzu viel Zeit in Anspruch nehmen.


    Katapultrechner

    Anleitung ist im Moment noch Todo

    Auch der Katapultrechner ist eine verbesserte Version der BT1.8 Version davon. Bei dem Layout bin ich mir noch nicht sicher, ob ich es so lasse. Ich finde es nicht unbedingt super übersichtlich ... aber bislang ist mir keine wirklich brilliante Idee gekommen, wie ich das besser lösen könnte, also bleibt es erstmal so. Wenn ihr eine habt, hier ist nochmal der Feedbackthread verlinkt: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

    Die wesentlichen Änderungen sind:

    - Die neue Version zeigt die Details zur Berechnung an. Das bedeutet erstens, welche Komponente wie viel ausmacht und zweitens, die Formeln für die einzelnen Komponenten. Diese Änderung habe ich eingeführt in der Hoffnung, dass die Wichtigkeit erkannt wird, die Einwohner korrekt einzugeben. Und natürlich einfach so, als Information, weil der Platz noch frei war.

    - Der alte Katapultrechner hatte eine Tabelle, die im Grunde anzeigt "jo, für Gebäudestufe 20 brauchst du 53 Katapulte, das bräuchtest du an Katapulten, wenn die Gebäudestufe nicht 20 ist: (Tabelle)". Der neue Katapultrechner hat eine ähnliche Tabelle, allerdings in erweiterter Form: Die neue Tabelle zeigt nicht nur an, wie es für andere Gebäudestufen aussähe, sondern auch, wie es für andere Katapultlevel aussähe (bei derselben Konfiguration, d.h. unter Berücksichtigung der Moral und des Steinmetzes). Die eigentliche Zeile und Spalte ist wie in der alten Version farblich hervorgehoben. Ziel dieser Änderung ist, dass den Schmiedefaulen die Wichtigkeit der Truppenupgrades bewusst wird, und dass man sich überlegen kann, ob es sich lohnt noch fix ein paar Kattalevel zu golden.


    Die alte Funktion, dass man eingeben kann, wie viele Katapulte man hat, und rausbekommt, auf welcher Stufe das Gebäude anschließend ist, gibt es natürlich immernoch.


    Und wie gesagt: Im Moment nur TK Support - Baumeisterartefakt ist derzeit also noch nicht verfügbar.


    Screenshots:



    Special Achievements

    Angeregt von zwei Threads im englischsprachigen Forum, habe ich ein "Tool" geschrieben, das kurz und übersichtlich alle Special Achievements anzeigt und kurz erklärt, wie man sie bekommt. Wer nicht weiß, was Special Achievements sind - es gibt versteckte Achievements, deren Fortschritt man nicht sieht, die man für manche Aktionen bekommt. Sie haben großteils eher Easter Eggs Charakter, als dass sie einen wirklichen Erfolg darstellen und sind einfach nur just for fun im Spiel.


    Achtung: Die Screenshots von dem Tool zeigen alle derzeit verfügbaren Special Achievements und wie man sie bekommt. Wer das nicht gespoilert bekommen möchte, schaut sich die Screenshots bitte nicht an. Das Tool verfügt übrigens ebenfalls über eine Spoilerwarnung.


    Screenshots:


    mfg,

    Be2-e4

  • Guten Nachmittag,


    die letzten beiden Tools, die zumindest angefangen wurden, sind ein Timer/FL Timer und ein Adelungsrechner.


    Timer & Farmlistentimer

    Ich habe irgendwann mal angefangen, einen eigenen Timer zu bauen für Farmlisten. Das hat einen ziemlich speziellen Grund: Ich hatte vorher einen akustischen Onlinetimer genutzt und mich wirklich alle fünf Minuten erschrocken, als das blöde Ding gefiept hat, weil es so laut war. Und trotz der Lautstärke habe ich es manchmal einfach überhört, wenn ich Serie geguckt habe oder etwas gespielt habe. Und naja, wenn man drei Sekunden Headset ablegt ist auch Schluss mit dem Ton. Also wollte ich weg von akustischen Signalen und habe einen Timer gebaut, der blinkt, anstatt zu klingeln - und das Timerfenster dann so positioniert, dass ich mit der Maus drüber fahren muss, wenn ich die Farmlisten abschicken will (vielleicht zur Erläuterung: Um Farmlisten zu schicken mach ich mir kleine 150 x 150 Pixel Browserfenster auf, in denen man quasi nur den Abschicken Button sieht und pack die Fenster auf einen Bildschirm, den ich selten ganz brauche, weil da auch mein Skype und TS ist - d.h. da ist eh bisschen Platz frei) und resette den Timer wenn man mit der Maus drüber fährt - perfekt für mich.


    Ein ähnliches Konzept hat dieses Tool.


    Man kann wählen zwischen einmaligen Timern und Farmlistentimern. Letztere starten automatisch neu, sobald sie abgelaufen sind, erstere nicht. Und der Plural ist durchaus bewusst: Man kann unbegrenzt viele Timer auf einmal aktiv haben, z.B. einmal für 10 Minuten Farmlistentakt für Liste A, B und C und einmal für 20 Minuten Takt für Liste D und E - so ähnlich haben wir in der letzten de4 gefarmt. Nebenbei gehen natürlich auch noch andere Timer, z.B. eine Erinnerung, dass man in 25 Minuten einen Stammi abschicken muss.

    Außerdem kann man auswählen, ob der Timer blinken, klingeln, beides oder gar nichts soll, sobald er abgelaufen ist. Das akustische Klingeln muss ich allerdings noch implementieren. Wie gesagt, DevBlog, keine Toolvorstellung. :p


    Im Moment sieht das Tool so aus:


    Sieht man im Screenshot zwar nicht, aber als Startzeit Eingabeformat kann man hh:mm:ss, mm:ss oder einfach die Sekundenanzahl benutzen. Statt 3000 ginge also auch 50:00 oder 0:50:00.

    Im Moment wird die aktuelle Konfiguration wie sie ist im LocalStorage gespeichert, sobald man einen Timer hinzufügt oder löscht (und natürlich neu geladen, sobald man F5 drückt oder so). Die Timer laufen im Hintergrund allerdings nicht weiter.

    Wenn ein Timer abläuft und blinken aktiviert ist, blinkt seine Zeile. Fährt man mit der Maus über die Zeile, endet das Blinken.


    Geplant ist noch:

    - Eine Möglichkeit, Kommentare zu den Timern zu schreiben

    - Eine Möglichkeit, die Timer mit dem Server zu synchronisieren (damit man die aktuelle Konfiguration auf allen Geräten hat, sofern man eingeloggt ist)

    - Timer im Hintergrund weiterlaufen lassen

    - Konfiguration als Link exportieren, um sie teilen zu können

    - Konfiguration speichern/laden mittels Buttons machen, anstatt automatisch



    Adelungsrechner

    Hm. Bei diesem Tool zu sagen, dass es eine Verbesserung des alten Tools ist, wäre nicht ganz zutreffend.

    Der alte Adelungsrechner hat ausgespuckt, mit welcher Stammikombination man als einzelner Account ein Dorf seines Gegners im Idealfall adelt, ohne sich selbst zu überadeln.

    Der neue Adelungsrechner fasst drei Tools (zwei neue + den alten Adelungsrechner) in einem Tool zusammen. Die drei "Untertools" sind dann über Tabs auswählbar (so ähnlich wie Abfang-/Speed-/Wegerechner im alten BT1.8). Eines davon ist fertig, bei dem zweiten bin ich gerade dabei und das dritte noch nicht angefangen.


    Erstens, der Adeligenvergleich.

    Der Adeligenvergleich ist eine einfach gehaltene Tabelle, mit der man die Adeligen der drei (fünf) Völker simpel vergleichen kann. Man kann alle relevanten Daten angeben: Große Feste auf beiden Seiten, Brauereifest beim Angreifer und die Einwohner von Angreifer und Verteidiger. Anschließend sieht man in einer übersichtlichen Tabelle, wie viel Zustimmung die Stammesführer der jeweiligen Völker mindestens, höchstens und im Durchschnitt senken.


    Screenshot:


    Zweitens, die Adelwahrscheinlichkeit.

    Hier wird man einen Verteidiger und beliebig viele Angreifer angeben können. Das Tool berechnet dann (von oben nach unten), wie hoch die Wahrscheinlichkeit ist, das Dorf oder die Stadt in diesem Angriff zu adeln. Anwendungsgebiet soll sein, dass man abschätzen kann, ob die Stammis reichen und wie hoch die Gefahr auf einen Selbstüberadel ist. Eventuell auch, um zu entscheiden, ob man es sich leisten kann, wenn der Cleaner mit Brauerei läuft, ob wirklich alle Stammis aus allen NDs ein großes Fest brauchen, and so on. Man könnte sagen, man soll mit diesem Tool abschätzen können, ob eine Adelung gut geplant ist oder ggf. die Planung verbessern können.


    Dieser Tab ist wie gesagt im Moment InDev und noch nicht fertig.


    Im Moment sieht es so aus:


    Geplant sind noch:

    - Möglichkeit zwei Angreifer zu vertauschen, bspw. um versehentliche Selbstüberadelungen zu vermeiden

    - Anzeige der minimal und maximal notwendigen Angriffe in dieser Konstellation um das Dorf sicher zu adeln, z.B. für die Planung von Nacht und Nebel Aktionen, bei denen man wegen kurzer Laufzeiten mehrmals laufen könnte

    - Eventuell ersetze ich das Dropdown für die Völker noch durch klickbare Völkericons, so wie im Ausbildungsrechner:


    Falls es jemanden interessiert, wie die Wahrscheinlichkeit für den Adel berechnet wird, sei dies kurz erläutert.

    Die Adelmechaniken habe ich von T:L übernommen, ich habe leider bisher noch keine Möglichkeit gehabt, die für TK zu verifizieren - ich gehe aber nicht davon aus, dass da groß Änderungen durchgeführt wurden.


    Grundsätzlich funktioniert das adeln so:

    1. Je nach Volk wird eine Zufallszahl zwischen 20 und 25 (Gallier, Germane) oder 20 und 30 (Römer) generiert.

    2. Bonus/Malus für großes Fest wird addiert/subtrahiert: +5 für Angreifer gF, -5 für Verteidiger gF

    3. Die Zahl wird mit der Anzahl der Stammis in dem Angriff multipliziert.

    4. Das Ergebnis wird mit dem Moralmalus verrechnet: (Verteidiger EW / Angreifer EW)^0,2, Werte unter 0,667 und über 1,000 werden auf die jeweilige Grenze gesetzt.

    5. Das wird dann bei aktivem Brauereifest des Angreifes noch durch zwei geteilt.

    6. Zum Schluss wird das Ganze noch gerundet.

    Heraus kommt die gesenkte Zustimmung.


    Um die Wahrscheinlichkeit auszurechnen, berechnen wir für jede denkbare Gesamtzustimmungssenkung die Anzahl der Kombinationen, die sie ergeben. Die Summe der Kombinationen, die mindestens 100 (bzw. so viel, wie man konfiguriert) abziehen geteilt durch die Summe aller Kombinationen ist dann die gesuchte Wahrscheinlichkeit. Und die Anzahl der Kombinationen zu berechnen ist relativ einfach mit dem folgenden Algorithmus:


    - Rest folgt im Folgepost, 10.000 Zeichenlimit überschritten -

  • Achtung - mathematischer Teil. Wer das überspringen möchte kann gefahrlos nach dem Spoiler weiterlesen. Wenn es euch interessiert, freut es mich aber, wenn ihr es lest:


    Drittens, Adelplaner.

    Das entspricht im Grunde dem ursprünglichen Adelrechner aus BT1.8. Man gibt Einwohner, Volk, Feste beider Spieler und Anzahl der verfügbaren 3er Stammis ein und bekommt eine Stammireihenfolge zurück, die das Dorf sicher adelt und dabei das Selbstüberadeln minimiert - sofern eben möglich. Keine Screenshots, weil noch nicht angefangen. Das ist wahrscheinlich Gegenstand der nächsten Posts, zusammen mit dem Rest vom zweiten Tab, weil ich da gerade dabei bin, es zu programmieren. :p



    Übrigens: Erwartet bitte nicht, dass der Blog täglich neue Einträge bekommt. So viel habe ich dann auch wieder nicht zu berichten über die Entwicklung. Ist jetzt nur die ersten Tage, weil da eben schon sieben Monate Entwicklung drin stecken. Außerdem wird nicht jeder Post neue Tools beinhalten. Manche (einige) Posts werden sich auch mit etwas langweiligeren Themen befassen, manche (viele) Tools werden mehr als nur einen Post bekommen, weil die Entwicklung eben manchmal etwas dauert, und die Posts werden wahrscheinlich grundsätzlich etwas kürzer. Im nächsten Post wird es wahrscheinlich um den letzten Tab im Adelungsrechner gehen und noch um Kleinigkeiten im zweiten. ^^


    mfg,

    Be2-e4

  • Guten Abend,


    die letzten paar Tage habe ich an dem Adelungsrechner weitergeschraubt und eine Kleinigkeit im Ressourcenausbaurechner verbessert. Weil es wirklich eine Kleinigkeit ist, die zuerst: Die Berechnungen unterstützen jetzt die Angabe der Serverspeed. Eine UI dafür gibt es zwar nicht, wird es aber auch nicht geben - die Serverspeed wird durch die ausgewählte Welt definiert. Also, sobald es implementiert ist, die Spielweltauswahl ist zurzeit nur Dekoration.


    Am Adelungsrechner gibt es auch noch nicht viel neues zu sehen, dafür etwas neues Gedankengut. Zu sehen sind zwei Knöpfe, die die Angriffe im Wahrscheinlichkeitenrechner hoch und runter verschieben können:

    Ich hoffe inständig, dass ich noch eine schönere Position dafür finde, als dort, wo sie gerade sind.


    Dafür habe ich mir ein paar Gedanken gemacht, wie ich die Stammireihenfolge berechnen möchte und wie genau man die Eingaben spezifizeren können soll. Das grundsätzliche Problem ist, dass der triviale Ansatz, um die beste Reihenfolge zu finden exponentiell mit der Anzahl der möglichen Stammidörfer ansteigt. Das heißt, ein trivialer Ansatz ist unbrauchbar.


    Eine Möglichkeit wäre zu berechnen, wie viele Stammis man maximal schicken darf, damit das Dorf garantiert nicht geadelt wird. Das funktioniert relativ gut und wird vom alten Adelungsrechner so umgesetzt:

    1) Ermittle wie viele Stammis maximal geschickt werden können, um das Dorf garantiert nicht zu adeln

    2) Ermittle, wie viele davon großes Fest feiern dürfen, ohne dass das Dorf geadelt werden kann

    Dadurch erhält man z.B. so etwas wie "5 Stammis, davon 2 mit großem Fest, die senken minimal 75 und maximal 99 Zustimmung" (zufällige Beispielzahlen) und weiß dadurch, dass man um das Dorf jetzt sicher zu adeln mindestens 25 Zustimmung senken muss - und kann dafür die minimal notwendige Stammizahl mit Festen ermitteln. Die optimale Reihenfolge der letzten Stammis ist trivial: 1er zuerst, dann 2er, dann 3er und in der jeweiligen Gruppe zuerst ohne Fest und dann mit Fest.

    Bei dieser Methode gibt es allerdings ein fieses Problem namens Rundungsfehler. 2 Stammis senken nicht notwendigerweise genau doppelt so viel wie einer. Einer könnte 17-21 Prozent senken, zwei dafür 33-43 Prozent - zum Beispiel wenn es eigentlich keine 17-21, sondern 16,5-21,4 Prozent sind, die bei einem Stammi gerundet werden, bei zwei Stammis aber erst nach dem Verdoppeln gerundet werden.

    Dadurch wird die Aussage "man bräuchte zuerst 5 Stammis mit 2 großen Festen und dann einen 2er mit gr. Fest" recht schwammig: 5 Stammis können 5x 1, 2 + 3x 1, 2x 2 + 1, 3 + 2x 1 oder 3 + 2 sein. Alle mit potentiell anderen Ergebnissen und Wahrscheinlichkeiten.


    Ein Beispiel für einen solchen Fall wäre ein 1.000 EW Römer, der ein 590 EW Opfer adeln möchte, das 125% Zustimmung hat: Die Berechnung würde ergeben, dass er 4 Stammis mit gr. Fest schicken muss um die Zustimmung zu senken und anschließend einen 2er mit großen Fest zum Adeln schicken muss. 4x 1 Stammi gefolgt von einem 2er würde auch perfekt funktionieren. Schickt er aber einen 1er, einen 3er und einen 2er, so besteht die Chance, dass der zweite Angriff schon adelt - wegen Rundungen (die Chance ist übrigens 1,65%):


    Nach etwas darüber nachdenken, habe ich mich aber dazu entschlossen, den Algorithmus obwohl er nicht exakt ist so zu benutzen. Der Grund dafür (außer dass der Fehler minimal und selten ist) ist derselbe, aus dem ich entschieden habe, dass man nur einen Angreifer konfigurieren kann (anstatt mehrere) - das Problem eine Stammikombination zu finden, die die Zustimmung so weit es geht senkt, ohne das Dorf zu adeln, ist eine Variante des Rucksackproblems, genauer gesagt des Teilsummenproblems - beide sind nicht in Polynomialzeit exakt lösbar.


    Der Spezialfall eines Angreifers mit der vereinfachten Annahme, dass es keine Rundungsfehler geben könnte ist eine Vereinfachung des Rucksackproblems auf nur ein mögliches Item in unbegrenzter Anzahl - und das bricht das Problem auf ein paar simple Grundrechenaufgaben runter. Das ist eine Vereinfachung, die ich für Berücksichtigung von Rundungsproblemen nicht finden konnte und die für eine Einbeziehung anderer Moralmali nicht existiert.


    Eventuell teste ich irgendwann ein paar Annäherungsversuche oder probiere aus, wie gut und schnell es mit dem Rucksackproblemsalgorithmus in Pseudopolynomialzeit funktioniert, aber vorerst belasse ich es dabei. Andere Bereiche wollen auch meine Aufmerksamkeit und ganz ehrlich - die paar Prozent in den wenigen Fällen in einem Tooltab, der vermutlich eh nicht der meistgenutzteste sein wird, sind den Aufwand nicht wert. ^^


    Die Implementierung und hoffentlich das User Interface folgen im nächsten Post. Apropos - ich habe vorhin festgestellt, dass noch ein Angriff löschen Button fehlt. :D


    mfg,

    Be2-e4

  • Guten Abend,


    eine Kleinigkeit habe ich nun doch noch an dem Algorithmus (siehe oben) optimiert:


    Die Adelung wird in zwei Abschnitte geteilt:

    1) Zustimmung senken, ohne dass geadelt wird

    2) Eigentliches Adeln

    Wie oben wird also zuerst eine Stammireihenfolge berechnet, die die Zustimmung soweit wie möglich senkt, ohne zu adeln und anschließend geadelt.


    Anstatt mich mit den Rundungsfehlern von letztens zu ärgern, fügt der Algorithmus jetzt 3er Stammis hinzu, bis kein weiterer 3er Stammi mehr passt (ohne Gefahr auf Adel). Anschließend 2er und dann 1er Stammis. Damit sind für den Moment Rundungsfehler ausgeschlossen, weil die maximale Senkung jedesmal exakt für diese Stammizahl berechnet wird und vorher keine Rundungen passieren. Nachdem die Stammis eingeplant wurden, wird die Planungsliste durchgegangen und geprüft, ob jeweils ein großes Fest aktiviert werden kann, ohne Gefahr auf Adel. Das geschieht auch noch Rundungsfehlerfrei.

    Zuletzt wird geprüft, ob ein 3er oder 2er in 1er + 2er aufgebrochen werden kann um nur 1 (bzw. 2) große(s) Fest(e) zu feiern. Dabei können sich eventuell Rundungsfehler einschleichen - diese sollten aber Auftretwahrscheinlichkeiten von < 1% haben und damit ziemlich insignifikant sein.


    Nun haben wir eine Menge von Stammis, die x bis y Zustimmung senken, wobei y < Startzustimmung. Nun müssen wir noch mindestens (Startzustimmung - x) Zustimmung senken, um das Dorf sicher zu adeln. Dafür gehen wir ähnlich vor: Es werden solange Stammis hinzugefügt, bis das Dorf sicher geadelt werden kann, indem nur noch große Feste aktiviert werden. Dabei werden solange 3er hinzugefügt, bis ein 2er reicht. Dann entweder ein 2er oder ein 1er hinzugefügt und zuletzt noch große Feste gefeiert, dabei werden 3er zuerst mit gF versehen, dann 2er, dann 1er. Anschließend werden die Stammis in ihrer Reihenfolge optimiert, nämlich 1er -> 1er gF -> 2er -> 2er gF -> 3er -> 3er gF, damit die Chance sich selbst zu überadeln minimal bleibt. (Nur die Stammis des zweiten Schritts werden sortiert).


    Anschließend ist das Ergebnis fertig.


    Beispiel:

    Ich will ein (fiktives) Dorf mit 300 Zustimmung adeln, 2.000 Einwohner vs. 1.000 Einwohner, als Römer, ohne Brauerei.

    1. 3x 3er hinzufügen - ein weiterer 3er würde nun eine Adelung riskieren

    2. 2er hinzufügen - mehr Stammis würden eine Adelung riskieren

    3. Einen 3er mit gF laufen lassen - mehr gF würden eine Adelung riskieren

    4. Zum Adeln werden nun zwei 3er eingeplant, einer mit gF

    Das Resultat ist also: 3er gF -> 3er -> 3er -> 2er -> 3er -> 3er gF


    Der Algorithmus sollte Rundungsprobleme bis zur Insignifikanz minimieren (wird sie aber wahrscheinlich nicht komplett beheben).


    Ich plane übrigens, nach der Berechnung das Resultat einfach in den Adelwahrscheinlichkeitentab zu übertragen, damit man direkt die Wahrscheinlichkeitsberechnung sehen kann (und somit auch validieren kann, ob der Vorschlag passt oder selbst daran feilen).


    Ein User Interface gibt es auch schon, allerdings ist es noch nicht funktionsfähig und tut einfach nichts. Außerdem fehlt der Berechnen Button:



    ToDos:

    - Limitierte 3er in den Algorithmus einbauen

    - UI beleben



    Außerdem habe ich ein paar Kleinigkeiten im Wahrscheinlichkeitentab geändert:

    • Die hoch/runter Buttons sind nun links von der Volkauswahl, dafür die EW Spalte zweizeilig
    • Das Dropdownmenü für die Völkerwahl habe ich wie im Ausbildungsrechner durch die Stammiicons ersetzt, außerdem bei den Icons deutlicher gemacht, welcher aktiv ist (betrifft auch den Ausbildungsrechner)
    • Die Reihenfolge der Angriffe kann jetzt auch - auf Vorschlag von iTob - mittels Drag & Drop verschoben werden, dafür hab ich aber keine klare UI. Der Cursor wird zu einem Verschieben-Cursor, wenn man in die Nähe der Pfeiltasten kommt. Ich hoffe das + Anleitung (ToDo) sind genug Hinweise auf dieses Feature. Draggen kann man übrigens an der ganzen Zeile.

    ToDos:

    • Löschenfunktion für eine Zeile - wird wahrscheinlich zwischen die Pfeile kommen

    Screen"shot" (ist ein GIF wegen Drag & Drop Funktion):



    mfg,

    Be2-e4

  • Guten Nachmittag,


    nachdem ich gerade etwas nebenbei auf einer T:L Welt klicke, habe ich angefangen, T:L Support jetzt schon zu implementieren, damit ich die Tools direkt nutzen kann.

    Implementiert habe ich bisher Truppenicons für T:L. Diese werden automatisch für alle Tools abhängig vom ausgewählten Server genutzt - TK Icons bei einem TK Server und T:L Icons bei einem T:L Server. Dieses Prinzip werde ich auch für Gebäudeicons übernehmen, für andere Icons (wie z.B. das "+" Zeichen im Ausbildungsrechner, oder das Angriffsschwert, Verteidigungsschild und Spähfernglas) behalte ich TK Icons bei. Einerseits habe ich keine Lust die T:L Icons zusammenzusuchen, andererseits finde ich die TK Icons einfach hübscher. Damit sind jetzt übrigens auch Icons für Ägypter und Hunnen vorhanden.


    Außerdem habe ich mittlerweile die Truppendaten für T:L hinterlegt, sodass der Ausbildungsrechner jetzt auch für die beiden neuen Völker und T:L allgemein genutzt werden kann. Ich musste lediglich die Völkerauswahl anpassen. Ägypter und Hunnen sind in TK natürlich nicht auswählbar.


    Hauptsächlich betroffen von den Änderungen ist der Ausbildungsrechner:


    Aber auch der Adelungsrechner hat die T:L Icons (so wie alle anderen Tools, die Truppenicons nutzen werden - ganz automatisch):



    Der Adelungsrechner funktioniert übrigens auch direkt mit den beiden neuen T:L Völkern. :)


    Intern habe ich ein paar Dateien und Ordner verschoben:

    • Ich habe ein paar CSS Dateien von Travian aus dem Browser kopiert um es mit mit den Truppenicons für TK leichter zu machen und einige "Rohdaten" von irgendwelchen Datentabellen (z.B. Truppen TSV Dateien). Die haben im Tool keine Verwendung, wurden aber von mir genutzt, um die eigentlich genutzten Dateien zu erstellen. Den Ordner habe ich vom Hauptverzeichnis in das dbg Verzeichnis geschoben. Das dbg Verzeichnis wird nicht hochgeladen bei Release, d.h. die Dateien sind nur in der Quellcodeverwaltung und nicht live.
    • Ich habe die (bisherigen) versionsspezifischen Icons in einen extra Ordner gelegt, namentlich die Icons für Truppen und Achievements, damit da etwas mehr Ordnung herrscht.

    mfg,

    Be2-e4

  • Guten Morgen,


    über das Wochenende habe ich eigentlich nicht viel gemacht, muss ich gestehen. Dafür eine Sache, die mal dringend nötig war. Vorwarnung: Technischer Hintergrund, aber ich habe mich bemüht es laienfreundlich zu schreiben.


    Wir nutzen in Binary-Tools für alle Tool UIs eine von mir geschriebene JavaScript UI. Basically ist das eine JS "Klasse", die eine Tabelle darstellt. Muss halt nicht zwingend eine HTML Tabelle sein, wir können auch HTML Code als Template hinterlegen, der dann als eine "Zeile" interpretiert wird, und von dem mehrere nacheinander in einen Container gepackt werden, wenn es mehrere Tabellenzeilen gibt. Die meisten Tools (wie z.B. der Ausbildungsrechner) nutzen diese Variante (HTML Code übergeben als Template) in Kombination mit genau einer Tabellenzeile, um die Einstellungen anzuzeigen. Die einzelnen Intervalle im Ausbildungsrechner, Angriffe im Adelungsrechner, Timer im Timertool, and so on, sind auch alle mit dieser UI realisiert. Die wird basically überall genutzt und bietet uns einige praktische Funktionen, um uns kaum noch um die UI kümmern zu müssen:

    • Änderungen an den Werten werden sofort erkannt und angezeigt
    • Inline-Editierung funktioniert automatisch, sofern für die Spalte aktiviert (z.B. Kaserne, gr. Kaserne, and so on im Ausbildungsrechner): Auf den Wert klicken ermöglicht Bearbeitung.
    • Validierung von Usereingaben funktioniert automatisch, indem wir nur einen Validator hinterlegen
    • Nutzereingaben werden automatisch geparst, ggf. über hinterlegten Parser
    • Formatierung funktioniert automatisch, indem wir einen Formatter hinterlegen
    • Bedingte Formatierung ist möglich
    • Sortierung ist möglich (wenn als echte HTML Tabelle genutzt, können die Überschriften angeklickt werden um zu sortieren, falls für diese Spalte aktiviert, z.B. in der Weltenübersicht)
    • Hinterlegen einer Berechnungsvorschrift für Spalten ist möglich (d.h. eine Spalte automatisch aus dem Wert der anderen Spalten zu berechnen)
    • Wenn ein Tool für alle Zeilen Berechnungen durchführt (z.B. wenn man das große Fest beim Verteidiger aus/einschaltet im Adelungsrechner), kann im Quellcode die UI Synchronisation de- und wieder reaktiviert werden, damit nicht jedes mal unnötigerweise neu gerendert wird, wenn durch Quellcode ein Wert geändert wird.

    Soweit so gut, als ich sie geschrieben und erweitert habe, habe ich allerdings (mehr oder weniger bewusst) nie so wirklich Wert auf Performance gelegt, weil ich die im Nachhinein immernoch problemlos verbessern kann - und sich das dann auch direkt auf alle Tools auswirkt. Und genau darum habe ich mich am Wochenende endlich etwas gekümmert:

    • Wird eine Zeile aus der Tabelle gelöscht, wird nun nicht mehr alle Folgezeilen neu gerendert um die Indexverschiebung auszugleichen, sondern die Zeile aus dem HTML Code gelöscht:
      Bei jedem UI Update wird geprüft, ob die Anzahl der HTML "Zeilen" mit der Anzahl an Datensätzen übereinstimmt. Wenn es zu viele HTML Zeilen sind, werden die überschüssigen von hinten an gelöscht und anschließend alle Zeilen neu gerendert. Das war von Anfang an nur als Fehlerprävention implementiert und sollte später dadurch abgelöst werden, dass die eigentlich betroffene HTML Zeile gelöscht wird - was jetzt der Fall ist.
    • Wird ein einzelner Wert einer Zeile editiert, wird nicht mehr die gesamte Zeile neu gerendert, sondern nur noch das Element, welches den Wert der Zelle beinhaltet hat.
    • Wenn die UI Synchronisation wiederaufgenommen wird, wurden bisher alle Zeilen neu gerendert, um sicherzugehen, dass alles aktuell ist. Jetzt werden nur noch die in der pausierten Zeit geänderten Zeilen neu gerendert.
    • Es werden einige Sachen jetzt gecacht

    Insgesamt ist die Performance für einzelne Änderungen um (bei nur vier Spalten, bei mehr Spalten signifikant stärker) um einen Faktor von durchschnittlich ~400 angestiegen und das Hinzufügen neuer Datensätze geht jetzt ~25x schneller. Da ginge zwar vielleicht noch etwas mehr, aber die Performance reicht denke ich für die praktische Anwendung.


    Geplant sind für die UI übrigens noch:

    • Anzeige von nur einem bestimmten Ausschnitt der Daten (sei es Filterung oder Aufteilung in mehrere Seiten)
    • Stapelverarbeitung ermöglichen (wird z.B. vom Einsatzplaneditor zwangsweise benötigt werden)

    Übrigens: Ich weiß, dass es wohl bereits fertige JS Bibliotheken dafür gibt. Und die haben wahrscheinlich einige Vorzüge (z.B. performancetechnisch). Ich habe mich dennoch bewusst dafür entschieden, das selbst zu schreiben - und zwar weil ich sehr Spaß daran habe, solche Sachen zu programmieren und dann auch selbst zu nutzen. Es mag wohl sinnvoller sein, Fertiges zu benutzen, aber ich möchte mir den Spaß daran definitiv nicht nehmen lassen. Solange meine Version funktioniert, kann was ich brauche und performant genug für den alltäglichen Gebrauch ist, hat es selbst zu programmieren auch keine nennenswerten Nachteile, die am Ende beim Nutzer zu sehen oder zu spüren sind.


    In den nächsten paar Wochen wird übrigens wahrscheinlich etwas weniger hier im Blog kommen. Erstens Job (= Programmieren für Arbeit = keine Lust danach noch an Binary zu programmieren), zweitens Klausur. Wahrscheinlich werde ich daher die nächsten Wochen hauptsächlich nachts am Wochenende an BT programmieren. ^^


    mfg,

    Be2-e4