Schlagwort-Archive: dev-blog

Dev-Blog Donnerstag 11/16

Dev-Blog Donnerstag 11/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Die schon vorletzte Woche gestarteten Refactorings (User-Input konsequent und zentral behandeln) weiter fortgesetzt. Da das nur bedingt Spaß macht, mache ich das in eher kleinen Häppchen. Wir haben ja kein Feuer auf dem Dach, da uns aktuell keine Lücken bei der Eingabeprüfung bekannt sind. Trotzdem ist mir sehr wichtig, am Ende alle Eingaben einheitlich zu behandeln, weil es das Leben in Zukunft auf jeden Fall vereinfacht.

Letzten Donnerstag habe ich ein eintägiges Seminar zum Thema „Geistiges Eigentum in Theorie und Praxis“ besucht. Die Vortragenden waren absolute Experten im Gebiet von Patenten / Patentrecherche sowie dem Aufbau einer IP-Strategie (Intellectual Property) eines Unternehmens. Auch wenn das aktuell kein Thema für mich ist, so hat sich der Besuch des Seminars in jedem Fall gelohnt.

Dann habe ich mich wieder recht intensiv mit der Amazon Elastic Compute Cloud beschäftigt und den eXperinox Chat fertig aufgesetzt und auch zum Laufen gebracht. Details dazu findet ihr im Blog-Artikel am Samstag.

In diesem Zusammenhang habe ich mich nach über 15 Jahren wieder einmal etwas mehr mit Linux beschäftigt, insbesondere mit der Linux Shell. Ziel: die Log-Files, welche unser Chat in der Cloud erstellt, sollen an shlainn und mich gemailt werden. Automatisiert per CronJob. Eine sehr empfehlenswerte Seite  ist LinuxCommand.org: Learn the Linux command line. Write shell scripts.

[Iwan (shlainn)]

Weiterhin gibt es wenig aufregendes zu berichten während wir systematisch durch alle  Eingangspunkte von experinox pflügen und den neuen Code in Stellung bringen. Und da ich eh gerade dabei bin jede einzelne Seite manuell zu testen, dachte ich mir dass das ein einmalig guter Moment ist,  automatisierbare Tests dafür zu schreiben. Dazu verwenden wir, wie schon einige Male erwähnt, das codeception Test-Framework.

Nachdem wir jetzt doch eine Menge Tests und Checks haben die bei jedem Push in unser git Repository durchlaufen, wurde die  Gesamtlaufzeit auf unserem Jenkins CI Server immer länger. Um dem entgegenzuwirken (und die 16 Prozessorkerne unseres Servers etwas besser auszulasten) habe ich unseren Build-Prozess umgestellt. Mittels des Plugins „MultiJob“ kann man einen Jenkins Job in mehrere Phasen unterteilen. Alle Jobs in einer Phase laufen parallel – was es uns ermöglicht Tests und Stylechecks gleichzeitig laufen zu lassen. Das verkürzt den Prozess um mehrere Minuten – und wird in Zukunft sicherlich noch mehr bringen, wenn wir mehr parallelisierbare Jobs haben.

Dev-Blog Donnerstag 10/16

Dev-Blog Donnerstag 10/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Diese Woche war wieder einmal etwas Arbeit im „Untergrund“ angesagt. Ein paar Refactorings, um so manche potentielle Schwachstelle gerade zu ziehen.

Dabei bin ich doch glatt über einen Bug gestolpert, der dazu geführt hat, dass revitalisierte Aliens im Virgo Supercluster nicht dargestellt wurden. Der Käfer wurde natürlich umgehend zertreten, wodurch man nun auch in Virgo die revitalisierten Aliens im Käfig sitzen sieht.

Und mit den Amazon Web Services, insbesondere mit der Amazon Elastic Compute Cloud. Ein etwas ausführlicherer Blog-Beitrag wird am Samstag folgen.

