Before diving into the development update, I want to bring your attention to the vote for the name of the upcoming preview game world. Please head over to this thread with the poll, cast your vote and then return to enjoy the devlog 
As mentioned last week, I am working on several âmeta featuresâ in preparation for the preview game world, namely in-game change-logs, a comprehensive feature/configuration overview and better way to restrict access to game worlds (like internal, exclusive orâŚwellâŚpreview game worlds).
While these feature sound trivial (which they are, technically), I use them as a first step towards the long-term transition to what I call the âGeneration 3 frameworkâ: When AirlineSim started in the early 2000s, the state of the art was âaction-based frameworksâ. You follow a link or submit a form and a new page opens. Thatâs what I call âGeneration 1â and youâll find it in old features like staff management or service profiles.
Shortly after, and with the rise of JavaScript in modern browsers, âcomponent-based frameworksâ started to pop up. You still have server-rendered pages, but many interactions would only update fragments of the page instead of reloading everything. Youâll find this âGeneration 2 frameworkâ in most âcurrentâ features of the game, including flight planning, fleet management or cabin configurations.
But for a while now, the leading paradigm has been âclient-basedâ: All UI interactions happen on the client (in the userâs browser) and communication with the server is limited almost exclusively to data transfers (fetch information or issue commands) via an API. This setup has many advantages (and some disadvantages, of course) compared to the previous ones. In particular, it makes building rich, interactive UIs a lot easier, which is particularly useful when building a game that should actually look and feel like, well, a game.
This âGeneration 3 frameworkâ is what I am working towards right now, and the in-game change-logs in particular are my âpathfinderâ here: I need to build the whole setup from scratch, including a new and more modern application setup on the server-side (thatâs what the Spring Cleaning was about, among other things), the foundation for a standardised API, auto-generation API-specification and documentation, a semi-automatic pipeline to build the API client thatâll talk to the server, an internationalisation pipeline for the client-side framework (that handles extracting strings for translation, loading them into the translation management system, compiling translated messages etc.), a general build and test setup for client-side code and last but not least a component framework used to build and style the actual, visible UI. All of these components and more are needed even for a trivial thing like ârendering release notes in a popup after clicking the version number in the footerâ. Hence me using this as a âpathfinderâ.
The biggest challenge here is that I have sworn myself to avoid âmassive, behind-the-scenes updates that take months and years to buildâ at all costs and practice continuous delivery, with all features, even big ones, being build continuously and on the same code base as âproductionâ. While this works fairly well for âregular featuresâ (just hide them behind a feature flag), itâs a very complex affair for something like a UI overhaul, where you canât easily do partial updates. Or rather: Partial updates are complicated to pull of.
As such, finding the right approach and the fitting 3rd party frameworks to enable it, is difficult. And while I feel like I am getting somewhere, I am seriously tired of âframework stuffâ and canât wait to get back to actual feature development. Especially because I am just no designer and all that frontend UI/UX stuff is Greek to me 