Passenger and cargo traffic originates and ends in cities and towns rather than at airports. These locations are connected via ground connections to their closest airports. When demand is distributed, customers will consider connections from and to any airport in the origin and destination networks.
The actual demand is not based on researched traffic numbers from the real world but is generated in-game. This formula-based approach is very flexible and - for example - allows using historic data to compute varying demand in game worlds with a data time offset.
Why?
There are various advantages compared to our current airport-based approach:
It provides more flexibility in simulating different scenarios, including historic ones. The formula can work with all sorts of readily available input factors. Think GDP, Gini index, population development, economic structure etc.
It serves the overall design goal of supporting different business models in AirlineSim. Example: Low-cost carriers operating at cheaper remote airports can capture some of the traffic of nearby network hubs, something that current “costs legs” due to the required ground segment from one airport to another.
It drastically reduces data research effort as it does not require to research point-in-time demand values for each individual airport.
When?
Work on this has started as an ad hoc project at the end of 2025 (see the respective devlog) and is “done” from a functional point of view. That said, many UI-adjustments, loads of tuning and solving some follow-up issues will still require some work.
A first draft of this feature is available for testing in the game world Wright starting today. You can find more details and the current state of development on a dedicated post here.
This is absolutely fantastic news! Basically a mechanism I was also thinking about and wrote about in one of the threads on the forum last year. Can’t wait for different factors like local GDP, geography, etc. to make it into the picture, that will be a game changer. Are you also planning to add seasonality factors in the calculation in the future (perhaps based on climate, seasonal leisure demand for summer sea destinations or winter skiing, etc.)? That would be a great opportunity for some players to actually run airlines that would provide also aircraft leasing rather than running flights themselves Opens so many possibilities for the future, looking forward to the further development! Happy Christmas for now!
Any thoughts on how to assess attractivity of the individual airports (without needing manual input for each of them)? For example, would flying out of LCY be more attractive than flying out of LHR? Perhaps this could then be somehow connected to airport fees, i.e. less attractive airports would be cheaper for the airline but pax would not prefer them so the airline would have to compensate with price - which is basically how EU LCCs operate.
The current airport-based model is somehow flawed in that city airports get less demand because they’re smaller IRL, even though they’re generally more attractive for passengers.
Maybe I misread your question, but this is one of the key side effects of location-based demand. A smaller cheaper airport far away from the city center might be more attractive to airlines and would allow them to offer cheaper flights. At the same time, passengers might dislike the longer drive but accept it for the lower prices. This will be particularly pronounced once LBD is paired with individual travel requests.
What I’m going for is how will the attractivity of an airport calculated. Is it purely distance from some point defined as a city centre? If so, are all passengers prefer to be as closes to this as possible, or will there be some modeled to live close to the airport? Stuff like that.
One issue with the new “location-based demand”:
The demand now handles which planes can fly which route instead of the airport size (“runways”). As for Switzerland (from ZRH), the LET 410UVP can only fly ZRH-SMV, although BXO and SIR have the same “airport size” (“Besserer Feldweg”).
Another extreme example (other way round):
Mönchengladbach (MGL) is size 9 (!) due to the cities nearby, but has just one 1.200 m runway.
(Image). Fun fact: you would not be allowed to fly a Dash 7 MUC-MGL because MGL is too big, MUC too small (7!).
I see this is still experimental, but I think this should change soon, as not the “demand”, but the airport size matters? Please consider a change for this topic…
Absolutely. The “bar-sum rule” has - in fact - always relied on the demand levels rather than the size (which often correlated, of course). In hindsight, this is a birth defect and it should have been based on a more static attribute to begin with. Location-based demand just amplified the issue and I figure we’ll have to look into a change soon.
Regarding the size of Munich: I also realised this yesterday when working on a reworked ground network tab for airports…MUC is smaller than STR. Which isn’t too surprising when you know a.) the structure of cities/towns around Munich/Stuttgart and b.) how the algorithm clusters locations. But still…another round of refinement is already on my to-do list.
I think the sollution would be quite easy to implement:
Make the limitation of planes based on the size of the airport (infrastructure), not the demand in the surroundings. You already have that for all airports, maybe just “translate” the size back to a number (i guess it is a “size_id” in the database already?) that can be used instead of the “bars”.
And:
MUC may have smaller demand levels than STR, but still the airport is not only built for local demand but for usage as a hub! The visualization “at it is” is fine now: you see how high the potential (!) demand is. MGL COULD serve a lot of people, but the infrastructure limits its operations.
Idea for additional realism:
Not only implement “slots” in terms of “runway operations”, but also “gates” in terms of parallel handling of aircrafts. You still can fly 4 planes per 5 mins into MGL, but MGL can only handle 6 planes in parallel (see the parking positions in google maps). More than 6 planes handled heavily increases turn around time! It is not easy to implement, it would act like “slots after slots”. Land at 8:00, but the next handling is available from 8:15 on. Or change from “runway slots” to “handling slots” that are used for the time of turnaround. The runway slots should fit to those from handling in real life? This would increase the use of terminals: you can increase the handling!
(edit: just foundRedefinition of airport handling capacities)
Opens so many possibilities for the future, looking forward to the further development! Happy Christmas for now!