AeroMogul Update #16 (2025/03/19)

A small refresher: AeroMogul is made up of two parts—the "Logic Server/Engine" and the "Client." The Client consists of the GUI and 3D elements. It’s what you interact with. The "Logic Server" or "Logic Engine" handles everything that happens in the background, including AI, calculations, data storage—everything that makes the game function. It also manages networking. Even in single-player mode, the Client connects to the Server locally on your computer. (To clarify, "locally" means no internet connection is required or used. Some people get confused when they hear "server.") The Server also supports online hosting, allowing dozens of Clients to connect to it. This is why the Client is called a "client" and the Server is called a "server." Our Client is built in Unity3D, while the Server is written in raw C and C++17.

As mentioned in the March update, I have shifted my focus from the Server to the Client—i.e., the parts of the game you see and interact with. I pushed the Server so far ahead that it's now time to catch the Client up in terms of features and polish. For example, when I started working on AeroMogul after the last 2nd Gear Milestone, my main focus became fixing bugs. The Client doesn’t have any major bugs, but there are plenty of small issues scattered throughout. Much of the GUI was originally written as a prototype to test how things look and function. With that in mind, I decided to go through every part of the existing GUI on the world map, fixing minor issues and bringing the design closer to a releasable state.

The way I work, in theory, the GUI should go through three phases (or more like four to get things right). Phase 1 is the prototyping phase, where I establish the general layout, color schemes, and flow. Phase 2 is a usable state, where more features are added, and the game can be fully played. This could be split into two sub-phases: a usable state and a releasable state, where all necessary features are implemented, and it's polished enough for release. Finally, there is the polished state, where everything is refined as much as possible.

Most of AeroMogul is in Phase 1, with a few parts in Phase 2. My current goal is to bring the existing UI up to Phase 2 before adding UI for new features (which will start in Phase 1).

I decided to work from right to left—because I’m bizarre like that. The rightmost UI widgets are the Map Layers system.

This system provided a lot of eye candy in the past. You can see what it used to look like here: https://www.youtube.com/watch?v=66H7G4jlAmM

There were a few problems with this layout. Some bugs, like airport colors not changing, needed fixing. It was also missing content—for example, it only displayed three airport sizes, while the game actually has five. Design-wise, the height was fixed, meaning only the visible options were accessible.

The Map Layer system is meant not only for styling your map but also for filtering data. With that in mind, I needed to switch from a fixed-height system to a dynamic one. I added a scroll bar, allowing me to expand the panel with more options. Drawing inspiration from the rest of the UI, I introduced category buttons that collapse and expand content. I also added missing functionality (such as coloring all five airport types) and fixed most of the system’s bugs. I cleaned up the process for saving and loading style changes, though there are still minor issues. Additionally, I linked the data maps for Population and Income, while the rest are pending creation and implementation on the server side.

I still need to tweak the theming (scroll bars), but this is now a Phase 2, usable UI. I can filter airports off the world map, all functionality works, and the system is designed to support future expansion while maintaining its Phase 2 status.

Continuing from right to left, the next UI element is the Save Panel. The Phase 1 implementation of this UI had the Client saving data to disk. That worked fine—except that the full data resides on the Server. At some point, to debug the UI, I added save functionality to the Server. That was great—except now, the Client couldn’t see which save games were available to load. The Server had no loading functionality, the Client and Server were using different paths, and in multiplayer settings, there were permission issues.

To address these problems, I created a user privilege system. Players are now classified as Admins, Moderators, or Users. The first player to connect to the Server is automatically an Admin (and in dedicated server conditions, the manager program will connect as Admin). In the future, Admins will be able to save, promote other users, kick, and ban players. Moderators will have the same abilities as Admins, except they won’t be able to promote users. Regular Users are just players. None of this will matter for single-player or small private groups, but it’s an important part of the Server’s backend functionality.

I've also updated the Windows port of the Server. The game uses MSYS2 on Windows, which is based on Arch Linux. Unfortunately, because it had been so long since the last update, updating MSYS2 broke a lot of the build. However, I managed to resolve the issues and reduce reliance on MSYS2 system packages.

The Windows and Linux save paths for the Server have also been updated to match the Client’s save paths. The idea is that the person loading the save game is likely the host, playing on their Client. This resolves the issue of save games not appearing in the Client’s load screen. However, edge cases remain—for instance, if the Server is hosted on a different machine from the Client or in multiplayer situations where the host isn’t playing. To address this, I am working on adding command-line arguments to the Server for loading save games. In the future, when I add a system tray for the Server, we’ll have a server-side save game display and loading functionality.

Once I finish the background work, I’ll clean up the UI and add a load button to the World Map Save Panel. Then, I’ll ensure that save loading works properly before moving on to the next UI element.

While none of this directly moves gameplay forward, it’s all necessary work that must be completed before release.