CBD 2.0

[LemonButt]

As many are already aware, I've done considerable tinkering with the current City-Based Demand (CBD) and while the current system works for cargo, it has its issues and I have a proposal for CBD 2.0 that addresses these issues with additional capabilities for introducing other features such as connecting pax.


CBD 1.0 ISSUES

1) The squares are too big.  I've beat this horse to death in other threads already, but the important thing to note on the squares is that the current system creates discrete versus continuous results.  What does that mean?  In the most simple terms, a continuous value is one that can be cut in half where as a discrete value is one that cannot.  The number of times heads or tails comes up on a coin is a continuous value (something between 0 and 100%) whereas the actual result of getting heads or tails is discrete (you can't get half a tail).

The intention of CBD is to create a continuous system where demand changes gradually over time.  However, the catchment area of an airport based on the squares creates a discrete system where things happen in dramatic steps (smaller squares would make the system "less discrete").  I recently was successful in expanding one of my base airports (KABE - Lehigh Valley International) from traffic level 7 to level 8.  The result was the new catchment captured the New York City square on the map, resulting in the catchment area population doubling from 19 million to 37 million overnight by simply adding a single (albeit dense) square to the catchment area. (all images can be clicked for full size)



This may seem trivial, but the net effect was revenue going from $635 million to $952 million (+50%) without adding a single new flight.  More notably, since the marginal costs of increased load factors is nominal, my profit went from $135 million to $413 million (+206%).  Furthermore, the cargo demand has remained constant which means my newly found $317 million in revenue is a bite taken out of a fixed pie--the current airlines serving the New York City square just lost ~$317 million in revenue overnight.  I do not believe either one of these scenarios (going up or down $317 million overnight) was intended to occur under the CBD assuming all other factors remaining constant (no big BKs, etc).






2) Traffic levels are counterintuitive.  Currently, airports have an infrastructure/traffic level cap based on the year/era.  This means the largest airports in the world might only be able to reach level 5 or 6 in the early days and eventually grow to reach level 10 in the modern times.  This is counterintuitive because infrastructure and traffic levels determine the catchment radius and subsequently, the catchment squares/population/area.  In the early days there are less airports, less flights, and less airlines--it is logical that people would travel a longer distance to reach and airport in the early days than modern times when air travel is more common with more airports, more flights, and more airlines.  The "real world" application being that in the early days, airports should have larger catchment radii/areas with airports in the modern times having smaller catchment radii/areas due to the larger number of alternatives available.

3) Multiple catchment areas/values are required.  Cargo is affected by pax operations (belly cargo) but pax operations aren't affected by cargo.  This means large cargo hubs SHOULD NOT have a larger pax catchment area because of cargo volume, but large pax hubs SHOULD have a larger cargo catchment area because of belly cargo.  This means large cargo hubs like FedEx's real world hub at Fort Worth Alliance Airport (cargo only--not yet added to AWS) would have a large cargo catchment area, but a small pax catchment area and there isn't massive unfulfilled pax demand to serve.  Likewise, DFW would have a large pax catchment area and a smaller, but still significant cargo catchment area due to the volume of belly cargo.

4) Players don't know what the hell is going on.  Many players in discord and otherwise want to know who they are competing against, but with the system's (necessary) complexity it is difficult for casual players to fully grasp what the hell is going on and how they can skew the odds in their favor.  This complexity needs to be distilled down to as few numbers/benchmarks as possible for the average player to fully embrace CBD.


CBD 2.0 CONCEPTS

1) The squares are too big. To address this, step one is making EVERY airport have the same maximum ~200km catchment area.  This catchment area being the maximum possible demand for an airport at any given time.  This means that my KABE base would start out with a catchment area that includes New York City instead of growing to include it with an overnight spike in revenue/profit (and overnight drop for competitors).  This also eliminates the "bias" that happens with catchment areas based on an airports position in the airport's "home square".  What the hell does that mean?  If you look at the screenshot above, KABE captured a single square to the east to get New York City, but not the west because KABE's position in the home square is to the east of center.  This "home square" position creates other, more significant issues where an airport with traffic level 2 or 3 could have a catchment area of 1 square if it's in the middle of it's home square or if it straddles the intersection of 4 squares, could capture 4 squares and capture 400% the land area of another similarly sized airport.  Setting all catchment areas to it's maximum means all airports are created equal in terms of catchment area, but also changes the system to where all we care about is the aggregate demand in the catchment area versus which square is generating how much demand (additional complexity for players to learn).

