Dev Blog 152: Notifications, tooling and Steam achievements

June 15, 2020

Hey there, airport CEO! It’s already the middle of June and time for another development blog, the 152nd in order, and with that another update on the development progression of Airport CEO as we’re roaring towards a 1.0 release later this year. We’ve had two amazing weeks of development and have been able to work more or less undisrupted which has yielded a lot of progress on all fronts of new feature development, which is also why this dev blog is a bit delayed. The contract negotiation system we spoke of in the previous dev blog has now been fully fleshed out, implemented and is in its final stages of internal developer testing; the same goes for all of the other business aspects mentioned in that very dev blog. We’ve also made very good progress on the implementation of multiple new assets used for the various Alpha 36 features specifically targeting the emergency system, which is very exciting and something we really can’t wait to share with you. However, we will have to try to contain ourselves and do just that as none of those subjects will be the main story of today’s dev blog but instead we’ll take a look at a few other major aspects of Alpha 36 that are not oriented around new development but rather around owning up to technical debt. With this much progress in such a short time, we really have a lot to talk about so let’s end this introductory paragraph and just jump into it!

Notifications

Airport CEO’s notification system, i.e. the system which spawns small single UI containers on the entire left-hand side of the persistent UI section of the screen, has been notoriously annoying and poorly utilized throughout the game’s entire early access period.  It was one of the earliest UI systems to be built for the UI overhaul update and was intended for a very different way of adoption compared to its actual implementation as of Alpha 34 today. However, due to a significant lack of UI design direction in the early stages of the game’s development, the system has over time been more and more abused by having to host a wide array of different notification situations that it was initially never intended for. The discord between the intended utilization and actual utilization is what is causing the system’s most annoying “feature”, never-ending spamming of pathfinding related issue notifications for passenger, employees or vehicles... amongst other random notifications about spam e-mails and whatnot (good lord), piled on top of that.

Notification mayhem stretching from Alpha 27 to Alpha 35.

This is obviously a highly undesirable behavior but has in most cases mainly affected airports that are not correctly built, i.e. containing some significant path related accessibility design mistake. As a way of mitigating the excessive spamming of certain notification types we early on after the initial implementation of the system also implemented a notifications settings panel which allowed CEOs to themselves decide which notifications to get, which notifications not to get and to what extent notifications could be delivered... or simply to disable the notification system all together. It says a lot about the implementation of a system when a common use of that system is to immediately disable it, which we’ve noticed that a lot of CEOs do. An equally bad characteristic of the system is that its spammy nature renders it having the opposite effect of what it was designed for; notifications delivered in excess cause the player to ignore them rather than noticing them... who would’ve thought!?

Only critical notifications are allowed on the "always displayed" overlay...

... while other important notifications can be reviewed in the designated panel.

The notification settings panel was always intended as a temporary solution since it did not resolve the underlying issue of too many sub-systems spamming the notification system with messages which it was never indented to display, but since that behavior as mentioned mainly transpired and affected incorrectly constructed airports, its repair and fundamental fix was pushed forward to leave space for more pressing bug fixing and new feature development. Now, with the deployment and subsequent maintenance of Alpha 35 it has become more and more apparent to us that the time for overhauling this system is now. A large percentage of the bug reports we receive on a daily basis are often caused not by broken code but instead by broken player design. Players are not able to correctly pay attention to what is wrong in their airport, which often leads them to think that something is wrong with the game when its rather so that something is wrong with their design. That pattern alone is in most cases only the developer’s fault as we’ve obviously failed at routing the correct feedback back to the player for them to understand the effects of their design decisions. We hope that with the fundamental overhaul of the notification system as of Alpha 36, some of the feedback the game provides will be more easily interpreted by the player and more importantly, more relevant in its given context.