[Iwan (shlainn)]

Wir versuchen eigentlich immer eine Balance zu finden zwischen neuen Features und Bugfixes/Refactorings – aber derzeit sind wir tief in Refactoring-Land unterwegs.

Bei Web-Anwendungen gilt die eiserne Regel „Sanitize all inputs, encode all outputs“ (in etwa: „Bereinige alle Eingaben, Kodiere alle Ausgaben“) – das bedeutet einerseits, dass alle Information die durch die Nutzer, also unsere Spieler, eingegeben wird, übeprüft und von ungültigen Werten bereinigt werden muss, bevor sie an die Business-Logik unseres Spiels übergeben wird. Und entsprechend muss alles was dann von uns an den Browser geschickt wird so Kodiert sein, dass es korrekt angezeigt wird – Stichwort UTF-8.  Um uns diese, zugegebenermaßen etwas trockene Aufgabe einfacher zu machen, haben wir vor einiger Zeit angefangen umzubauen.  Und in diesem Umbau stecken wir gerade noch drin.

Dev-Blog Donnerstag 9/16

Dev-Blog Donnerstag 9/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Das Thema Barrierefreiheit stand auch diese Woche wieder auf dem Plan, ein weiterer Blog-Artikel ist dazu ebenso wieder entstanden. Das Video auf der Portalseite wurde dabei etwas barrierefreier gestaltet und es skaliert nun bei einer Änderung der Größe des Browserfensters so, wie es soll.

Dann habe ich mich noch etwas mit Amazon Web Services beschäftigt. Näheres dazu wird es in nicht allzu ferner Zukunft im Rahmen eines Blog-Artikels geben.

In der Spieleplattform „Pewn“ habe ich unser Profil auf den letzten Stand gebracht. Neben Webgamers zählt Pewn im Moment zu den wichtigsten Internet-Plattformen, welche sich auf die Fahnen geschrieben haben, kleinere Spielbetreiber zu unterstützen.

Für all jene, die auf den Kampfsimulator warten, den ich unter Verwendung von Construct 2 begonnen habe: das Projekt liegt im Moment mehr oder weniger auf Eis. Die aktuelle Entwicklung an eXperinox selbst stand und steht auch derzeit im Vordergrund.

[Iwan (shlainn)]

Diese Woche habe ich:

1) Deadpool gesehen. Spaßiger Film – für vollen Genuss unbedingt in  Originalsprache anschauen.

2) Constructor gespielt. Ein Klassiker von 1998 – ein sehr stressiges Städtebauspiel mit viel englischem Humor. Demnächst kommt ein Remake raus auf das ich mich schon sehr freue 🙂

3) Prison Architect gespielt. Alle Jahre wieder kehre ich zu diesem Spiel zurück, und es gibt immer wieder etwas neues – denn die Entwickler bauen permanent daran weiter und fügen neue Funktionen hinzu. Die Menge an  Spielmechanismen die hier zusammenarbeiten ist für mich als Entwickler jedes mal aufs neue faszinierend und beeindruckend.

4) The Elder Scrolls Online gespielt. Als Fan der Elder Scrolls Reihe seit Morrowind und Fan von Online-Multiplayer-Spielen musste ich ESO zumindest mal anspielen. Das war vor 4 Monaten…

5) Pause von der experinox Entwicklung gemacht. Nächste Woche geht es weiter.

Dev-Blog Donnerstag 8/16

Dev-Blog Donnerstag 8/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Das Teilen der Flotte hat mich auch vergangene Woche noch ein wenig beschäftigt, aber nun ist ein weiteres, von unseren Spielern gewünschtes Feature online.

Barrierefreie Webseiten
Barrierefreie Webseiten

Zum Thema Barrierefreiheit von Webseiten habe ich den versprochenen Teil 2 als Blog-Artikel geschrieben, in dem es um die Umsetzung der Richtlinien zur Barrierefreiheit geht. In dem Zuge habe ich unser Webportal etwas überarbeitet und die Barrierefreiheit erhöht. Der letzte Schritt ist aber hier noch nicht getan.