2) Traffic levels are counterintuitive. Since catchment areas are the same/maxed out for all airports, each airline/airport will have increased competition as competition actually increases with new airports/new airlines/etc.  Airports in the early eras will have (relatively) more demand while airports in the modern eras will have increased competition.

3) Multiple catchment areas/values are required.  Since every airport has maximum catchment areas, we must create a mechanism to decrease/increase demand based on player activity.  This means introducing two single values that act as scalars between 0% and 100%.  At this point, it's not important how these two scalars are calculated, but only that they exist.  As player activity increases for pax, the pax and cargo scalars go up and as player activity increases for cargo, the cargo scalars go up.  Currently, CBD calculates the amount of demand an airport gets on a route on a pro rata basis--if there is 200 potential demand and two airports have 200 and 200 supply, both airports will get 50% of the demand.  Since we have maxed out the catchment areas and that supply is getting distributed to ALL squares, the way we distribute demand is based on these scalars.  If there is 200 potential demand and one airport has a 25% scalar with 200 supply and another airport has a 75% scalar with 200 supply, the supply that would get applied to that square would be 0.25 * 200 = 50 and 0.75 * 200 = 150 and even though both airports provided the same amount of supply, the split would be 50/150 instead of 100/100, making the "larger airport" get more demand than the "smaller airport".  This distribution of demand to the squares should be compatible with the current system where each airport's supply is simply multiplied by the scalar and plugged into the current functions that assign the demand.

4) Players don't know what the hell is going on.  The current route planning graph works showing potential demand, current supply, and actual demand.  This could easily be implemented for pax in the same manner as cargo.  Each airport would have a pax scalar and a cargo scalar (version 2.1 could have scalars for each class of pax/cargo to get even more granular) which will affect the potential demand, so if the potential cargo demand for a catchment area is 200, but the scalar for cargo is 25% then the potential demand displayed would be 50.  This is simple for cargo as cargo is asymmetric IRL, but pax operations would have the added element of being symmetric, which means that the scalar for an airport would be the average of the origin and destination.  This means the scalar between two large hubs would be high, the scalar between two small airports would be low, and the scalar between a large hub and a small airport would be somewhere in between.

Since flying to a large airport to serve a single large catchment area won't get 100% of the demand due to the scalars, you could still realize significant demand by flying to a major hub and the smaller overlapping catchment areas/airports around the large hub.  For example, Cincinnati (KCVG) could be a large hub.  Under the current system, you could serve 100% of the KCVG catchment area with a single flight to KCVG, making the surrounding overlapping airports useless as you'd just be competing with yourself.  Under this new system, there would still be incentive to fly to Dayton, Columbus, Louisville, Lexington, and Indianapolis as you might get a maximum of 60% of the potential demand flying to Cincinnati and pick up the additional 40% by getting 10% each from Dayton, Louisville, Lexington, and Indianapolis based on the scalars.

CBD 2.0 CONNECTING PAX

5) Connecting pax/cargo modeling with CBD.  Since hubs rely heavily on local populations for significant traffic, building a hub in Omaha will never be as large as building a hub in Chicago.  As a result, we can easily model the network effects of connecting pax using our airport scalars and increasing the "capture rate" of potential demand at an airport.  The number of unique route combinations (nonstop + single hop) can be expressed as (n * n-1) / 2 + n where n is the number of spokes at a hub--i.e. the number of direct destinations.  As an airport becomes more connected, the network effects grow exponentially:

- 10 spokes = 55 unique routes
- 20 spokes = 210 unique routes
- 30 spokes = 465 unique routes
...
- 100 spokes = 5150 unique routes

As the number of unique routes increases, so does the scalar.  Note that an airport with two based airlines with 20 spokes each will create the same network effects/effect on the scalar as a single airline with 40 spokes.