The notification system in Alpha 36 is overhauled around its initial design philosophy: Player attention is an extremely rare commodity and should be highly treasured. Especially with an update that includes severely disruptive behavior to the airport simulation, i.e. emergencies, it is important to make sure that whatever message is allowed to be spawned in such a sacred part of the screen as an always visible section is either very, very important to a certain situation or very, very relevant, or rich in information, to the context of the airport’s operation as a whole. The practical effect of this change is that you will see a lot fewer notifications in that left-hand side of the screen the system spawning those notifications will only be allowed to show messages about important information relating to the airport in general. We’ve also removed the entire concept of notification settings as this area is now much more respected and “always relevant”. Agents are for example, with a few very rare exceptions, no longer allowed to spawn notifications in that area, they instead spawn so called “world notifications”. World notifications are those small red colored UI container boxes commonly seen around deactivated desks, but now in an evolved shape and detached from objects. For example, if a passenger has an issue finding a path from point A to point B they will spawn a world notification at the position they’re standing (most likely point A). Hovering the mouse pointer over that world notification will reveal a short tool tip message which briefly instructs on what the nature of that world notification is, meaning exactly why it has been spawned there. Clicking on that world notification, depending on the cause of why it was spawned, will in some cases provide additional information through specific panels but you will no longer have to review “passenger X could not perform activity Y” through the old incident panel which immediately marked all path finding “incidents” as resolved; that panel has instead evolved into something else that we’ll discuss a little further down.

Just the positioning of a world notification alone provides context as to where exactly an issue has occurred.

But first we want to briefly inform on another important change to notifications and how they’re delivered, specifically flight related notifications. As mentioned, the previous notification system could often cause important information to go missing and especially information relating to certain flights. With the overhaul of the notification system we’ve also introduced a new UI element to the flight process panel, a notification overview section. If a flight encounters an issue during its turnaround at your airport and spawns a notification, the information of that notification can be overviewed in the flight process panel. If multiple aircraft have multiple critical notifications, a small red exclamation icon will be displayed above the flight process panel button alerting you of the issues you need to deal with. Hovering over the notification counter of a specific flight will reveal all notifications that are tied to that flight and hopefully provide you with a better overview of what exact issue a specific flight has.

An evolved flight process panel with the issue of any flight just a hover panel away.

The notification system is of course just like all other systems subject to change and improvement during the upcoming extensive beta period, but we hope that these initial changes will aid you in becoming more aware of what exactly is going on at your airport.

Tooling: Zone area and path analysis

Building an airport is not an easy task and the bigger it grows, the more terminals you have, the more paths a vehicle can drive and the more taxiways an aircraft can taxi through, the more difficult it becomes to survey your design. As mentioned in the section about notifications, the most common issue an airport CEO today struggle with is making sure that the airport layout they construct is accessible for all agents as the CEO has intended. We receive multiple bug reports claiming that something is wrong or broken with the path finding algorithm when in fact there is most likely some design flaw within the CEO’s airport causing its operations to grind to a halt. Very few tycoon games rely as much as Airport CEO does on correct agent flow with various zones and checkpoints to pass through, not to mention the complexity of designing a functional taxiway system, so it is not a total surprise that a lot of people struggle with this aspect of the game. Whenever we get a bug report like this, we use our development tools to debug the situation and as more and more bug reports of this nature were sent to us it eventually dawned on us that you too need to be able to debug your designs. We’ve thus exposed an array of new tools for you to check your airport’s terminal design and paths, in the hopes that being able to test your designs will not only enable you to more quickly build functioning airports but also lower the frequency of the common, incorrect “broken pathfinding” bug report while also helping us find actual bugs with the path finding algorithm as we move into beta. Let’s go through a few of the tools below:

The zone area tool enables you to analyze what zone and area a specific grid node belongs to. Hovering over a node will reveal its world position, its zone type (i.e. if it is open or secure, staff or international) and to what secure area, international area of terminal area it belongs to. We use this tool extensively to analyze what part of an airport belongs to what area and to make sure that complex terminal layout with zones crossing multiple floors have merged correctly.

The passenger path analysis tools enable you to test if your intended terminal design functions as expected and also enables you to see which path will be the most popular with passengers. Simply start the tool, select an origin position and then a target position and let the tool do its magic. Contrary to how the zone area tool displays its information in a hover panel right next to the mouse, the path analysis tool opens up a separate report display where the path analysis is summarized. You will also be able to get a detailed breakdown of what path the tool either actually found (a green line) or what the closest failed path was (red line). The line currently indicates elevation height by brightness of color (lower brightness indicates a lower floor path) but this is of course subject to change as we continue to develop the UI aspect of the tool.