[Iwan (shlainn)]

Diese Woche hatte ich sehr wenig Zeit für eXperinox – daher auch nur zwei kleine Features. Von diesen beiden bin ich aber ein klein wenig stolz auf die technische Umsetzung der Chat-Minimierungsfunktion. Die gesamte Minimierung erfolgt durch das setzen einer einzigen CSS-Klasse auf dem Eltern-Element des Chatfensters. Der Rest erfolgt ohne weiteres JavaScript durch das „C“ in CSS – „Cascading Style Sheets“.  Dadurch ist es möglich den Kind-Elementen eines Elements mit einer bestimmten CSS-Klasse spezifische Formatierungen zuzuweisen – die eben nur gelten, denn das Eltern-Element die entsprechende CSS-Klasse hat. Alternativ dazu hätte man das halbe Dutzend Elemente aus denen der Chat besteht einzeln in JavaScript ausblenden können – aber so ist es viel eleganter und übersichtlicher. 🙂

Dev-Blog Donnerstag 7/16

Dev-Blog Donnerstag 7/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Das Teilen der Flotte ist das, was mich diese Woche beschäftigt hat. Nach der ersten Implementierung ist mir noch das ein oder andere eingefallen, was man prüfen sollte (Anti-Cheating) und ich habe mich auch dazu entschieden, schon in der ersten Version das explizite Verteilen von Treibstoff und Pillen einzubauen. Ursprünglich wollte ich für die erste Version einfach 1:1 aufteilen, aber irgendwie ist das doch recht unpraktisch. Und da das nicht allzu viel Aufwand bedeutet, wird das nun doch gleich in V1 umgesetzt.

Auf den ersten Blick sollte das Teilen einer Flotte keine Hexerei sein. Wenn man sich dann aber näher damit beschäftigt, gilt es doch so einiges zu berücksichtigen. Zum Beispiel darf die Start- und Zielflotte nach dem Teilen nicht leer sein (sie müssen also zumindest ein Raumschiff enthalten). Auch in Bezug auf den Treibstoff gibt es einiges zu beachten. So kann der angegebene Treibstoff in der Zielflotte aufgrund der Raumschiffzusammensetzung nicht genug Platz haben. Oder der Treibstoff hat in der Ausgangsflotte durch das Abziehen von Raumschiffen nicht mehr genügend Platz. Dann muss noch der Flottenstatus geprüft werden. Flotten sollen nur Zuhause, im Status Herumhängen oder an der Handelsstation geteilt werden können. Und sie dürfen sich auch in keinem Kampf befinden.

Dann habe ich mich mit dem Thema Barrierefreiheit von Webseiten etwas näher auseinandergesetzt. Etwas, das sich jeder Webmaster näher ansehen sollte. Und wie so oft, wenn ich mich mit einem Thema intensiver beschäftige, ist daraus ein Blog-Beitrag entstanden. In Teil 1 gehe ich näher darauf ein, was man überhaupt unter barrierefrei versteht und im zweiten Teil werden ich mich dann noch der Umsetzung der Richtlinien widmen.

[Iwan (shlainn)]

Auch diese Woche lautet das Motto Bug Bash & Feature Fiesta. Alles was nach erster Einschätzung weniger als eine Stunde dauert kommt unter den Hammer. Für die nähere Zukunft sind noch ein paar Fixes in der 3D-Karte und im Chat geplant – dann reicht es erstmal wieder. Danach will ich mir die fehlenden Features der Handelsstationen weiter anschauen.

Dev-Blog Donnerstag 6/16