6) Actual connecting pax are nearly impossible to model with CBD.  I know that Sami has built some prototypes to make this work where a landing flight can impact the demand on a flight taking off within 3 hours, but under the CBD model this breaks completely.  Under CBD where "land" generates demand, there is demand between New York City and San Francisco.  This demand could fly from JFK to SFO direct, but there would also need to be a way to properly allocated demand for a direct flight between LGA and OAK which is effectively is the same route/pax/etc. so an airline adding capacity to one route should affect the other.  To further complicate this, connecting pax can connect in Chicago, for example, and assuming there are hubs in Chicago by other airlines, that means JFK-SFO will also compete with JFK-ORD-SFO, JFK-MDW-SFO, as well as JFK-ORD-OAK, JFK-MDW-OAK.  When you add in Newark as an origin, Gary in Chicago as a connecting airport, and San Jose as a destination that can all serve the same traffic with the same connection, you end up with 3 origins/connecting airports/destinations each which means you have 27 possible route combinations to consider.  On top of this, assuming JFK and SFO are major hubs, it's virtually guaranteed that those airports are flying to the same 100+ airports within the US creating hundreds of additional possible connections.  The solution to this would be that pax can only connect at a hub, but that also works in reverse--every hub in the US likely flies to both JFK and SFO resulting in a smaller, but still massive number of connection possibilities.  To further complicate this, additional complexity would have to be added to pricing in order to properly allocate demand--the price of a direct flight should be higher than a connection.  All of this introduces additional complexity that will lose even the most advanced players in fully understanding who they compete against on a route.  As a result, connecting pax can easily be implemented by increasing the scalar at an airport as network effects increase.  I don't know what that looks like in terms of nominal values, but based on the numbers above a 100 spoke hub has 10x the spokes as a 10 spoke, but actually has ~94x the routing possibilities.  The scalar for that airport shouldn't be 94x, but it should be something greater than 10x to reflect the network effects of increasing spokes by 10x having a greater than 10x effect on the overall system.  Likewise it could be modeled where two airlines with 20 unique spokes each would produce a smaller increase in the scalar than one airline with 40 unique spokes as the single airline should, in theory, produce stronger network effects.

CONCLUSION

The end result of this will be a fully "continuous" system--instead of having ~10 steps of discrete growth (technically 20 with infra added), the actual demand of an airport will be fully continuous where it can fluctuate up and down by a thousandth of a percent or many percents based on a player's actions.  This also encourages "coopetition" where two players competing benefits each other and the whole is greater than the sum of the parts versus two airlines fighting over a fixed pie with an eventual winner, followed by a de facto monopoly with no risk of external competition.  If one player dominates a hub under this new system, a new airline could start at the existing hub and take advantage of the existing network effects (i.e. the larger an airline grows an airport, the more attractive it is to new entrants) or they can start at a nearby airport to compete against the incumbent airline's catchment area without benefiting from the existing network effects at the existing hub.

Theoretically, this could also make smaller aircraft/hubs viable as flying to 20 destinations with 9 seaters out of a smaller airport could generate enough demand to be profitable. The early years also becomes more playable with more demand as the catchment areas are larger while the catchment areas remain large in the modern times, but are subject to more competition from more airports/airlines.

The pax and cargo modeling will be "more accurate" as attracting cargo and pax have the same mechanics, but having a big sexy cargo hub shouldn't generate big sexy pax demand because it's apples and oranges whereas a big sexy pax hub should be able to generate a decent amount of cargo demand.

And perhaps most importantly, all of the above reduces complexity for players.  There is no catchment area growth based on traffic or infra levels--only a fixed catchment area with a known maximum value multiplied by an airport's two scalar values (one pax, one cargo) to get actual demand, which also deductively shows how much room an airport has to grow.  Add more supply/destinations/etc. and the scalar goes up and actual demand increases.  This also makes the simulations more realistic as an airline starting out with 10 flights/day, assuming a new game/empty airport, will be best served flying to 10 destinations 1x/daily to create connections/network effects versus simply flying one route 10x/daily which is how most games start today.  This also makes the early eras much more interesting as large airports won't be born large, but must become large through the hard work of players making them large.  An airport will be simple with the catchment area demand and two scalars, but the route planning will also be simplified as there will simply be potential demand/supply/actual demand with the effects of connecting pax modeled without the nightmare of having to display/calculate possible connecting flights and the pricing voodoo required to make them competitive.

[MuzhikRB]

Some additional notes:

1. I would recommend to separate "pax" cargo from dedicated cargo. it doesnt matter how many pax routes you fly from hub, for commercial cargo only dedicated freighters network are matters. therefore I would recommend that when open the base there should be not only infra level (1-4) but also cargo hub option. and any freighter fleet shold be counted separately from pax version. even 752PF should be separate fleet from 752 in terms of commonality.

