The Spawning Problem – Why it Took Us Months to Build a Simple Switch

Written by: TheDevBird

#devlog


Hey! We've been silent for the past several months (since December). Sorry about that! We decided it best to take a step back from Airwave, enjoy the holidays, and think about our core problems: Spawning and Flight Management.

Let's talk about that.

Spawning Issues with “Center”

Back in October (2024), we had a fully simulated airport-to-airport system consisting of multiple airspaces and flights that would go between them. We came to call this feature “Center” as it would require a “Center” controller to manage them (or the official name: “Area Control”). But this wasn't fun and didn't fit with the gameplay philosophy of Airwave, as noted in our blog post and aside.

Those posts go into further details but the summary is: Aircraft wouldn't just spawn right outside of your airspace like the old days of Airwave, they would need to travel around 200 miles (max) to get to your airport, taking around an hour to get there. “Spawning,” as it were, was inherently delayed by an hour max. So any changes to the spawn rate were impossible to make instant, as aircraft already en-route would still exist.

Another thing we didn't like was how time-consuming it was to manage aircraft in “center” control to prevent collisions and optimize approach procedures. The two problems kept us from enjoying “center” and Airwave itself. After a bit of thought, we decided to cut it from the game.

Abstract Connections

a flight leaving the airspace through a connection

Late that same October, we removed the integration of multiple airspaces, cut down on travel distances, and focused the game on the single player-controlled airport. We also sped up the tick rate of aircraft en-route to and from their destinations, cutting the wait time down from 60 minutes to just 6, though the speed multiplier was tweaked a few times.

We called this phase “connections”, as the aircraft moved between abstract waypoints, implying other airports without actually simulating them. The aircraft still wouldn't spawn randomly, but they would come from other “airports” and fly directly to the player-controlled airport. This gave the impression of a living world, while still cutting down on the travel time and workload for the players.

a flight en-route to its destination

In this “connections” phase, we went through a few iterations of managing spawning. At first, we gave the player direct control over spawning flights. They could set a spawn amount, base delay, and stagger delay. They could also choose between approaches and departures.

Note, that departures have stayed the same, since there's no travel time involved, just activating a parked aircraft.

flight spawner UI

But this direct management of spawning was too much. We'd have to remember to keep a fresh set of scheduled flights in the queue or else our airspace would be empty. We mainly scheduled five or so flights at a time, allowing us to work out delays and staggers based on how well our throughput was at the time.

flight spawning in context

With the increased workload after going from automatic spawning to full manual control, we decided to scrap this idea. It wasn't removed at the time, but we had to figure out a better design or integration of such a system.

The Elusive “Holy Grail” Solution

It's early March of 2025 now. Despite the long break, Airwave was still on our minds the entire time. We longed to keep the multi-airport design of “center” without the overhead and spawn delay.

Randomly during a walk, as most inspiration happens, I found a solution: If spawns have a delay, why not move the idea of “spawning” to the destination? What that means is, if we fill the world with aircraft and have them be automatic by default, nobody needs to manage them or “center” if they don't want to. If the world is filled with aircraft, you could simply pick and choose which you'd like to deal with, and they would be handed off to you if you've accepted them. Otherwise, they would be diverted to another airport (unrealistic, I know, but it works).

flight accepting system

I thought of this as the final “Holy Grail” of solutions to the “center” problem. Conveniently, I also remembered about the amazing TCAS, and about IFR altitude assignment, so manual control of “center” was not necessary at all anymore. Aircraft would simply avoid themselves directly (TCAS) and indirectly (IFR alts).

a TCAS alert in the radar

But not everything works out, as we've seen during the many months of developing Airwave and the countless solutions to the same problems. Accepting flights came with the same issues as scheduling them, it was tedious and manual.

Taking Inspiration from “Nature”

Yes, “nature”, we all know air traffic controllers live in the wild.

Jokes aside, I took a step back again (after all the previous had failed) and looked at the problem from a different angle. “What is spawning?” I asked myself. “Real world controllers, or even VATSIM controllers, simply deal with what they're given.”

This is true. There is no spawn rate or anything in real world or virtual ATC. So the question wasn't, “How do we deal with spawning?”, it was “How do we manage throughput and workload?”. And that was it!

If an airspace is congested, aircraft are simply diverted or asked to hold in the air. Either that or the ATC levels up and deals with it. But that's the key, an airport can choose to hold or divert inbounds. Same for ground, though the terminology would be delayed or canceled.

The Final Solution

After brainstorming, grinding away at ideas, and trying out solutions, we finally found the solution to the spawning problem.

About two months after “center” was brought back and spawning was managed by accepting flights, we started implementing a delay system right at the end of April. It took us only a few days to get it to work. Really, it's a simple yet elegant solution.

It's both relieving and frustrating that it took us months to come up with the perfect solution that exists simply as two dropdowns in the frontend. That's it.

the two dropdowns in question

This is how game development works. You start with an idea and run with it. It will go great for the first bit. But then you might hit an issue that you can't solve. You might work around it by implementing other unrelated features. The longer that problem goes, the more frustrating it becomes, holding you back from your vision as you run out of other features to implement.

Airwave is even more complicated as we have a real-world example and our own philosophy to adhere to. That's why we didn't appreciate the first solution of killing “center”, we wanted multiple airports to exist in-game as it would allow for more than just a couple of players to play in the same world.

Moving Forward

Obviously, we can't promise that we will never run into these issues, maybe causing another development drought for months. But when this happens, we'll do a better job of being transparent in the blog, especially as we're trying things out.

Though writing retrospectives is fun, I'm going to push us to write more in the moment, archiving our thoughts as they were, rather than in hindsight.

Expect to see us fail. If we do, we'll blog about it. Our goal for Airwave is not only to be a niche simulation game for ATC and aviation enthusiasts of all skill levels but to be an archive of the thoughts and decisions that go into making that a reality.


Airwave is open-source and available on GitHub.

For questions or feedback, feel free to reach out on Bluesky, on our Discord server, or via email: [email protected].