Dev-Blog Donnerstag 6/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Wir sind nun schon eine Weile auf dem Refactoring Trip. Bedingt durch die erhöhte Anzahl an Spielern kommen immer wieder kleine Unzulänglichkeiten ans Tageslicht. Und da wollen wir aktiv gegensteuern, indem wir unsere Codebasis immer wieder einmal an den verschiedensten Stellen etwas näher durchleuchten und verbessern.

So habe ich mich diese Woche wieder den verschiedenen Queues (Bauqueue, Forschungsqueue etc.) gewidmet und diese weiter verbessert. Wie zum Beispiel das Abfangen der ein oder anderen Cheating Möglichkeit.

Man sollte sich aber im Rahmen des Refactorings immer wieder die Frage stellen, ob man „in Schönheit sterben will“. Will heißen: man kann es auch übertreiben! Wie fleißige Leser des Blogs wissen, bin ich grundsätzlich ein Anhänger des merciless refactoring – also gnadenlosem Umbau, wenn sich etwas schlecht anfühlt. Trotz allem gilt es am Ende trotzdem, auch Kompromisse zu machen. Nur weil zum Beispiel ein Style-Checker meint, dass man Member-Variable immer in einer bestimmten Schreibweise zu verwenden hat, muss man das nicht immer befolgen. Konkret: um Enums abzubilden, habe ich zum Start des Projektes entschieden, folgende Schreibweise zu verwenden:

class MainMenuEnum
 {
 public static $Communication = 'communication';
 public static $Construction = 'construction';
 }

Laut Style-Checker berechtigterweise ein Fail. Mir aber in dem Fall wirklich egal, weil in Summe weit mehr als 1000 solcher Definitionen im Code stecken. Alternative könnte man auch schreiben:

class MainMenuEnum
 {
 const COMMUNICATION = 'communication';
 const CONSTRUCTION = 'construction';
 }

PHP kennt leider keine nativen Enums, weshalb man sich eben solcher „Tricks“ bedienen muss, die an sich schon suboptimal sind.

Daneben habe ich ein wenig am neuen Feature des Teilens einer Flotte gebaut.

[Iwan (shlainn)]

Das Motto der Woche lautet Bug Bash.

Anekdote dazu: Ein Entwickler von Microsoft Office Excel soll einmal in einem Presseinterview beiläufig erwähnt haben, dass für Excel beim Release der Software noch etwa 2000 offene Tickets im internen Issue Tracking-System vorhanden waren – woraus die  Schlagzeile „Microsoft veröffentlicht Excel mit 2000 bekannten Bugs“ gemacht wurde…

Immer wenn uns ein Problem mit eXperinox gemeldet wird, oder wir selbst eines bemerken, tragen wir dieses in unseren internen Redmine Bugtracker ein, bewerten die Schwere des Problems, und priorisieren anhand dieser Einschätzung, wofür unsere Entwicklungszeit aktuell am Besten zu verwenden ist. Kritische Probleme (Cheating-Möglichkeiten, Sicherheitslücken, alles was direkten Einfluss auf den Spielverlauf hat…) werden immer so schnell wie möglich behoben, andere Meldungen werden zunächst zurückgestellt – wenn ein Button um einige Pixel verrutscht ist, ist das zwar auch unschön, aber nichts was uns nachts wach hält. Hinzu kommt, dass solche vermeintlich kleinen Fixes den für Entwickler äußerst wichtigen Flow unterbrechen können: Wenn ich mich gerade in den Code zum Beladen von Flotten hineingedacht habe, ein mentales Modell davon habe wie alles zusammenhängt, mir sich die feinsten Verästelungen der Objektstrukturen offenbaren – und ich dann „mal schnell“ rüberwechsle in den Nachrichten-Code um „5 Minuten“ ein Problem mit den Smilies zu fixen, kann ich danach wieder eine Weile auf den Beladungs-Code starren um mich zu erinnern was da eigentlich genau passiert.