2. As I remember Sami told that this size of catchment is more/less rely on game productivity issues. more squares - more load on server. but I may mistake.

3.Developing of point 1. All bases should get only cargo from its own catchment area that is not interfered with other even smaller bases. it means LAX will not get cargo from Ontario catchment area even if it is included in its catchment area. AND ONLY if someone opens CARGO hub in LAX it starts getting cargo from all its catchment area without exclusions.
mainly idea is that only bases with opened cargo HUBs can get cargo from nearby bases.  it will eliminate possibility that someone out of china can fly to Ontario and get cargo from LAX area even if in Ontario there is no cargo infrastructure to handle it. It will make life for players much easier if they can check what bases are have cargo hubs.

[LemonButt]

Another reason the current system doesn't work is that the catchment areas eventually grow into each other and you end up competing against yourself in a very opaque way.  For example, if you meticulously plot out 4 airports with adjacent catchment areas to fly to, they will eventually grow to the point that those four adjacent catchment areas now overlap with no transparency into how much demand allocated to each airport is actually duplicated.  Under the proposed system above, this would still occur to some degree, but since it's a continuous instead of a discrete system (not getting 0 or 100% of a square, but something in between) it means that "competing with yourself" means you can actually realize more demand since you can't get 100% from a single airport like you can today.

[JumboShrimp]

re: 1) The squares are too big

We have to be a little practical.  The size of the square is not going to change, even if you are right that the square is too big.

re: 2) Traffic levels are counterintuitive

I think this just serves to distinguish between small, unimportant airport and big important airport.  It also serves to cap the number of square to square calculations that need to be performed.  Tiny airport will only figure in calculations of 1-2 squares, not 10+ squares..

re: 3) Multiple catchment areas/values are required

On one hand, this is feasible, and would probably work well in most of the industrialized world.  OTOH, in 3rd world, where there is not much cargo to begin with, limiting the cargo catchment only to cargo carried would make all of the  3rd world airports tiny cargo catchment, leaving them with even less cargo.

re: 4) Players don't know what the hell is going on

I think we made some progress with displaying the catchment areas and airports sharing catchment areas.  I would say that the additional UI elements would be helpful, and I suggested a few.

re: 6) Actual connecting pax are nearly impossible to model with CBD

I disagree with this.  The system already knows how to solve the problem of square to square demand with direct flight.  It does it by simplification of the problem.
1. the system pins the demand from the square to square to Airport to Airport.
2. Allocation happens on Airport to Airport level
3. System has a way to re-adjust the allocation to Airport to Airport pairs.

So nearly infinite complexity turned into manageable one that system already knows how to solve with some additional periodical system re-allocations / rebalancing.

The same can be done with connecting flights.  Just turning them into "flights", with some clever ways of doing that.

This system would be extended by adding a connecting flights while capping complexity with something like below:
1. generating list of "candidate" connecting flights (based on some conditions, like total flight time,  price, transfers within 1 airline or within alliance)
2. From the full list candidates, a subset of Top X would be selected as Active.  Active for demand allocation.
3. turn both direct and connecting into just "flights" abstraction level
4. From here, the system would do the allocation the same way as before, at a higher level, where connecting flight would act like a direct flight (with some adverse parameters), and certain things like one leg being full would be accounted for.
5. The active routes would be tracked for performance.  Performance = # of passengers/ cargo ended up with some allocation.
6. The system would periodically dump, worst performing routes of the Active list and replace them with new routes from the candidate list.

Candidate list would be generated on the fly
Active list would be stored, for performance tracking

Practically speaking, the direct flights would get the bulk of the allocation, and connecting flights would enter the picture when the supply using of direct flights in insufficient.  This could be further fine tuned with pricing formulas etc.

re: Conclusions

1. Jumpy vs. continuous is not a big issue except some corner cases, as in gaining the worlds biggest demand square, in your example.  The design should not revolve over a corner case.  IMO, the granularity / jumpiness is ok as is, not a high priority to address.  (while we don't have pax CBD and connections implemented)
2. Building a "Network Proxy" on top of the system that is capable of doing the real thing is. IMO, counterproductive.  We could have had a proxy a decade ago;  Some proxies were suggested before the square to square system was designed and implemented. 

In fact, I proposed one of the network proxies myself when I thought that the square to square system would never get done.  But being past the point of having the square to square design implemented, we no longer need proxies.