Schlagwort-Archive: merciless refactoring

Dev-Blog Donnerstag 12/16

Dev-Blog Donnerstag 12/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Die Darstellung unserer aktiven Flotten ist etwas, was mir schon längere Zeit nicht mehr wirklich gefällt. So habe ich mich diesem Thema gewidmet und einen Entwurf für eine zukünftige Darstellung hingekritzelt.

Draft für neue Flottenanzeige
Draft für neue Flottenanzeige

Mittlerweile habe ich damit begonnen, das Ganze umzusetzen.

Bis zur Fertigstellung wird aber noch etwas Zeit vergehen, da ich mich parallel weiterhin mit den Amazon Web Services beschäftige und in dem Rahmen meine Linux Kenntnisse aus längst vergangenen Zeiten abstaube und reaktiviere 🙂 .

Auch den Oster-Event haben wir wieder gestartet – das alljährliche jagen nach Fast HASE und EGG Flotten ist bereits in vollem Gange.

Wirklich vorwärts ging diese Woche aufgrund einer hartnäckigen Stirnhöhlenentzündung bei mir aber leider recht wenig.

[Iwan (shlainn)]

Weiterhin gibt es mehr von dem was es letzte Woche schon gab – Refactoring und kleinere Fixes. Ein angenehmer Nebeneffekt eines solchen Frühjahrsputzes ist es, dass man sich nicht wie sonst, auf ein System fokussiert, sondern sich alles einmal anschaut. Das letzte mal dass wir das gemacht haben war bei der Umstellung vom alten blauen Skin auf den aktuellen Grafik-Style von eXperinox – und das ist schon eine Weile her. Und so fiel einiges an altem Gerümpel in JavaScript und CSS als Nebeneffekt des Refactorings auf – und flog anschließend raus. Das sollte Ladezeiten und Bedienbarkeit in vielen Bereichen des Spiels deutlich verbessern.

Als große Baustellen liegen Derzeit noch Unionen, Flotten und der Baubildschirm vor mir – danach reicht es aber auch 😉

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 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 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.

 

Dev-Blog Donnerstag 52/15

Dev-Blog Donnerstag 52/15

Von Entwicklern für Entwickler

[Horst (Slayer)]

Nachdem wir letzte Woche unsere UnitTests auf Iwans internen Server eingerichtet haben, waren noch ein paar kleine Nacharbeiten erforderlich, damit am Ende alle 226 Tests (zu wenig, wie schon öfter erwähnt) durchlaufen. Aber immerhin – laut Code Coverage Report werden knapp 38% unserer Business-Logik abgedeckt. Und für 2016 haben wir uns vorgenommen, den UnitTests wieder mehr Aufmerksamkeit zu schenken.

Code Coverage unserer Business Logik
Code Coverage unserer Business Logik

 

Pimp my Log, wie im letzten Blog beschrieben, läuft einwandfrei. Ein klarer Fortschritt in unserer Infrastruktur. So haben wir unsere Traces ständig auf einfache Art und Weise im Blick.

Die letzten Änderungen am Dialog zur Flottenzusammenstellung haben mich auch in Kontakt mit einem recht alten Javascript-File gebracht. Schön, wenn man das Gefühl hat, dazugelernt zu haben. Oder anders ausgedrückt: schöner Code ist etwas anderes, ein weiteres Refactoring war die Konsequenz.

Frohe Weihnachten und schöne Feiertage!

[Iwan (shlainn)]

Ah, endlich eine Woche Freizeit für eXperinox! Und so haben wir heute, an Weihnachten, wie versprochen eine erste Version des Handels zwischen Spielern online gestellt.

Die Details dazu, wie der Handel abläuft habe ich schon recht ausführlich im Forum beschrieben. Die aktuelle Version soll als Grundlage für die weitere Entwicklung von Features rund um den Handel dienen. Wir haben uns hier, wie schon beim Profil entschieden, zunächst eine Grundversion online zu stellen, und diese dann iterativ zu erweitern. Zum Einen gibt uns das bereits jetzt die Möglichkeit, wertvolles Feedback von Spielern in die Entwicklung einfließen zu lassen. Außerdem ist es für uns deutlich einfacher, kleinere Stücke online zu stellen, anstatt ein großes Monster-Feature wie das Baumenü vor einigen Monaten.

