Connecting Traffic?

[Sigma]

Connecting traffic is already build into pax demands as it's (partly) based on real figures. Right?

Yes and No.

By default it's not.  The pax demand is, more often than not, simply a matter of comparting City Sizes to get an estimated demand between them.  That's why so many O-D pairs have virtually identical pax demand between them.  In the face of a lack of data, which is the case for 95%+ possible O-D pairs, it's simply guesstimated.

In other cases it's based off publicly available pax demand.  This may or may not be inclusive of connecting pax.  Certainly in many cases it's not.  The only statistical data of any use is data from a passengers actual origination to their actual destination, not traffic between two airports as that demand data is of little use to anyone in the business.  That's why there's semi-accurate demand in the game for some routes that aren't flown direct in real life.

And then there's the "data" that's put in after the fact by people submitting it.  Which frankly I've never thought was a good idea because it's simply a self-fulfilling prophecy of real-life.  In real-life there may be 200 flights a day from London to New York, but if 150 flights worth of passengers were actually flying from, say, Paris via London or continuing on to Denver (or some combination thereof) then changing the demand in the game between New York and London to fit the real-life number of seats flown on that route is in contrary to how demand on every other O-D pair is calculated.  We already have demand from Paris to Denver (whether good or bad) we shouldn't be changing the demand between London and New York to include these passengers.


Now, back more on the subject at hand, I always thought this would be an intriguing way of doing (at least a form of) connecting passengers, at least regional connections anyhow...

Let's say I start my airline in DFW.  I then open a route DFW-JFK which has demand of, say, 200/day.

But then, in this game, there's also demand to JFK from literally dozens of nearby cities/airports around DFW, and likewise demand from dozens of airports around me to dozens of airports around JFK.  If no one is flying to these airports one would have to assume that they would simply have to drive to DFW to fly to JFK and/or fly to JFK and drive to their final destination.  So, barring anyone else creating a direct flight to these airports, the demand should be summed up with the demand out of DFW.  And the demand to airports around JFK summed up as well.

Now, say someone opens up a route to JFK out of DAL (somewhat across town from DFW)... they should get the demand from all the locations nearer to them.  So everything that was in my XX-mile circle around me to the East, they should get as they're now the closest alternative to a direct-flight.

This gets complicated though when someone, say, opens a route from ATL to Midland that also had a flight to JFK.  Surely the people in and around Midland would rather take the flight out of Midland and connect through ATL rather than drive all the way to DFW to take my flight.

I know it would be a far cry from something easy to do.  But I think it would make the game a LOT more dynamic than it is today.  Now you simply supply 100% of the demand and chances are the vast majority of your routes will go uncontested.  But with the above scenario, the demand on your DFW-JFK route would be dynamically and significantly changing as people opened up new routes to/from nearby airports, just as it does in real-life.

[bukatino2000]

wow Sigma what you describe is overcoming the best of all gaming scenarios!!

Is more a "dynamic demand" then connecting traffic, since less passengers demand would come out from a new (more confortable to reach by driving) origin of departure, thus independently if we speak of a direct or non-direct flight. Simply given demand from A to reach B = 200/pax, if C arises (within xx-mile circle) then demand A to B falls to 100/pax. I think this is an extra issue in relation to this topic and maybe actually only able to straighten Sami's hair  . The state-of-the-art of our demand function doesn't allow many variable values.

IMO the two possible proceedings for connecting traffic are either introducing a function with strong restrictions thus smoothing calculation charge for the server or doing it/typing pro single route. But flying daily 1.000/2.000 cashboxes I'm afraid some of my colleagues would say "¡nada de eso!" in this case.

[mukk]

just so you know, there is indeed (at least) one other airline webgame out there that does exactly that.
passengers can change up to two times, there are transport systems between neighboring airports, and passenger demand is calculated 3 days in advance (so for example flights only 3 days/week make sense since they fill up over time).

(you have to google it if you wanna know the name, but it's not really worth it, cause last time i checked
a) it was only in german and b) the user interface was a real mess compared to this game)

the way they do it there is that the game runs 'in realtime', that means the daily schedule of a plane will be flown exactly once each rl day (the earnings are modified so the game doesn't take forever, but it's still very slow).
this way they have 24 hours to calculate the passenger distribution, so this is how they make it possible (if you compare that to AWS, here the same calculation had to be done within 25 minutes (!), if you keep the current day length).

i just wrote this because i really missed the transfer pax feature here in the beginning, it just fundamentally changes the way you play the game. in that other game, for example, you where able to build up a 'real' hub, using flight waves (e.g. all planes come in before 8 pm and depart after 9 pm) to maximize the transfer effect. so there was a lot more planning involved. it also enabled you to use smaller airports as hub, since you where not so much depending on the airports own pax demand.
i really hope sami will be able to add this to the game someday (and yes this is a BIG challenge ).

[Sami]

The accelerated time here makes things a bit different. If we'd run in real time then it wouldn't be a problem at all, true .. But it will probably be some sort of math formula that calculates the transfers as counting them individually pax by pax in the accelerated time mode is not possible.

[toyotaboy95]

