Does the game account for connecting traffic? Would developing a regional feed benefit traffic to larger markets via hub connections?
not yet.
I think part of the problem with that is it makes big airlines even more powerful and makes it harder for the little guys.
Have to see what Sami thinks though.
not really
more player will willing to run a "small" airlines if there is connecting pax.
they can form a partnership(not alliance,kinda like subsidiary) with the "big" airlines,and feed their route,while the big one feed yours.
I usually not operate the route that less than 50 pax per day,I'm busy enough to manage my existed network.That left some space for the small airlines to run.
Once connecting pax available,it will brought airwaysim realism to a higher level!
I wake up this morning thinking: WE NEED SUBSIDIARIES. I need to create regional airlines to my BIG DADDY airline. I NEED IT!
If connecting traffic does not play a part in the loads/profit/sucess of a carrier, why is Atlanta such a big market in 1985? I would think in that time frame markets like DTW, PIT, ect would have greater amount of traffic? Also doesn't this lack of connections also limit the number of markets that can be served?
If an airfield has connecting traffic in real world it has higher demands in the game for point to point passengers. It doesn't matter if there are connecting flights or not.
Higher point to point demands is fairly unsophisticated. Ideally, the game would use a search function to work out available routings for passenger demands between one city and all other cities. Passenger choice would be a function of price, time, stopovers, airline changes enroute, comfort, service, and so forth.
Airlines would then compete more dynamically and hubs would naturally arise. The interplay between airlines would also become much more interesting if this was modelled.
Using a simple increase in point to point demand does not enable that sort of dynamic competition.
An example: if I am an airline based in Honiara, and I offer services to Brisbane and Los Angeles, and I am the only airline flying all the way across the pacific, then my demands should be exceedingly high - not just the point to point demands between Honiara and Brisbane and Honiara and LA.
Another example, if I only serve Honiara - Brisbane, but someone elses serves LA Brisbane, and there are no other flights across the pacific, my demand on Honiara - Brisbane should be exceedingly high.
The absence of this dynamic makes the game very one dimensional and a poor reflection of how airline markets actually work (particularly the demand side). I hope this more realistic choice model that I have discussed is included in future versions.
Bryn.
I agree with CLR2LND. Connection traffic would be vital and important factor to the game if possible. Without factoring in connections, it would be advantageous for everyone to fly widebodies everywhere because of the lower CASM. Also, if connections are not a factor in generating traffic, the advantage of creating an alliance would be very limited. (i.e. in real life, without alliance connections, LH would not be sending large heavies like 340s into smaller secondary markets such as DEN and CLT)
I think accounting for connections and frequencies would create a more realistic scenario where planning and routing of your aircraft takes more strategy. Instead of a rolling hub type operation, you may want to create several banks of arrivals and departures.
Quote from: Bryn on January 15, 2009, 12:58:01 PM
Higher point to point demands is fairly unsophisticated. Ideally, the game would use a search function to work out available routings for passenger demands between one city and all other cities. Passenger choice would be a function of price, time, stopovers, airline changes enroute, comfort, service, and so forth.
I totally agree with you, a game like that would be perfect. However, with a couple of hundred airlines and all the airports in the game, I don't think any server could cope with the huge amount of calculations comparing all possible routings, even if considering only direct flights and flights connecting through just one airport. Are there any other online airline management games that actually do this? (Sorry if mentioning other games is forbidden...)
It may not be feasible to actually calculate all the possible connections, but there should be a way where extra credit for load factors can be given to/from your hub and to/from your alliances' airport. In reality, feed and connecting traffic is so important to revenue, some flights operate solely for connecting passengers alone.
maybe the game can calculate arriving passengers for a certain period 3-4 hours or so as potential connecting passengers? there are some markets which are only interesting to serve because of connecting possibilities. I thought connections are somehow calculated into the demand... So I better reroute some of my aircrafts. ???
Instead of trying to calculate all possible connections, why not calculate available connections? For example, I offer a flight that is KCMH-KSTL-KMCO. There is demand on the KCMH-KCMO route, so instead of assuming that all passengers get off at KSTL, could the program calculate/divert part of the KCMH-KMCO demand onto the longer route? I know that with technical stops this occurs, but why not extend that to routes with stops? For example, IRL, Southwest operates from Columbus to Las Vegas via STL or MDW + PHX.
I guess the logic I'm thinking of is, instead of calculating every way a passenger can get from A to B, see what one-hop or two-hop routes are possible. This would make airports like KCMH much more profitable, as you're kind of locked into the 'big' routes right now. Flying KCMH-KSTL-KMCO would help boost numbers on the KCMH-KSTL route AND satisfy demand on the KCMH-KMCO route. The current situation is a 50% LF on KCMH-KSTL and the need for a separate direct KCMH-KMCO route. I'm sure there's plenty of other examples out there, but this is just one.
Thinking about it a bit more, I don't think my idea really pertains as much to 'Connections' in the traditional sense, but pass-through passengers. In the route screen, there's an option for 'Refuel only at this airport - do not take new passengers' - why not have an option 'take on new passengers, but don't kick the old ones off'? Or something similar, to allow people to stay on the plane to its eventual destination for the route.
Simple agree with you all and think it is a fundamental and necessary issue, bringing the game to a higher level.
Sure gonna need a very powerful server to do all the calculation job. :-\ Suggest to implement a system where connecting flights, on indoor or on alliance basis could be manually arranged. This may create more realism, strategy and if possible interaction between players. Avoiding for the big guys to become even bigger would make sense since this proposal goes into the direction of giving HUBS a larger operational role.
Other comments?
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)
I don't think it is an easy task when condering to make connecting traffic closer to real life.
For example, assumed i offer a route: LAX-ORD-JFK
If the system considering the factor of connecting traffic, what should I charge a passenger if his or her distination is JFK.
Should I only charge the price of direct flight LAX-JFK($334) or charge LAX-ORD($251) and ORD-JFK($180)?
If the system uses the first pricing method, what will be the reference price if I don't have a direct flight?
If the system uses the second one, there will no connecting traffic due to the higher total cost when the total cost acts as a factor.
Second, if other airlines offer ORD-JFK about the same time as mine, how the system to allocate traffic when they offer a very low price on ORD-JFK route? Will some pessangers change to other airlines due to lower cost?
Third, does the system have to consider LAX-DEN-JFK, LAX-ATL-JFK...... and so many other possibilities? If no, then to calculate connecting traffic is meaningless. If yes, how to allocate pessangers to flights on those routes? I also agree with what Kontio mentioned regarding server capacity. It should be a heavy for the server to search all possibilities and then allocate pessengers to different flights.
In other circumstances I have tried to set up calculations like this -- it can hang a computer very quickly.
Using the aforementioned LAX-ORD-JFK route, would demand also take into account the LAX-DFW-JFK route as part of the passenger demand calculation? And the dozen others that are parallel?
I think an easier way to do it would be to fake it by taking into account the number of connecting airports to a particular airport, the size magnitude of each of them (or the pax count) and then add a percentage load increase at that connecting airport (this could be in the range of 1 percent or something) as the number of connected airports grows. This could be combined with the existing functions that increase load over time and the ones that increase load as fares are lowered; it doesn't have to contradict them in any way. In my opinion, this would be a good quick fix until Sami can approach it more thoroughly.
Quote from: Kazari on June 27, 2009, 07:41:54 PM
...I think an easier way to do it would be to fake it by taking into account the number of connecting airports to a particular airport, the size magnitude of each of them (or the pax count) and then add a percentage load increase at that connecting airport (this could be in the range of 1 percent or something) as the number of connected airports grows. ...
everything who are NOT just clicking or automatic increasing of revenues is appreciated. We aren't adding substantial other things to the game in other case lol.
Quote from: Kazari on June 27, 2009, 07:41:54 PM
In other circumstances I have tried to set up calculations like this -- it can hang a computer very quickly.
Using the aforementioned LAX-ORD-JFK route, would demand also take into account the LAX-DFW-JFK route as part of the passenger demand calculation? And the dozen others that are parallel?
I think an easier way to do it would be to fake it by taking into account the number of connecting airports to a particular airport, the size magnitude of each of them (or the pax count) and then add a percentage load increase at that connecting airport (this could be in the range of 1 percent or something) as the number of connected airports grows. This could be combined with the existing functions that increase load over time and the ones that increase load as fares are lowered; it doesn't have to contradict them in any way. In my opinion, this would be a good quick fix until Sami can approach it more thoroughly.
Connecting traffic is already build into pax demands as it's (partly) based on real figures. Right?
Quote from: Powi on June 28, 2009, 06:30:32 PM
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.
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 ;D. 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.
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 :) ).
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.
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).
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.
Quote from: sami on June 27, 2009, 02:39:43 PM
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?
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.
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.
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.
Quote from: woollarah on June 25, 2013, 09:39:17 PM
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
Have you got a link? Cannot Really find an answer on my Question there. Thanks
um... how hard did you look?
Like ;D