Doch dank unseres Bugtrackers werden diese kleineren Probleme nicht vergessen, und gelegentlich, so wie diese Woche, startet man einen Rundumschlag gegen all die kleinen Unsauberkeiten die sich angehäuft haben. Überflüssige Seitenreloads, ineffizientes internes Verhalten bei bestimmten Vorgängen, unglücklich positionierte Dialogfenster, fremdgehende Smilies – am Ende dieser Woche werden wir von solchen Dingen wieder einige weniger haben.

Dev-Blog Donnerstag 5/16

Dev-Blog Donnerstag 5/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Das Ressourcen-Update ist durch, der erste große Teil des Refactorings damit abgeschlossen. Trotzdem ist in dem Bereich noch einiges zu tun.

Neben kleineren Code-Reviews, die wir nun ziemlich konsequent durchziehen, haben wir noch das ein oder andere Brainstorming Ticket diskutiert – also etwas in unserem Ideenpool (Redmine 🙂 ) geplantscht.

Ansonsten war ich vergangene Woche eher ein Gefangener des rL.

[Iwan (shlainn)]

Der neue Ressourcen-Unterbau, der uns einiges an Blut, Schweiß und Tränen gekostet hat, ist online. Ebenso ist ein Dorn den ich schon immer im Auge hatte, nämlich das Verhalten beim Beladen von Flotten, auch beseitigt. Eine gute Woche.

Die Flottenbeladung war bislang so gebaut, dass sie immer ein Schiff nach dem Anderen vollgemacht hat. Das führt natürlich dazu, dass wenn man nur mal kurz 1000 Holz mit einer Flotte von 20 Mega-Raumern verschiffen wollte, alles Holz in den ersten Raumer geladen wurde, und 19 Stück leer mitgeflogen sind. Das neue System verteilt die Lade- und Entladearbeiten geschickt auf alle Schiffe, sodass in einem Fall wie dem gerade beschriebenen, die Ladezeit durch paralleles Laden in alle Schiffe deutlich verkürzt wird.

Wir sind immer bestrebt unser Sortiment an Werkzeugen die wir im Hintergrund für die Entwicklung von eXperinox verwenden zu erweitern, sodass unsere Dev-Pipeline immer effizienter wird. Neben den von Horst schon mehrfach erwähnten automatisierten Unit-Tests (phpUnit) auf unserem Jenkins-Buildserver verwenden wir auch Code-Style-Checker (phpcs & PHPCheckStyle – ja das sind zwei unterschiedliche Programme :p ) um den Code zu analysieren und auf potentielle Probleme aufmerksam gemacht zu werden.

Zusätzlich dazu habe ich mir Codeception angesehen – ein Testing-Framework auf der Basis von phpUnit, dass es einfacher macht Acceptance tests durchzuführen – über einen Browser automatisiert bestimmte Aktionsfolgen an einen Test-Server mit eXperinox zu schicken, und sicherzustellen, dass jeder Click noch die gewünschte Aktion nach sich zieht.  Das ist etwas, das mit phpUnit auch möglich, aber eher umständlich ist. Wenn Codeception hält, was es verspricht, wäre das ein weiterer Schritt in eine gute Richtung für eXperinox.

Dev-Blog Donnerstag 4/16

Dev-Blog Donnerstag 4/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Ich beginne jetzt nicht damit, dass ich wieder UnitTests geschrieben habe. Ab sofort könnt ihr davon ausgehen, dass ich jede Woche den ein oder anderen Test schreibe. Das sind wir der steigenden Anzahl der Spieler einfach schuldig. Denn klar ist: mehr Tests erhöhen die Qualität. Punkt.

Und wer sich fragt, was denn aus dem Kampfsimulator geworden ist, den ich mit Construct umsetze, den muss ich etwas vertrösten. Das Projekt liegt vorübergehend auf Eis. Der Ressourcen-Umbau und die geplanten Features für das „Hauptspiel“ eXperinox lassen das im Moment nicht zu.