The path analysis tool is very versatile and can handle passengers, employees, security employees, contractors, baggage, vehicles and aircraft. Click on the magnifying glass button in the lower interaction panel, select what agent type’s path you’d like to analyze and select an origin and target position. The tool will try to find the most suitable path as if the path request would have been invoked by the agent interacting with your airport.

We obviously use this tool to debug terminal designs and agent position reachability, and hope that by enabling it for you, you will not only be able to build more efficient terminal layout designs but also to consider the tool before sending in a bug report.

Steam achievements

A game published on Steam is not really complete without Steam achievements and as mentioned a few weeks ago, Alpha 36 and the emergency update will finally bring these achievements to Airport CEO! At the point of writing this development blog, 38 achievements have been implemented and most of them are ready to ship. The achievements are roughly divided into these four categories:

  • Aircraft and turnarounds
  • Agents
  • Management and economy
  • Workshop and community

They will range in difficulty from being very easy and “tutorial like” to extremely challenging. Regardless of any specific achievement, gameplay and fun has always been the primary focus. Technically it was a fairly simple task to make the achievements work and sync to a user’s Steam account. Since a lot of documentation concerning the matter already exists online and the fact that we already use Steam’s API for modding, it was mostly a matter of implementing all the calls to our achievement manager when a certain event is invoked. The counting of these events relies on a Steam-side system, closely related to achievements, called “stats” which lets developers store game related data (ints, floats and their own averaging variable avgrate) on their servers. This way, nothing is serialized locally and therefore can’t be cheated by altering values in the save files. However, being forced to use ints and floats as single variables (no bool variables and no arrays), some clever engineering was sometimes needed to save us from maintaining too many variables on both Steam’s end and in our code base.

As these achievements relates to how accomplished the player is as an airport CEO, we have decided to disable the achievements whenever the player decides to either use sandbox mode, non-simulated construction, the development console (F9) and (or) the development panel (F10). This is airport specific and there will be no-turning-back once the airport’s been disqualified for achievements.

Our freelancing graphical designer Lukas is working hard with the icons that will go with each achievement and below is an example of their general style (of course not final and very much subject to change).

Icons are subject to change.

Steam requires you to publish two versions of any achievement icon, one locked and one unlocked depending on whether or not you’ve collected that achievement. We wanted to have a frame to make the icon easily recognizable as an ACEO achievement but also something fits the aviation theme. We decided upon a style paying homage to the dimmable (electrochromic) window shades popularized by the Dreamliner (and produced by Gentex) which make the icons look both unique and relatable.

The achievements will be deployed, and fully achievable, immediately with Alpha 36 and the emergency update starting with internal and then experimental testing. However, please note before full release (meaning a 1.0 release where we leave early access) all player achievements may be completely reset at any time. Unfortunately, there is no way for us to reset just one of the stored “stats”-values, it is all or nothing and we might need to do hard resets before full release.

In other news

... another aircraft has been assembled in Steve’s aircraft factory and deployed into the most recent Alpha 36 build: The Dash 8 Q300! Since Alpha 36 is the last major content update before the extensive beta period, Steve is working overtime in the factory to ensure that the last birds make it in on time (although there will most likely be some final additions and tweaks to existing aircraft throughout the beta period).

The Dash 8 Q300!

 Phew! That’s everything for this week and we’ll as per usual be back in around two weeks’ time with another update on the development progress of Alpha 36 and the emergency update. And yes, dev blog 153 will take a long-haul flight into the new incident system and all of the assets relating to the simulation of emergencies so make sure to stay tuned for that.

On Friday we’ll be celebrating Swedish midsummer so with that said we’d like to wish you all a “glad midsommar” and a really big “skål!”. Fly safe!

Related blog posts

Dev Blog 156: The Emergency Update released and a new development paradigm

September 10, 2020

Good [insert appropriate time-based greeting depending on your local time state], airport CEO and welcome to the 156th dev blog in order. It’s been another two weeks since we...

Read more

Dev Blog 155: We're back! ... with experimental testing of Alpha 36

September 3, 2020

Hey there, airport CEO! Wow, long time no see and we’re finally back in full force after a much needed but short summer vacation break. We’ve actually been back for quite some...

Read more

Newsletter

Enter your email to get the latest updates and news.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.