AeroMogul Update #14 (2024/04/18)

TLDR Summary: I pushed back AeroMogul Prototype A because of timing and to make it more of a game and less of a tech demo. I have an outline for improvements to the core system and AI for Prototype A. I've added inflationary data, fuel and oil prices, oil production data, a dynamic jet fuel price system, many new airport fees, fleshed out existing data frameworks for airports, dynamically generated airport fees, and additional routes expenses/calculations. Finally, we have some progress on GearCity: 2nd Gear Milestone #2 artwork. But he won't finish in time, so we'll get a $1000 bonus in Milestone #4.

Intro

We're already four months into the year, and it's my first AeroMogul-focused update post. This delay is not because of a lack of progress, just timing. I worked on Milestone #3 and subsequent bug fixes for the first two months of this year. Then, when there was news, it came closer to the monthly FBS updates, so I put AeroMogul updates into the monthly FBS updates instead of their own mid-month featurettes.

So, with that explanation out of the way, let's cover a few things and update you on progress.

AeroMogul Prototype A

My initial plan was to build a prototype for contributor testing in Q1 of this year. However, GC Milestone #3 was extremely buggy. And it will still require another bug fix patch in a couple of weeks. And GC Milestone #4 will reach its goal next month. That means I have the next month or two booked for GC, and I won't be able to give too much time to AeroMogul.

Currently, AeroMogul is nearly ready for that planned prototype. The only missing part is the player GUI for Advance (mode) Route Scheduling. However, at the start of this month, I decided it would probably be best to delay Prototype A for two reasons. The first is the timing with Milestone #4. I would not be able to give either the full attention it deserves if the development of Milestone #4 and AeroMogul Prototype A came out simultaneously.

The second issue is mainly of content. AeroMogul's core loop is finished, but it's rudimentary and not fun. What do I mean by that? Well, from the player side, you'd start a company. (With half the sub-systems not implemented). You click an aircraft from a list to take ownership of it. You buy slots from two airports. Then, create a route between these two airports, assign a plane, and then the no yet implemented feature of managing that' plane's schedule. You end the turn. The game calculates passengers. You get some revenues, and you adjust prices. That's it. That's the fundamental loop. The AI does the same. However, beyond the initial routes, its route creation is random. Its reaction (price changes) is nonexistent. The aircraft pool is limited, and there are few expenses.

The frameworks for many systems are all there. But they need to be fleshed out with rules before we can use the mechanics in the game.

So, I decided to push the core loop forward this month instead of rushing through the route GUI and pushing out Prototype A while I was working on GC Milestone #4. This means I will be delaying Prototype A to sometime this year. But it will be more of a game and less of a tech demo. How long? Well, that depends on too many factors to guess. Will Milestone #4 be buggy? Can Serhey do more artwork bounties? Will I be able to put my youngest into pre-k (thus freeing up 10-15hr a week for more work.) But I can guarantee Prototype A will be ready this year. It could be ready at the end of this month if I stuck with the original plan.

AeroMogul Design Plans

What's the plan? When I made GearCity, I created all the systems for the player and then did all the testing as a player. When it came time to add the AI, I tacked them onto the player-designed systems. I made each AI company act individually and had its own behavioral traits. In short, the AI played the game as a human player would. This was great in a narrow scope. But it did not scale well in a world of GC's size. Nor did this design perform well when I filled the game world. The result was not only a slow AI but a poor-performing one.

AeroMogul's systems are being designed with the AI in mind first. The player piggybacks off of those AI systems. In theory, this should allow the AI to be stronger and faster. The code to do player actions will be less efficient and messy, but the player would not notice because the front end masks the underlying systems. Nor would any inefficiencies cause performance issues because players do far fewer actions than the sum of all AI moves. (In a multiplayer scenario, the player machine does the formatting before sending it to the server with the AI-designed functions.)

With that in mind, I'm moving the core game loop forward by expanding the existing game mechanics to improve the AI. This will create a richer AI response to the game world and provide the Prototype player with semi-intelligent competition in their testing.

Currently, the AI decides to create a route at random. It grabs a plane from the aircraft pool, makes the route, and while doing so, it checks for slots. This is nowhere near how the final product will handle it, but it was good enough for testing.

What should happen is the AI should decide to make a new route based on several factors. A key one used in several steps is the company's financials. Once the AI decides to make a route, it must figure out where. Once it has two airports in mind, it should determine an aircraft. Unless it already has available aircraft or has invested in a specific aircraft family, in which case, it needs to choose the airports within the bounds of that aircraft's range. Once the AI determines the aircraft and airports, it must check the slot status. If all three are good then it can start the process. The process is in a strict order. The AI needs to stagger aircraft and slot acquisitions to receive the aircraft and the slots simultaneously. Then it may create the route.

AeroMogul Progress

The key to the previous paragraph was financials. Much of the AI decision-making has to revolve around the health and growth of the company. So that's what I set out to improve first this month. The game already has revenue, but expenses are sorely lacking. But before I can expand upon expenses, I need to define the value of money.