Ganz im Umbaufieber gefangen, baue ich nun auch die Bauqeues für Raumschiffe und Gebäude um. Passt recht gut zum Ressourcenumbau dazu.

[Iwan (shlainn)]

Das Beladen von Raumschiffen war mir schon immer ein Dorn im Auge. Da hat man eine Flotte von 50 Mega-Raumern, will mal eben 1000 Holz von A nach B fliegen, und anstatt 20 Holz in jeden Raumer zu packen und in Sekunden fertig zum Abflug zu sein, dauert das Beladen 4 Minuten, da die gesamte Ladung nur in den ersten Raumer geladen wird, und die anderen 49 gelangweilt herumhängen. Doch Rettung ist nah! Diese Woche habe ich einen ersten Vorstoß zu einer Verbesserung des Ladeverhaltens unternommen. Diesen werden wir jetzt erst einmal ausgiebig intern testen.

Der Ressourcenumbau in dem wir derzeit stecken wurde ausgelöst durch den Einbau der Handelsstationen, und dient schlussendlich dem Ziel, dieses Feature besser in unsere bestehende Code-Basis zu integrieren – denn zwei parallele Systeme (eines für Ressourcen an Kolonien der Spieler und eines für Handelsstationen) für die gleichen Aufgaben zu haben steigert unnötig die Komplexität des Codes. Und Handel ist auch, wenn alles gut geht, der nächste Punkt auf meiner ToDo-Liste: die vor einiger Zeit angekündigten Verbesserungen rund um Kaufaufträge stehen an 🙂

Dev-Blog Donnerstag 3/16

Dev-Blog Donnerstag 3/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Wer das Wort UnitTests schon nicht mehr hören kann, ich habe wieder einige erstellt 🙂 . Aktuell waren die Bau-Queues für Raumschiffe und Gebäude an der Reihe. Ein recht zentraler Teil in eXperinox, dem etwas „Liebe“ nicht schaden kann. Das bedeutet Refactoring (merciless, wie immer), um den Code an unsere immer höheren Ansprüche anzupassen. Und bevor man etwas umbaut, sollte man eben (weghören) zuerst UnitTests schreiben. Denn auch wenn UnitTests niemals alle möglichen Fehler aufdecken können – speziell bei einem Refactoring helfen sie schon ungemein.

Der Umbau des Ressourcen-Handlings (näheres siehe Dev-Blog von letzter Woche) hat große Fortschritte gemacht, die neue Lösung fühlt sich nun sehr gut an. Hier haben Iwan und ich wieder einmal bewiesen, dass wir uns gegenseitig zu Höchstleistungen anspornen und gemeinsam eine klar bessere Lösung aus dem Hut zaubern, als es ein einzelner tun könnte. Aber das ist ja nichts Neues: Pair-Programming und gemeinsame Code-Reviews steigern die Qualität eines Sources-Codes.  Zwei Gehirne denken besser, 4 Augen sehen mehr 🙂 .

Und ganz nach unserem gelebten Motto, dass wir gerne Wünsche unserer Spieler erfüllen, habe ich diese Woche einen davon sehr kurzfristig umgesetzt. Nämlich, dass Spieler einer Union Heimatplaneten eines ihrer Mitglieder auch während des Einsteigerschutzes anfliegen können, zum Beispiel, um sie anhand eines Transportes mit Ressourcen versorgen zu können. Anfrage im Chat gegen 1715, online ging das Feature schon eine Stunde später 🙂 .

[Iwan (shlainn)]

Ich habe mich eines alten Feindes angenommen: der Touch-Bedienung unserer 3D-Karte. Vor knapp zwei Jahren als ich die ursprüngliche Version der Karte schrieb, war die Welt noch einfacher, touch-Unterstützung noch nicht standardisiert, und ich war ehrlich froh, dass das Ding überhaupt läuft. Heute, 2016, hat man keine Ausreden mehr nicht zumindest simple Unterstützung für touch anzubieten. Und so sprang ich diese Woche über meinen Schatten.

