Better demand model - passenger route searching and choice

Started by Bryn, January 15, 2009, 09:41:36 PM

Bryn

In the general chat section, I posted a response to connecting flights, which I think should be a feature in this.  A summary of my suggestion is here:

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 airport and all other airports.  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 - but point to point demand in the game does not allow this.

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 also be exceedingly high (because of the pax finding their way through HIR).  Again, this is not modelled and makes the demand model very simple and unrealistic.

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.

Echoco

i imagine the solution would be pretty complicated.all i see from that is A=B=C flights probably get higher Lf on B=C leg than A=B

- denote one way flight
= denote return flight

Bryn

The solution is pretty simple. The computation may be fairly laborious - but it's just brute.

1. Ascertain a base population of potential travellers between airport a and all other airports (i presume this is, at the moment, just a fairly standard gravity equation)

2. Create vector of possible paths for each airport pair (up to a point... )

3. Assign utilities for each possible path (including a null path - passenger does not travel) such that utility is a function of time, price, airline changes, airline quality, inflight service, etc.

4. Use probability function over passenger population and distribute accordingly.

I think the mistake is to short-cut to what you think the load factors might be rather than creating an open-ended economic environment for gamer decisions to be made in.

Cheers,

Bryn.


Echoco

Quote from: Bryn on January 16, 2009, 04:16:40 AM
The solution is pretty simple. The computation may be fairly laborious - but it's just brute.

1. Ascertain a base population of potential travellers between airport a and all other airports (i presume this is, at the moment, just a fairly standard gravity equation)

2. Create vector of possible paths for each airport pair (up to a point... )

3. Assign utilities for each possible path (including a null path - passenger does not travel) such that utility is a function of time, price, airline changes, airline quality, inflight service, etc.

4. Use probability function over passenger population and distribute accordingly.

I think the mistake is to short-cut to what you think the load factors might be rather than creating an open-ended economic environment for gamer decisions to be made in.

Cheers,

Bryn.



heh 5 years ago when my brain cells were still alive i might have understood that. Are you saying that in a given population there should be assigned percentage of likely destination and use that to calculate which route they'll take? thats what I was thinking of but sounds too CPU intensive

Bryn

I am saying something similar to that. 

For an airport, there is a demand value for travel to every other airport (I think this already exists).

What is needed is a search for flights to get to those other airports.  Then the demand is dispersed across the routes based on factors like time, cost, quality, and so forth.

The null options is a no-travel option, so in some instances, travellers will have greater utility actually not travelling than travelling, mostly because of the time and cost.

If the demand model is moved to this level, airlines can then cooperate overtly or incidentally and many many more possibilities are opened up.  It becomes far more realistic.

It is more computationally intensive, but that's what those cycles are there for.  It is a global computation that only needs to happen on every game day.

Cheers,

Bryn.


Echoco

ahh yeah thats the same as what i was thinking but i didn't explain it as well as you lol I'd like it to be like that too.

i'd hate to code it though, presumably every 25 minutes there has to be a calculation per originating airport to each destination airport comparing each flights by each airline taking into account the time of day, fight time, ticket price and number of tickets, airline and route image  :o

assuming time zones doesn't come into this lol

CX717

it's a good idea IMO...But I doubt is that feasible?
Every route have to be calculate by the server every time,and it change almost every minutes.
and there is near ten thousand(?) routes in the game.........

Bryn

The computation would only need to be done once every game day (25 minutes).  Also, base demands seem to already exist for every airport pair - it is the search and choice computation that would be added.

I do not think this is all that complicated.  Think about the implications though.  you could then run a feeder airline and feed off the demand flowing through a hub.  Hubs could organically arise in the game, just as they do in real life.  Airline alliances would have much more meaning. and so on and so on.

Air networks are about creating paths for goods and people to flow along.  A fairly simple upgrade to the demand model in this game would improve the simulation dramatically and make this much more interesting and fun.

Cheers,

Bryn

PS. If you really are worried about computation time - this is a massively mutiplayer game, how about breaking new ground and distributing the computations!