Inflation has been in the news all the time lately. The value of money grows all the time. It mostly goes up because orthodox economists fear deflation. But sometimes it does go down. Inflation has to be modeled in a proper business sim. This is no different in GearCity, and it's no different in AeroMogul. In GearCity, we determined inflation around 4 things. Vehicle price inflation, annual USD CPI, hard-coded values, and city per capita values at multi-decade snapshots. (Where the City in GearCity comes from.) I interpolated the values between the data points. I designed the game around 1900 pricing, and the system only goes up.

With AeroMogul, I implemented the system slightly differently. Firstly, the internal pricing is in 2020 dollars. (I'm still mentally stuck in pre-covid times.) I then designed the system to handle previous and future inflation. This design fixes an issue in GC that makes it extremely difficult to do pre-1900 pricing. Since I plan on using this same engine on future products, monthly inflationary data was added into the early 1900s, and quarterly/yearly data as far back as 1820. I will no longer have hard-coded inflationary values like in GC. The formulas won't need it. The Data Grids, previously mentioned in other updates, already contain regional economic data and are akin to the City data used in GC.

A major consumable for airlines is fuel. It's also a major inflationary commodity. As of right now, I've implemented two types of fuel, AVGAS and Jet Fuel. More fuel types will come in the future as I start adding more aircraft/engine data. For AVGAS, which is mostly the same as gasoline, I've implemented monthly USD fuel prices as far back as the 70s. Then, I sourced quarterly and yearly data as far back as the 1890s to fill out the remainder of the data. These prices will follow historical price changes. Airports and FBOs (SLAs) also affect prices at individual airports. Data Grids may also have an effect in the future.

For Jet Fuel, I decided to do things a little differently. I've implemented monthly, quarterly, and yearly prices for barrels of oil dating back as far as the 1870s. I've also added the amount of oil barrels produced each month/year as far back as the 1890s. The game also sums up the amount of jet fuel used globally. With these three data points, the game dynamically generates jet fuel prices based on production and demand.

Why? It might come as a shock, but the commercial jetliner industry consumes the vast majority of jet fuel. And because the game aims to simulate the entire commercial airline(cargo, charter) industry, dynamically generating the prices provides more realism than fixed prices. If the in-game demand for jet fuel is less than in real life, the prices will fall below the historical value. If demand is higher, then prices will increase.

Why not do this for AVGAS? Most AVGAS comes from the same production output as motor gasoline. AVGAS is only a small slice of the auto industry's gasoline use. Its demand doesn't have the same impact on prices.

In GearCity, we only had USD. While the Airline industry practically works on USD, I have set up a framework for UI currency conversions in AeroMogul. I have not added the data to convert currency, but the system is in place.

Airport data also got a major overhaul. As I dug deeper into Airport research (thanks sokerroneous) I deepened some of the fees airlines charged. I also changed a few of the fees and facility measurement units. And I made changes to facility variables. I have not implemented many of the features that will use these changes, but now was a good time to do it while I added more to route expenses.

Airport fees are now dynamically generated based on the airport size and demand. With approximately 7000 airports and 80 years of history to cover, I couldn't find all the info needed to manually enter the historical fees. It's probably more realistic to dynamically generate them based on demand anyway.

I also implemented the data frameworks for Airport Service FBOs (SLA) and Maintenance FBOs (SLA). However, I have not filled in the data or implemented any FBO(SLA) features.

There were changes to internal route expenses, aircraft models, and engine data sets to support the new fees.

Flights have a healthy amount of non-labor expenses, including fuel consumption, landing fees, pax fees, and misc fees. There are about 10-20 more airport-specific ones to add, but many of these expenses will require buildings/rental features first.

AeroMogul Next

With Routes now generating revenues and a good amount of expenses, the next step is to flesh out the AI aircraft procurement process. The improvements will not include new aircraft production or buying on credit. The AI must check its cash funds, buy an aircraft, and have that expense deducted from its balance. The purchase needs to cue for delivery.

After that, I need to expand the slots system by putting airports into the negotiation modes when they get full. The AI then must check if slots are available and how long the process will take before creating a route.

After completing those two steps, I can tie them all together. The AI decides it wants to create a route. It figures out where or with what. Then, it gets the aircraft and slots. When both of those are delivered, it sets everything up.

Finally, I'll add a rudimentary system for AI route price changes.

From there, I can complete the player aircraft scheduling GUI and tie the new expenses to the route GUIs. At that point, Prototype A is ready.

GearCity: 2nd Gear Artwork Update!

Serhey has made some progress with testing the material system shaders in 2nd Gear. Once we get this pipeline under control, things should go more rapidly. He'll still miss the Milestone #4 deadline, but with a little bit of luck, he'll finish before Milestone #5!

This shader has a few errors that prevent normal maps, but it still looks pretty.

This is closer to what we'll see in the game. It looks awful because we're testing a few things. But if you look closely, you'll notice normal mapping (gaps, indentions, and bumps). That should help improve the aesthetics when the artwork finishes. You can also see a bit of reflective maps.

I think I'm over 2000 words now. So, I am stopping here. I likely missed a few things I have done or am working on. But I should be working instead of writing a novel!