Das Auswählen von Objekten in der Karte ist jetzt deutlich zuverlässiger, man kann die Karte durch wischen verschieben, und auch einfache Multi-touch Features wie das Drehen der Karte durch Wischen mit zwei Fingern und Zoomen mittels Kneif-Geste (heißt das so? Iwan ist verwirrt) sind eingebaut. Derzeit durchläuft der Code interne Tests, aber mit etwas Glück ist er, wenn dieser Beitrag online geht schon im Spiel und macht das Leben von Spielern an mobilen Endgeräten einfacher.

Dev-Blog Donnerstag 2/16

Dev-Blog Donnerstag 2/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

UnitTests, UnitTests, UnitTests. Ich bin wieder auf den Geschmack gekommen und schreibe nun wieder vermehrt UnitTests. Vor allem, seit ich seit der Coverage-Analyse von Jenkins nun weiß, dass es mit unserer Testabdeckung noch etwas schlechter aussieht, als kürzlich hier behauptet. Nicht etwas mehr als 35% sind es, sondern nur schlappe 26%. Warum der Unterschied? Naja, Statistiken, man weiß ja – nur wer sie selber fälscht, kann sie korrekt interpretieren  😉 .

Bei der ersten Coverage-Analyse wurden Klassen ausgeklammert, die 0% Abdeckung hatten. Diese sind nun mit berücksichtigt und verschlechtern somit unseren ohnehin üblen Wert noch weiter.

Dann habe ich mich vergangene Woche wieder einmal etwas intensiver mit Transaktionen, Isolationslevel und Deadlocks beschäftigt. Unser Code braucht an der ein oder anderen Stelle in diesem Zusammenhang auch noch etwas Refactoring.

Auch im Zusammenhang mit den Ressourcen haben wir weiteren Handlungsbedarf ausgemacht und uns in eines der gnadenlosesten Refactorings Ever! Ever! Ever! gestürzt.

Die Konsolidierungsphase hält also noch etwas an.

[Iwan (shlainn)]

Das schreiben von Code ist ein iterativer Prozess.

Als wir den Handel implementiert haben, wurde deutlich, dass unser bisheriger Ressourcenhandling-Code nicht ohne weiteres an die neuen Anforderungen angepasst werden kann – und ich habe einen neuen ResourceManager geschrieben, der neben den bisherigen Fähigkeiten auch mit Ressourcen in Handelsstationen umgehen konnte und einige weitere Verbesserungen brachte. Zunächst haben wir den neuen Code nur für Handelsstationen eingesetzt, um sicherzugehen, dass alles auch in der realen Umgebung unseres Spiels (und nicht nur in UnitTests) so funktioniert wie es soll. Das war vor Weihnachten.

Letzte Woche haben wir dann begonnen auch im Rest des Spiels den ResourceManager einzubauen – und dabei fielen Sonderfälle auf, in denen Ressourcen verloren gehen könnten, wenn wir den neuen Code einsetzen – sodass Horst eine zweite Version des ResourceManagers schrieb, welche die Probleme behob. Bei weiterer Analyse fiel uns dann aber auf, dass dadurch auch eine der Verbesserungen aus der ersten Version verloren ging. Nach längerer intensiver Diskussion krempelten wir dann das Design noch einmal komplett um – und sind jetzt bei der dritten neuen Version des Ressourcen-Codes.

Diese Version haben wir jetzt überall eingebaut und testen in den nächsten Tagen intensiv, bevor wir sie online stellen. Ressourcen sind ein äußerst wichtiges Thema, und Ressourcen die durch Bugs verloren gehen (oder durch Exploits unrechtmäßig gewonnen werden können) sind für Spieler, und uns als Spielebetreiber, extrem ärgerlich und frustrierend – und das wollen wir um jeden Preis vermeiden.