Wir haben noch einige Erweiterungen zum Handelssystem geplant, die in den nächsten Tagen und Wochen online gehen werden… Aber jetzt wünsche ich allen zunächst einmal Frohe Weihnachten!

Dev-Blog Donnerstag 49/15

Dev-Blog Donnerstag 49/15

Von Entwicklern für Entwickler

[Horst (Slayer)]

In einer sehr konstruktiven Session mit Iwan haben wir festgelegt, dass wir den Handel nicht gemeinsam entwickeln werden, da wir uns bei dem Feature potentiell im Source-Code zu rasch gegenseitig auf die Füße steigen würden. Vor allem auch wegen des im letzten Blog angesprochenen, notwendigen Refactorings im Bereich der Ressourcen. Wir werden das natürlich mit der entsprechenden Vorsicht und in kleinen Schritten angehen und durch gemeinsame Reviews und viel Testen zu verhindern wissen, dass dabei etwas schief geht.

Eigentlich wäre das ein sehr guter Zeitpunkt, unsere doch recht stiefmütterlich behandelten UnitTests wieder einmal in die Hand zu nehmen und zumindest für den Bereich Ressourcen auch etwas zu erweitern. Als ersten Schritt habe ich zumindest damit begonnen, die bestehenden Tests wieder zum Laufen zu bringen.

Dann habe ich noch das für Mitte Jänner geplante Recycling einiges umgebaut. Bisher konnte unsere Raumschiffqueue nur sehr bedingt Aufträge für mehrere Raumschiffe gleichzeitig annehmen. Was dazu geführt hat, dass ich zum Recyclen von 5 Raumschiffen einfach 5 Aufträge abgesetzt habe. Allerdings hat das zu 5 Zeilen in der Auftragsqueue geführt (auch für den Spieler sichtbar) und in weiterer Folge zu 5 Zeilen in der Timeline. Bei 50 Boonglidern ist das Spam pur. Durch den Umbau ist es nun möglich, mehrere zu recyclende Raumschiffe innerhalb eines Auftrages abzusetzen. Damit gibt es auch nur noch einen Auftrag und am Ende einen zusammenfassenden Eintrag in der Timeline. So muss eXperinox!

Auch das Reparieren von Raumschiffen konnte davon profitieren – das habe ich auch entsprechend umgebaut. Beim Update ist leider ein kleiner Fehler passiert, der aktuell laufende Reparaturen schief gehen ließ. Den Bug habe ich aber am selben Abend innerhalb einer Stunde beheben können und so hielt sich der Schaden in Grenzen.

Dieses Wochenende startete auch unsere Ingame Spendenaktion für die Sonnensinsel, einer Einrichtung zur Nachbetreuung krebskranker und schwer erkrankter Kinder. Der Start verlief gut, erste Spenden gingen schon am ersten Tag ein. Aktuell sind es 6 Spenden im Gesamtwert von 45€.

[Iwan (shlainn)]

Eigentlich hatten wir ja angekündigt für den Adventskalender der diese Woche angelaufen ist keine extra Übersicht bauen zu wollen, aber dann hatte ich doch noch ein paar Stunden Zeit am Sonntag und habe noch was gebaut. Ein klick auf das eXperinox-Weihnachtslogo führt zur neuen Advents-Päckchenübersicht. Hier kann man sehen, welche Päckchen man geöffnet und welche man verpasst hat. Jeden Tag reinschauen lohnt sich 🙂

Adventkalender
Adventkalender

Neben den von Horst erwähnten Änderungen unter der Haube, habe ich einen ersten Entwurf für das Design einer Handelsstation entwickelt.

Erster Entwurf Handelsstation
Erster Entwurf Handelsstation

Dev-Blog Donnerstag 48/15

Dev-Blog Donnerstag 48/15

Von Entwicklern für Entwickler

[Horst (Slayer)]

Der Adventkalender ist fertig. Wer sich vom 1.12. bis 24.12. täglich ins Spiel anmeldet, wird also mit einer Überraschung belohnt werden. Da wir – wie schon letzte Woche angemerkt, den Handel nicht vergessen dürfen, haben wir vorerst auf eine Kalenderdarstellung verzichtet. Es wird also nach dem Login jeweils nur eine Seite eingeblendet, die die Überraschung des Tages darstellt.

