[EN]
So Quimby has been running for a few days now and from a technical perspective we can draw a few early conclusions. Most importantly, the spring cleaning I worked on over the past weeks apparently didn't introduce quite as many issues as I was afraid it would. In fact, I see only very few errors in the logs and the low frequency of reports we receive from players indicates that the experience looks similar from their point of view. That said, I'm of course still busy ironing out some teething problems and as mentioned before, adjusting the system to the new way transactions are handled will be an on-going process. If everything goes according to plan I hope to be able to roll out the new version to the other game worlds some time next week.
Speaking of "new version": As a few of you might have noticed, the version number of the game (which can be found in the footer of the game pages) has made quite a drastic jump with the roll-out on Quimby. We've been standing at 1.5.x for ages now and only the third number would be increased whenever a noteworthy new feature was introduced. There was no clear rule as to when the first or second values would be incremented (and we did so inconsistently when the we switched to the current framework). So I decided to switch to a new scheme which roughly follows the "semantic versioning" guidelines (see http://semver.org/):
- The first value (major version) will be incremented when we introduce changes that are incompatible to the previous version. We might make an exception in case of massive new features that considerably change the game and the gaming experience, because we will of course avoid having incompatible releases if possible.
- The second value (minor version) will be incremented whenever we add a new feature, remove an old one or replace an existing one with an overhauled implementation.
- The third value (patch version) is dropped altogether. The build numbers we display directly behind the version number today provides a similar information already.
Last but not least, some actual development news. Through a bug report on the forums a stumbled across a inconsistency in our scheduling logic: When you were scheduling flights for an aircraft, you could add a new flight by ticking the checkbox for a particular day. But once that day has been assigned, unticking the box did not remove it again. This was because a ticked box meant "add a flight" instead of "have a flight that day". So I spent over four hours fiddling with quite a few internals and came up with a (in my opinion) better and more logical system:
- When you create a new flight number (no assignments so far), all or no days will be ticked based on your user setting.
- When you choose an existing flight number, all days will be ticked if that is your custom setting. Otherwise, all days will be ticked that have the current aircraft assigned.
- When you choose a flight number from the visual flight plan (second of the hover items of a flight segment), all days will be ticked that have the current aircraft assigned.
This "pre-ticking" is important, because now a removed tick in fact means "remove that flight". Other assigned aircraft remain unaffected unless you actively remove flights (by using the "remove selected day" button) or tick a day to assign the current aircraft (as it has been previously).
Since this is most likely going to break all kinds of people’s workflow (see https://xkcd.com/1172/) and because I had to touch quite sensitive parts of the code, these changes are on an extra branch for now and will be tested on a test server before being rolled out to Quimby (and all the other game worlds at some point in time).
[DE]
Da Quimby nun bereits einige Tage in Betrieb ist, können wir ein erstes technisches Fazit ziehen. Mit am wichtigsten ist dabei sicher, dass der Frühjahrsputz, dem ich über die vergangenen Woche gearbeitet habe, anscheinend weniger Probleme verursacht hat, als ich zunächst befürchtet hatte. Tatsächlich sehe ich nur sehr wenige Fehlermeldungen inden Logs und die geringe Frequenz eingehender Fehlermeldungen von Spielern lässt darauf schließen, dass es aus Spielersicht ähnlich aussieht. Wie dem auch sei arbeite ich natürlich weiterhin daran, einige Kinderkrankheiten zu heilen wie bereits an anderer Stelle erwähnt wird die Umstellung auf die neue Art und Weise, wie Transaktionen gehandhabt werden, ein längerfristiger Prozess werden. Wenn alles nach Plan verläuft hoffe ich aber kommende Woche die neue Version auch auf den anderen Spielwelten einspielen zu können.
Und wo wir gerade von "neuen Versionen" sprechen: Einige haben eventuell schon bemerkt, dass die Versionsnummer des Spiels (welche im Fuß jeder Spielseite auftaucht) mit dem Quimby-Start einen recht drastischen Sprung gemacht hat. Eine gefühlte Ewigkeit lang standen wir bei Version 1.5.x und nur die dritte Stelle wurde erhöht, wenn wir nennenswerte neue Features eingeführt haben. Es gab und gibt aber keine festen regeln, wann die erste und zweite stelle erhöht werden (und während der Umstellung auf das aktuelle Framework sind wir dabei recht willkürlich vorgegangen). Daher habe ich mich entschieden, auf ein neues Schema umzusteigen, welches grob den Richtlinien für "Semantic Versioning" folgt (siehe http://semver.org/):
- Die erste Stelle (major version) wird erhöht, wenn wir eine nicht rückwärtskompatible Änderung einführen. Wir machen hier möglicherweise Ausnahmen, wenn wir große neue Features einführen, die das Spiel und das Spielerlebnis erheblich verändern, da wir natürlich versuchen, nicht rückwärtskompatible Änderungen zu vermeiden.
- Die zweite Stelle (minor version) wird erhöht, wenn wir neue Features einführen, alte entfernen oder bestehende durch eine überarbeitete Implementierung ersetzen.
- Die dritte Stelle (patch version) entfällt komplett, da die Build-Nummern die wir bereits hinter der Version anzeigen, bereits heute einen ähnlichen Informationsgehalt haben.
Schlussendlich noch eine tatsächliche Neuigkeit aus der Entwicklungsabteilung: Über eine Fehlermeldung im Forum bin ich über eine Unstimmigkeit in der Flugplanungs-Logik gestolpert: Wenn man Flüge für eine Maschine plant, kann man einen neuen Flug hinzufügen, indem man den Haken für einem bestimmten Tag setzt. Sobald der Flug aber zugewiesen wurde kann man diesen Flugtag nicht wieder entfernen, indem man einfach den Haken wieder entfernt. Das lag daran, dass die Checkbox die Bedeutung "Flug hinzufügen" hatte, und nicht etwa "an diesem Tag einen Flug durchführen". Daher habe ich über vier Stunden damit zugebracht tief im Code zu graben und die Flugplanung auf ein (meiner Meinung nach) logischeres System umzubauen:
- Wenn man eine neue Flugnummer anlegt werden abhängig von euren Einstellungen alle oder keine Tage vorausgewählt (so wie bisher).
- Wenn man eine bestehende Flugnummer auswählt und eure Einstellung dies vorsieht, werden alle Tage vorausgewählt. Andernfalls werden alle Tage markiert, die die aktuelle Maschine zugewiesen haben.
- Wenn man eine Flugnummer über den grafischen Flugplan auswählt (zweites Hover-Icon eines Flugsegments) werden immer alle Tage markiert, die die aktuelle Maschine zugewiesen haben.
Diese "Vorauswahl" ist wichtig, da das Entfernen eines Hakens nun tatsächlich "diesen Flug entfernen" bedeutet. Andere Maschinen als die aktuell ausgewählte bleiben unbeeinflusst, außer man entfernt aktiv Flüge (mit dem "Gewählte Flugtage entfernen" Button) oder man markiert einen Tag um die aktuelle Maschine zuzuweisen (so wie bisher).
Da diese Änderung vermutlich die Arbeitsabläufe diverser Spieler zerstören wird (siehe https://xkcd.com/1172/) und weil ich einige recht empfindliche Code-Passagen anfassen musste, sind die entsprechenden Änderungen momentan noch auf einem separatem Entwicklungszweig und werden auf einem Testserver getestet bevor sie auf Quimby (und später den anderen Spielwelten) ausgerollt werden.