AeroMogul Update #11 (2023/09/18)

My work continued on AeroMogul, although somewhat stymied by a hurricane that hit north Florida. Extended family members occupied my office for some time. So, my focus was limited to the logic/gameplay engine. I managed to improve the performance of the passenger routing system. It is not as fast as before the previous changes set us back, but we're closer to sub-10 seconds again on my R5 3600.  

I also wrote a terminal (command line) client for the game. This client allows me to play the game from a terminal without a graphical client. I only own one computer capable of running AeroMogul's graphics, and it's in my office. Thus, I wrote this client to work on the passenger code. Otherwise, I wouldn't have been able to test any of the code I wrote. This client would prove even more beneficial, as I discuss later.

Some work has also gone into the financial results of flights. However, I couldn't get too far into this because GearCity: 2nd Gear Milestone #2 reached its funding goal! Thus, my work has shifted to clearing out GC's bug list and getting a head start on the new vehicle designer system while we wait for voting results.

AeroMogul's Client

If you haven't heard yet, Unity Software made a major pricing structure change a few days ago. This change created a huge developer backlash. I've received a couple of questions, and there was a little discussion about it on our chat network.

AeroMogul has two engines. One engine contains all of the game logic, AI, and rules. It handles all the data and network connections between players. You can call this the Logic Engine, Gameplay Engine, Server, or by its name, Beardgine III Economics Engine. Any of these names are sufficient. This engine is a self-made, proprietary, in-house design. It uses no closed-sourced code from third-party sources.

The other engine for AeroMogul is the client. The client is what displays the graphics and UI. It handles audio. It takes input from the user and relays requests to the Server. I made our client in Unity.

I chose Unity because of requests from several possible producers. It also had a few recommendations from programmers that I would have contracted had funding come through. And because it had a comprehensive third-party UI library available. 

When selecting an engine for AeroMogul's client last year, I looked at several possibilities, including Unreal, Godot, OG3D, C4, Armory3D, Flax, and Uniqine. While all these engines were nice, they lacked a comprehensive first or third-party out-of-the-box UI solution. I made a similar mistake with GearCity. And I vowed for it not to happen again.  

This requirement limited me to SDL, QT3D, improving Beardgine 2 (GearCity 64bit) and replacing its UI library, or Unity with the "New UI Widgets" plugin. 

From my experience creating Beardgine 1 & 2, Unity seemed like the fastest and least buggy solution.

What Did Unity Do?

If you don't fully understand what happened, I'll briefly cover it. Unity Software has been losing money for many years. Their investments in ad networks haven't fully paid off. So, they devised a multiprong attempt to raise revenues from developers. Some of the changes they made include increasing the upfront costs for the software, removing some lower-level tiers, and adding DRM to the editor. But the sticking point for many has been a flat fee per "installation" of a game. You read that correctly, per installation. The fee amount depends on what tier level you subscribed to and the number of installs. But the base fee was $0.20/install. (In reality, everyone would pay for the higher tier, resulting in $0.15 to $0.02 per install.)

Every time you install or reinstall on any computer, anywhere, it would charge the developer money. There are all sorts of problems with this model. It would charge the developer for pirated copies, returns, demos, etc. It opens up the door for malicious actions. And there is no way for a developer to plan a budget for the actions of their users. Worst of all, there is no way for Unity to track who and how many installs without invasive spyware. Anything less than spyware would be guesswork.

Because the limits are set relatively high (per game $1,000,000 12mo revenues, 1,000,000 lifetime installs), the main focus isn't F-AA tier games, but Free to Play mobile games. In those games, $1 Million in revenues requires 30-200 Million installs. The install fee would cost MORE than the revenues per install, resulting in these companies going broke... unless... they use Unity's ad services. In this case, Unity would waive the fee.

Unity has failed in its efforts to communicate its changes. They provided contradictionary answers in multiple locations and then just fell silent. Rumors are internal struggles in the company, even going so far as death threats from within the company that resulted in office shutdowns.

Outside of the mobile niche and the questionable method of tracking installs, most games are unlikely to be affected. However, Unity's ability to retroactively change the licensing terms and the lack of transparency on how much developers would owe has left many afraid and pissed. And they have every right to be. 

There has been enough backlash that Unity has slowly walked back what constitutes an "Install." At first, it was any install, including demos. Then Unity excluded demos and charities. And then an install was just a single user per device.

There is more to it than this, and I have more thoughts on it. But how it pertains to AeroMogul is likely what you're interested in.

What About AeroMogul?

I was always apprehensive about using a closed-sourced commercial engine, especially one of the duopoly engines that took over Indie development over the last decade and a half. Unfortunately, just as I adopted one, my concerns were proven correct.

Luckily, I am not too far into the Client development that I can afford to wait it out and see how the situation develops. I can focus my efforts on the Server, and use the terminal client as needed to continue development. However, it would mean a delay to the Alpha build I had hoped to release.

Unity Software makes 60% of its revenues via its ad-related work. The F2P companies that utilize Unity's ad network are getting hit the hardest by this change, and they're starting to boycott by removing Unity ads from their products. I suspect Unity will continue to backtrack these changes to something more reasonable.  

As it currently stands, the fees would likely not impact AeroMogul if I opt to purchase the Pro license. (Which I had already planned on doing.) Under no circumstances am I willing to track or spy on users's machines. So Unity's tracking of "Installs" is a line in the sand that under no circumstances am I willing to cross. The retroactive changes to the previous version's licenses and terms are also a concern. If they're willing to change the terms of 10-year-old games today, what prevents them from screwing my game 10 years from now?

I am following the situation closely. I have additional opinions on the technical and business aspects of these changes and how they should resolve the issue, but it's beyond the scope of this thread.

If my main concern of installation tracking is not alleviated, I will switch engines for the client. Leaving out the absurdity of charging fees by installs, there is no way for Unity to accurately track installs without invading your privacy. And under no circumstances will I accept that.

Unfortunately, the UI in other engines has not improved. At this point, I see only two paths if I must diverge from Unity. I can try to contract the author of "New UI Widgets" to port his UI library to Godot or contract someone else to create a full UI lib for Godot. Or I upgrade and update GearCity's Beardgine engine. Most of that work is already bounties in the FBS. These would include but are not limited to upgrading the rendering APIs, multi-threading the core, and entirely replacing the UI library with imGUI. These options would create at least a year delay, possibly more.

Any other paths would result in me creating and maintaining a full UI library. It doesn't matter if I select Godot, Unreal, or anything else. Most games don't need the UI toolkits we do. This endeavor would be very costly in time and effort. My other options, such as using pure SDL would require much of the heavy lifting that Beardgine already does, and QT had its own licensing woes in the last few years. 

So, my current plan of action is to wait. I have the Milestone #2 work on GearCity, which will take 1-2 months. Then, I can work on AeroMoguls' logic/server using the terminal client for several months before I must decide on the client engine. I suspect Unity will completely backtrack on their changes, at worst, leaving a flat royalty fee for all newer engine versions. But if not, I have two options, assuming no one else creates a full UI solution for another engine in that time. Sadly, any delay in the client will likely result in a delay in the Alpha build unless you guys want to play in a text console! :)