I think there might be a simpler solution to all of this. Connecting flights should be limited to alliance and your own flights (until a more complex formula is made). The first item we have to tackle is the 2nd destination of the route in which the passenger would OPT for direct flights to their final destination but consider the connecting flight IF the price is lower (for example the Kangaroo Route - until a carrier uses the 777-200LR).

[mukk]

ah well, i totally forgot to mention that in that game i was talking about, transfer was also limited, not by alliances, but by cooperation contracts. of course it should be limited by alliance membership in this game, for one to make alliances more attractive, and also to drastically limit performance needed.
i thought about this for a while, and maybe it could be done if you split the calculation in two.
what i mean is, store in the db a list of all existing route pairs (with pairs i mean all existing ways to get from a to b, including transfer routes), that are already ordered by 'quality' (have some sort of quality value set), and maintain this list in realtime (meaning, calculate/remove route-pairs as well as calculate new order whenever someone creates/changes/deletes a route).
this list will be certainly very big (some million entries), but it will also make the majority of the calculation a one time ad-hoc thing. so, all that is then left to be done on a per-day (25 minute or whatever) basis is distributing the pax among the routes.
would still need a lot of performance, but maybe it's not outright impossible.

[bukatino2000]

The number of route pairs goes up more than exponentially by this so before it can be even thought of the calculation system must be tested and partly re-optimized. Not a simple process.  (ie. if we'd have 110 000 route pairs now, with connections automatically this could go to millions, which is way beyond the design limits)

How if we were limiting connections initially among significant (4) + large (5) aiports only? In this way we rule out more than 2/3 of the possible calculations, thus not overstressing the server. What do you think woud be the implications with this?

[slannoy]

Would it be feasable to create connecting trafic as a real flight ?
You will have to create a connection between two flights that would have its own flight number but never has the same route image as a non stop route.

Companies using connecting flights will have:
- To offer reduced prices for this kind of flight (passenger always prefer non stop)
- To ensure the connexion are possible given the time between the two connected flights (just as we have a risk of to quick turn-around)
- To avoid delays that make passengers missing their connections.

Bad connections influence the route image and company image

This way the system will see it as if a company create a new flight and will not have to compute connecting traffic on all flights of a company.
Only the ones the company has decided to make possible and to promote via marketing actions.

[arandall]

What if we did it like this:

Let's take the aforementioned LAX->ORD->JFK route. We'll say there are three other connecting routes, LAX->LAS->JFK; LAX->DFW->JFK; LAX->ATL->JFK.

In order to get rid of the need for the server to calculate constantly other possible routing patterns, we can set up the following rules:

  1) Passengers will prefer the direct LAX->JFK route heavily (we can put a price premium here of some percentage, i.e. a passenger will pay up to 20% more for a direct route).
  2) In order for a connection to work, an airline must register it as a valid connection. For example, it makes no sense to have an LAX->LAS->JFK connection if the time in between       the LAX->LAS flight and the LAS->JFK flight is greater than say, 5 hours. This doesn't have to be a limit set in stone, but the point is to add a time penalty so connections with layovers of greater than a certain number of hours will have virtually no demand.
  3) Include a section where you price the LAX->JFK route via LAS (which will be cheaper than LAX->LAS + LAS->JFK). The point here is that rather than the computer going through all possible iterations of LAX->JFK, the computer only goes through iterations that the airline has already setup. Connections will be tedious, I suppose, for us to setup, considering how many possibilities exist, but there can be a page where after one sets up a LAX->LAS route that all possible connections can be listed, which will be a listing of all flights from that airline from LAS for the next five hours.
  4) Impose a significant enough time penalty, where silly connections, like LAX->HNL->JFK have virtually no demand from LAX->JFK traffic.
  5) Later when feasible, allow for cross-airline connections, where one airline can propose a connection and the other can choose to accept. For example, if I propose a LAX->JFK flight via my LAX->LAS flight and another player's LAS->JFK flight, I can ask for a price for the route and establish what percentage each of us get for a connecting passenger. I.e., if the total route ticket is $250 each way, I can ask for $50 and he can ask for $200, or whatever.

[woollarah]

Any News on the connecting Traffic? As connecting Traffic is Not considered the Pax demand Shown  on Routes like dxb to mru or Sez for Example Clearly do Not reflect the Real passenger demand. We all know that  in Real Life the  based Airline there is operating Several B777 and  A340 per Day on These Routes Most of them with very High Load Factors. The Game presently Sees not much demand on Routes like this and i guess  that is because  of the missing number of Transit Pax. Thanks for the Update Info on this Feature.

[swiftus27]

Any News on the connecting Traffic? As connecting Traffic is Not considered the Pax demand Shown  on Routes like dxb to mru or Sez for Example Clearly do Not reflect the Real passenger demand. We all know that  in Real Life the  based Airline there is operating Several B777 and  A340 per Day on These Routes Most of them with very High Load Factors. The Game presently Sees not much demand on Routes like this and i guess  that is because  of the missing number of Transit Pax. Thanks for the Update Info on this Feature.

Read city based planning

[woollarah]

Have you got a link? Cannot Really find an answer on my Question there. Thanks

[swiftus27]

um... how hard did you look?

[Zombie Slayer]

Like