Endless Skies – Expanding to infinite horizons
Written by: TheDevBird
Air traffic controllers don't get enough credit. They manage the entire sky, every single aircraft that isn't on the ground. The amount of aircraft in the air at any given time is around 10,000-20,000 (source). A single air traffic controller can manage from 45-70 aircraft per hour (source). All of this happening 24/7. Luckily, there are strict rules on what areas a controller has jurisdiction over and how aircraft are transferred between them, alleviating some of the workload (and adding some too).
We were enthralled at this; controllers all over the world managing every single flying aircraft. That's cool. ATC games don't really go past a single airport, aside from Vatsim, a player-run ATC system for Microsoft Flight Simulator. So, after conquering the voice-to-task and ground control systems, we wanted to expand further.
Of course, this would be challenging, right?
Foreword
Airwave's vision has since been changed to reflect a more vertical model rather than infinite horizontal scale. This post was made a few months after these changes were made and shortly after they were recently removed.
The Big Bang
Expanding our single-airspace-focused game into a massive controlled world seemed fairly straightforward, surprisingly. Most of the back-end code was already dynamic, allowing for multiple airports within the singlular airspace. It wasn't all great, however. The bulk of our next challenge was to:
- Place airports randomly in a world-space
- Make aircraft intend to go between them
- Allow an aircraft to know which airspace it is within
- Get the frontend to support changing airports/airspaces
The first problem was the perfect place for fun math. We provided a max radius for the world, minimum spacing distance for the airports, then brute-forced a random generation that fit all of them nicely in place. Sure, it wasn't pretty but we were able to fit about 20 airports all within a 1000x1000 nautical-mile world-space.
The second problem, a little less easy. We needed the aircraft to choose the player's airspace specifically, preventing aircraft from travelling between airspaces that the player didn't control. This would allow the player to treat all aircraft in the world as either inbound or outbound from their airspace.
Sure, it wasn't realistic, but it made the game easier as the player didn't need to keep an eye on all aircraft like a ARTCC controller would. We were still in the testing phase, after all, so we were fine with this simplification.
Next, aircraft needed to know where they were. Like the first problem, this was also pretty easy: iterate through all airports and find the closest one and assert that we are within the minimum range for it.
But how do we display all of this?
The last challenge was the most difficult, as is usually the case. Tying everything together required new UI elements to be built, allowing the player to change the airspace and airport they wanted to control. Further, the stripboard would need to automatically update based on the airport, rather than be hard-coded to the runways and states of the main airport.
Piping in enough context for the dropdowns and info panels was a little rough. The server couldn't help us here, the front-end was responsible for making all of the decisions in terms of displaying airport information. We wanted to ensure that the back-end's job was only to receive commands. It shouldn't care what airspace a player is controlling, receive and process commands on a frequency.
So we needed to make sure that the front-end let the user know what airspace they were controlling, which would be displayed in different places. This also included rewriting all of the code for our lovely, manual stripboard.
Goodbye, manual stripboard
The stripboard is the backbone of an air traffic controller. It's their second brain. In the real world, a controller will jot down flight information on a strip of paper and organize the strip under headers based on the status of the flight. We wanted to keep the same feeling of real things by making the first prototype of our stripboard semi-manual. The information on the strips would update automatically, with new strips being created at the top of the board. Sorting was left to the player, allowing them to happily flick a strip from “Approach” to “Landing” once they were done with handling a flight.
But due to the changes forcing a dynamic foundation on the front-end, we couldn't find a suitable workaround for allowing the stripboard to update nicely when switching airports. Either we store the state for each airport's stripboard, or we regenerate the strips when an airport is switched to, forcing the player to re-sort them.
Sadly, we opted to completely rewrite the stripboard, making it fully automated. Putting all of the work on the UI meant that we 1) had to implement logic to assert the state of the aircraft and 2) could provide the player with an up-to-date view of their airspace without the need for their intervention. Yes, the satisfying flick of shuffling the strips was gone, but players could now see a granular list of all of their aircraft, the state of each (landing, taxiing, approaching), and other important info at a glance.
This new stripboard was different. Both the new and old were enjoyable in their own ways. The old one with manual sorting meant that we had to keep on top of both our airspace and stripboard. But the new, automatic one allowed us to use the stripboard as a glance-able way to assert the state of aircraft we could and couldn't see.
The turning point
By the time we had expanded each system, building deep features into Airwave, the game was almost a perfect demo of a true simulator. All aspects of an aircraft's journey were supervised. You could guide an aircraft from the airport where they spawned, guiding them to land at yours, then back to theirs.
But, with great power comes great responsibility, of course. All of this was becoming too hectic for both me and my co-developer, Leon. Now, two people weren't enough to play the game. I wasn't sure how to feel about this. On one hand, it put the game in a “game to play with friends” category, but that wasn't ideal if I wanted to have it scale from a single player to many.
Oddly enough, the issue wasn't just about adding more airports. It was the task of having to control aircraft even after they left our airport. With our realistic framework, aircraft could take up to an hour to reach our airport from the furthest airport in the game. That just wasn't right. Old Airwave focused on bringing aircraft from the edge of the airspace, to the airport and back. Our recent “milestone” grew that supervising area past our airspace to the entire world.
It got to a point where play-testing Airwave was similar to that of an airline pilot during cruise: doing a lot of nothing. This was all due to the dreaded center controller position.
Note: In our playtesting, Leon would work as ground, I would work as Center, and we would share the Approach/Departure work between us as we saw fit.
Being in the center of it
I'm sure the obvious answer here is “Yeah, Center/ARTCC is a job. Just find another person to man it.”
And you'd be right, sort of. Center was indeed a solvable problem by adding another player. But as I mentioned earlier, we wanted this to work from one to many players, not limit the minimum to 3. We had to find another solution.
After taking a much needed break from Airwave, we found the solution that was sitting there the whole time. *While, Airwave was a challenging simulator, it was not an enjoyable game.* Enthusiasts, I'm sure, would jump out of their seats if we told them they could follow what real-world controllers do. But tell that to a player who wants a “challengingly casual” (ATC can be casual, right??) learning experience.
We envisioned players having a somewhat chill time, despite the high-intensity of air traffic control. Giving them the task of managing all aircraft, especially all aircraft in-between airspaces, wasn't right. The “fun” rating of the game was looking like this:
- Approach: Guide aircraft from the airspace to land, then through takeoff – Fun
- Ground: Guide aircraft to and from the runways and their gates – Fun
- Center: Watch aircraft move in straight lines, sometimes changing their speed or altitude to prevent collisions – Not Fun
See the issue? The engagement of Center was lacking. Unfortunately, that's all a realistic simulation can offer, the realism part. Center is boring if you're not an enthusiast.
From simulator to game
Our vision for Airwave had to shift from simulator to a gamified version of the real thing. Sure, most inspiration comes from real life, but real life isn't always fun. Airwave needs to be a fun game that isn't solely for people who like simulators (though, you're still welcome to play). Airwave as a game needed a different lens. Something that combined both realism and fun. That is what we are looking to capture next.
Airwave is open-source and available on GitHub.
For questions or feedback, feel free to reach out on Bluesky, on our Discord, or via email: [email protected].