Und dann hat Iwan im Rahmen der ersten Diskussionen zur Umsetzung des Handels wieder einmal in ein Wespennest gestochen. Acht Jahre alter Code ist nur selten eine gute Basis für Erweiterungen. Wir werden also den Code im Bereich der Ressourcen refactoren, bevor am Handel weitergebaut wird. Merciless! So, wie es sich gehört.

Dieses Wochenende startet unsere Ingame Spendenaktion für einen guten Zweck – nämlich die Sonnensinsel, einer Einrichtung zur Nachbetreuung krebskranker Kinder. Der entsprechende Code zum Spendenaufruf ist fertig umgesetzt und wir hoffen, dass der ein oder die andere unserem Aufruf zur Spende folgt.

[Iwan (shlainn)]

Diese Woche gibt es viel zu berichten. eXperinox, die eingeweihten werden es schon wissen, ist ja ein Weltraumspiel mit Raumschiffen. Daher würde man denken, dass der Code darauf ausgelegt ist, das  einfügen folgender Features so einfach wie möglich zu machen: mehr Weltraum, und mehr Dinge die man mit Raumschiffen machen kann. Dem ist leider nicht ganz so, wie Horst erwähnt hat. Das ist nicht ungewöhnlich bei einem Projekt, das sich seit langer Zeit in der Entwicklung befindet, erfordert jetzt aber doch ein wenig delikate Chirurgie, um am Ende etwas zu haben das besser spielbar und erweiterbar ist, und nicht Frankensteins Monster mit immer mehr angehängten Stücken.

Wir sind aber diese Woche dem Konzept, wie der Handel ablaufen soll, ein großes Stück näher gekommen. Im noXiversum verteilt wird es Handelsstationen geben, die wie regionale Märkte funktionieren. Wer etwas verkaufen will, der muss die Ressourcen zu einer solchen Station fliegen. Dort können sie dann zum Verkauf angeboten werden. Gekaufte Ressourcen werden ebenfalls in der Handelsstation gelagert bis sie abgeholt werden. Handelsstationen werden von der Gönnerrasse betrieben, Angriffe sind also nicht möglich. Gehandelt wird nur nox gegen Ressourcen, oder Ressourcen gegen nox. „Tausche Erz gegen Schaf“ ist ein anderes Spiel 😉

Anfangs wird der Handel auf Ressourcen beschränkt sein. Ob man später andere Dinge (Raumschiffe, DNA,…) wird handeln können, steht noch in den Sternen.

Dev-Blog Donnerstag 35/15

Dev-Blog Donnerstag 35/15

Von Entwicklern für Entwickler

[Horst (Slayer)]
Nach dem Geburtstag ist vor dem Geburtstag. Nachbereitung in Form von Badges für die Hauptsponsoren und Sponsoren des Geburtstagsevents.

Dabei habe ich wieder einmal merciless refactoring betrieben und die Organsation der Awards umgebaut. Das war bisher alles irgendwie auf Sonderfälle und Einzelfälle (DNA Forschung) ausgelegt und hielt nun wirklich nicht mehr meinem kritischen Blick auf den Code stand. So haben wir nun ein Award-System, welches Auszeichnungen in Zukunft einfacher gestalten wird und auch das Erstellen der Spielerprofile in Bezug auf die erspielten Errungenschaften eines Spielers erleichtert.

Und dann hatten wir noch etwas intensivere Planungssessions. Wie soll es weitergehen, was bauen wir als nächstes? Die GamestageEXPO kommt in großen Schritten näher, dann gibt es die Versprechen von Features im Rahmen des Geburtstagsevents und ein weiteres Projekt ist in auch Planung. Das alles muss in unserer eingeschränkten Zeit Platz finden.

[Iwan (shlainn)]

Intensive Arbeit am  Geheimprojekt von letzter Woche hat sich ausgezahlt. Der Prototyp geht morgen in den internen Test (wird also im Team-Cluster und für ausgewählte Tester freigeschaltet) und wird, wenn alles zufriedenstellend verläuft, dann nächste Woche für alle enthüllt.

Nicht ohne eine gewisse Zufriedenheit möchte ich dabei feststellen, dass sich experinox immer weiter in die Richtung des utopischen Zukunfts-Browsergames über das ich vor einer Weile philosophierte entwickelt. Denn mit der Einführung dieses Features bekommt das Spiel eine neue Mindestvoraussetzung:  WebSockets…