April 2025 Update (Patreon)

Greetings Everyone,

Two more months left to focus purely on AeroMogul. Let's look over what I've done since the last update.

FBS Fundraising

The FBS system will resume in June. I expect to set the goal to $2000 with an additional $1000 from the leftover money from the failed artwork in Milestone #2.

GearCity: 2nd Gear

As mentioned above, the FBS system is paused until June. The few bugs submitted for v2.5.0.1 will be addressed in June when I reopen the FBS system.

AeroMogul

Disclaimer/refresh: AeroMogul is designed in two parts. The Client, which consists of the graphics and the GUI, and the Server, which consists of the game logic, networking, data storage, etc. These two programs talk to each other in order to play the game. A common misconception is that "server" means internet. The server is used offline when you play a single-player game and is run on your computer. It can also be used to host online, LAN, and even hotseat games.

I'm working on the client side of things, cleaning up the UI and catching it up with the server features. As I mentioned in the last AeroMogul update, after completing the map layers improvements, I moved left to the next set of UI in the game: the save/load system. I left off that last update working on file paths.

I completed moving the save file paths from the client code to the server code. So, now the Client and the Server can see the same save games hosted on the same machine. I've also added a command-line argument to the server code to pass along which save game to load. This is used when launching a game from the Client or starting a server from the command line (which will eventually be superseded by a server GUI program).

With this functionality being one step closer to production-ready, I decided to deviate and work on the save game formats themselves. The bulk of the last two weeks was spent going through the various data in the server (game logic) and formatting the save files for this data. I implemented a compression system which reduces the starting game size (with no turns processed) from 17MB to 700KB. With another test, I dumped all the time slots into the save file, running it up to 900MB raw, which compressed down to 40MB. There is some more tweaking I can do here — I can change the compression formats and levels, or I could change the save formats (moving from JSON to CSV). I'm not sure how much data will eventually be written, but needless to say, we won't be having multi-GB save files like in GearCity.

Since the compressed save files are small (for the time being), the system now timestamps the save games rather than writing over them. This leads to an automatic save-scrumming system. Going back to the load functionality, the Server will automatically load the newest save game of that save file unless a specific previous time slot is selected. I'm not sure if this feature will be retained or curtailed in the future. It really all depends on the size of the save games. But for now, having a backup/snapshot of previous saves is nice.

Finally, I've made both the initial data sets and the save game formats compatible. This will be important in the future if we ever implement a scenario system, as creating a scenario is as easy as saving the game. I also verified loading of save files.

Which brings me to where I am now. I do most of the work on the server side of things in Linux because non-Mac Unix-likes are the least-worst to use and develop on. I have to develop the client in Windows because Unity blocks the editor from working on the OSes I like to use. This means I am doing most of the work in a "Direct Multiplayer" setting.

Before, I would run the server on my Linux VM, and then launch the game in Windows as I would a single-player game. Rather than launching the server process locally and connecting to localhost, I hid that code out and connected to the Linux server instead. I have since cleaned all that up. I unhid the code to launch a local single-player game and created the code for the Direct Multiplayer UI in the main menu. This is where I am today. Unfortunately, I will need to spend a little more time cleaning up this code, as it's having issues sending the game information back to the client when I connect to the server this way.

After I am done with this, the next plan is to move the player creation UI from the Main Menu to the World Map. Move the Multiplayer Hosting and Hot Seat from Multiplayer to New Game in the Main Menu. Redesign the Main Menu Load Save UI. Add Load Save UI to the World Map. And finally, write the client-side UI/code for player privileges, including allowing "mods" to download save games. Then I can move to the next group of UI widgets.