City based demand

[Maarten Otto]

I like it...

But don't forget a lot of larger airports function as a hub to an entire country. EHAM for example is the main airport for the Netherlands and I know a lot of Belgium residents find it easy to use Amsterdam as well.

[forsberc]

I like it...

But don't forget a lot of larger airports function as a hub to an entire country. EHAM for example is the main airport for the Netherlands and I know a lot of Belgium residents find it easy to use Amsterdam as well.

That might be too complicated for the first version.  Though with what I was saying, the countries in the Schengen area will (assuming it exists in the game year) create no borders between Belgium and Amsterdam, thus it is merely a factor of distance between the 2 airports. On that same note though, the base distance (from which to base the multiplier) could be manual set to be higher for the European airports due to increased infrastructure- high speed rail notably. These base distances could be manually set per geographic area prior to the game starting- each tailored to each geographic needs. Greater distances in Europe for example.

[Glob-Al]

I've only just started playing but this all looks really exciting - even if it's a way in the future.

I think the small squares approach is about as good as you'll get. With all the players from different countries that there appear to be on here I'm sure you could find a team of researchers to help out with the data for various parts of the world as well if needs be.

[Maarten Otto]

I think the larger squares will do the job to find out how things work.

Don't forget The amount of work needs to be tested. So you better do large squares of one continent (Europe) first to see it it works out well. Then you can adjust it to get better results. Finally when all is working properly, you can decide to take the whole thing one more time into the next level of detail.

I think this feature should be implemented in phases so people can get used to it and Sami can work on it without time pressure.

Therefore I suggest the following roll-out:

- Europe in large squares, and test by all players in a Euro Challenge scenario.
- Europe in Smaller squares. Fully tested in a next Euro Challenge.
- Northern America smaller squares.  Fully tested in a North America Challenge.
- Northern America and Europe together in a trans-Atlantic game world.
- Finally Implement Asia and Oceania as well.

[forsberc]

I think Maarten Otto is on the right track, but why not consolidate that release schedule into this:

European Challenge: Larger Squares- merely to see if it will work. Game time 5 years or something small.
Trans-Atlantic Game: Larger Squares- Full game style. Long term testing.
Whole World: Larger Squares- Final Prototype
Whole World: Smaller Squares- The End result.

The first three would be game engine 1.3 (I would guess) and the last would be 1.4. 1.4 could then be developed in 9 months-1.5 years as the game worlds were testing the larger squares. I think less releases would take less time and the lessons learned through the Larger Square games could then be applied in full to the final release.

[meiru]

just to mention this... if you have a game from the fities into our time, then the amounts of flights that are offered from one airport would have to influence how it is improved over time... so, this would have to be modeled as well... and this is getting even more complex... maybe even not possible to simulate... or would you also simulate the politics and how easy/hard it is to develop airports in different countries? ... e.g. in Switzerland... try to build a new runway... you'll get into troubles for decades
so I wouldn't make it that complex and simply link some airports together (KJFK, KLGA, KEWR for example) ... oh, and by the way... a lot of the demand from KATL for example are transit passengers... how to model that? 

[JumboShrimp]

just to mention this... if you have a game from the fities into our time, then the amounts of flights that are offered from one airport would have to influence how it is improved over time... so, this would have to be modeled as well... and this is getting even more complex... maybe even not possible to simulate... or would you also simulate the politics and how easy/hard it is to develop airports in different countries? ... e.g. in Switzerland... try to build a new runway... you'll get into troubles for decades
so I wouldn't make it that complex and simply link some airports together (KJFK, KLGA, KEWR for example) ... oh, and by the way... a lot of the demand from KATL for example are transit passengers... how to model that? 

That would be a nice extra feature - which is - development of cities (their growth rates) coould depend not only on their country population and GDP growth, but also on how well their demand is being served (by all airlines serving that city).

[Sigma]

That would be a nice extra feature - which is - development of cities (their growth rates) coould depend not only on their country population and GDP growth, but also on how well their demand is being served (by all airlines serving that city).

I think he was talking about airport improvement, not city improvement (though that'd be pretty cool too I suppose).  That's something I talked about either early in this thread or in one of the other ones that were discussed a year or so ago.

If airports are in AWS what airports are in reality, then we once again end up with a world that does little but recreate the same routes we have in the real world simply because we're recreating the infrastructure and that infrastructure is necessary.  Atlanta, for example, would continue to be a mammoth airport simply because it's runways/capacity allow it to be a major player.  But, in real-life, if not for the fact that Delta had chose for it to be its hub, there's no reason why Atlanta would have become a fraction of the airport that it has become.  Its airport would have instead been like most every major city airport in the southeast US.  It could have just as easily chosen Birmingham or Charlotte.

There needs to be a system that creates additional capacities (within some bounds) as demand requires it.  But that becomes very tricky.  People would then complain that Dallas Love has international routes. Or complain when London City is the biggest airport in Europe.  Up to sami whether he wants to go down that road or not, or even go down the infinitely more complicated road of trying to establish limitations on what certain airports can and cannot do within AWS.

[JumboShrimp]

If airports are in AWS what airports are in reality, then we once again end up with a world that does little but recreate the same routes we have in the real world simply because we're recreating the infrastructure and that infrastructure is necessary.  Atlanta, for example, would continue to be a mammoth airport simply because it's runways/capacity allow it to be a major player.  But, in real-life, if not for the fact that Delta had chose for it to be its hub, there's no reason why Atlanta would have become a fraction of the airport that it has become.  Its airport would have instead been like most every major city airport in the southeast US.  It could have just as easily chosen Birmingham or Charlotte.

I am all for adjustment to demand to reflect only regional demand, and then, players will be able to write their own history by locations of their hubs.  Passenger traffic between AB pairs will depend as much (or more so) on connecting traffic as the the local demand.  Then, Charlotte can indeed become the busiest airport.

There needs to be a system that creates additional capacities (within some bounds) as demand requires it.  But that becomes very tricky.  People would then complain that Dallas Love has international routes. Or complain when London City is the biggest airport in Europe.  Up to sami whether he wants to go down that road or not, or even go down the infinitely more complicated road of trying to establish limitations on what certain airports can and cannot do within AWS.

I think that a feature to grow capacities of airports (slots) based on player demand for slots could probably go into version 1.3, rather than wait for huge overhaul of demand and connecting traffic capability.  This feature is, IMO, small in scope and completely independent of demand / connecting trafic project.

It would enhance playability and it would start an effort to change the game world from striclty fixed and copying history / decisions of real world airlines to history written by players of the game scenarios.

BTW, I am playing ATB, and DTW has this incredible demand to AMS.  No real reason for it, other than decision of NWA and KLM to cooperate...  In the AWS, it should be based on how the AWS airlines operate...

The starting point of any scenario should correspont to the real world of that era (as far as sizes of airports, runways, slots), but from that point, the airports should develop on their own, based on player demand for slots.

That growth (of slots) could either be automatic (system would grow slots when they are running low) or player initiated (and paid for).

As far as DAL having international flights, I would not complain, but Sami probably already has an "international" flag for airports, and if he does not, it could be added.  But that's an extremely low priority item IMO.

[samomuransky]

A) Have border crossings reduce demand by 50%. This is because of customs and the lack of will of the traveller to change countries unnecessarily.

This is not realistic everywhere, especially in Europe (there are no customs for individuals when travelling between EU members /with some exceptions/ and no immigration inspections between Schengen Area members)... Second sentence is not really true for most of the world.

[samomuransky]

Generally I like the idea of squares, but I believe that flight connection feature should be completed first, otherwise it won't work properly...

[JumboShrimp]

Generally I like the idea of squares, but I believe that flight connection feature should be completed first, otherwise it won't work properly...

Well, the 2 go hand in hand, but if it is going to take a year or more to get the city based demand done correctly but only, say 3 to 6 months for the connection feature, I would opt for connection feature first, with current less than perfect demand distribution.  Basically, bypassing the squares / city based demand to get the connection feature done ASAP.

[Seattle]

I feel that connections will be just as complicated... especially for players.

Anyway, city based demand opens up many more possibilities in the game, especially when it comes to allowing people greater choices in basing.

[swiftus27]

So, for instance there will possibly be many airports that can fly from a to b if they are in the same box.  This will change the dynamics around MANY cities.  For example, flying out of BWI internationally versus out of Dulles.

Also, I feel that this should never be incorporated before we implement some controls first (for instance, flying larger a/c out of London City).  

[Seattle]

Swiftus.... those controls are already in place! Sure, you can fly an A319 into LCY, but see how many passengers it holds.

[swiftus27]

Sami the Benevolent finally changed it? 

That's a great thing to hear!!!

I am more for authenticity than I am for fun.  I'd love to see this stuff.

However, I should be able to fly internationally from Reagan instead of Dulles in a City Based Demand model.  That will be interesting. 

[Seattle]

Except that there is the Perimeter rule, so you cant fly more than 2500 miles, exculding SEA and LAX. So Canada, Mexico, and the carribean would be fine, but transatlantic is more doubtful.

[JumboShrimp]

I feel that connections will be just as complicated... especially for players.

Well, it would make for a much deeper simulation, and it would introduce something sorely lacking (IMO) - competition between players.  The competition is very limited, as is.  Ok, there may be more than one player starting from the same base, as you, but eventually (with exception of slot limited airports), one player will become dominant, and from that point on, we are pretty much playing solitaire.

The bases added some competition, but with the 70 plane limit, you can't really challenge a larger player at his home turf.  You can challenge a smaller player at a second tier city, and that's about it.

The current demand system is based on existing hubs.  Meaning that if a guy is flying from Buffalo, NY to, LHR via JFK, he is built into the LAX LHR demand.  If there is a dominant player at LHR (and of course there are no slots), and a dominant player at JFK, no-one can compete for this passenger, and the demand is misplaced anyway, because it is represented as JFK-LHR demand, rather than BUF-LHR demand.

With the connection feature, anybody (or their team-mate) who happens to fly to BUF and LHR can compete for this passenger's business, not just JFK and LHR incumbents.  So there would be a lot of indirect competition.

Anyway, city based demand opens up many more possibilities in the game, especially when it comes to allowing people greater choices in basing.

I guess there may be many interpretations of what a city based demand really is. It can be:

1. just a way to figure out inherent airport (demand originating from airport's surrounding ares, not from connecting flights).  This would be my preference to get things off the ground quicker.  Under this scenario, each airport would be allocated some demand based on the population surrounding the airport.  For example, JFK would get some allocated, as well as LGA and EWR.  The ratio would stay constant throughout the game.  All the action would be in building connecting flights.

2. City would have a certain demand, and airports serving the same city can steal traffic from each other from overlapping areas.  Demand would really be tracked not on airport to airport bases (2755 of them) but on the land squares, some 40,000 of them, and even those square were too big according to some.  So multiply 40,000 x 4 if you want each square to really be divided into 4 sub-squares.

And what does it buy for us?  Not a whole lot, because of the 6,000 pax demand between JFK and LHR (in current ATB), maybe 2,000 live withing the squares of JFK and LHR, and the remaining 4000 are transferring from places such as Buffalo, New York, Scranton Pennsylvania, Glasgow, Scottland.

IMO, multiple airports with overlapping coverage is just an ugliness of the real world that threatens to bog down the beauty of the simulation that Sami is building, with little to no improvements to playability.

As far as flexibility in player basing, we are talking about a handful of cities with these "issues" needing flexibility.  But the LHR problem would be greatly diminished.  If you take current AWS demand allocated to LHR, in the new version of demand (whatever it turns out to be)  LHR demand will be cut down to probably no more than 25% of its current demand.  The demand will be distributed throughout the other UK and continental airports that LHR is serving (connecting).  And suddenly, LHR slot problem disappears.  It is no longer crucial to be based at LHR, to have slots at LHR, since the action is in the connecting flights, and the hub connecting these flights can be anywhere.

[Sami]

I've worked on this feature a bit too .. The population data globally is almost complete now. But this feature will eventually require a huge deal of manual work.

So far I know roughly the borders of countries, location of cities and their populations (and historical populations). In other words the information where people live has been now established, and also it has been distributed into the 'square model' I talked earlier (the model will not consider individual cities, but assigns each city into square and each airport will access the population data of the nearby squares to determine the demand).

But I know nothing about what happens in each city (or "square area"..); in other words is the city a famous tourist location, central of large business life .. etc. This data needs to be manually inserted for each country and is a big task, and will require community help eventually.

But for now I will continue to make small-scale experiments on how to proceed further. But the first step towards this feature (= base data) is almost done, the next step (= detailed data) and further steps (= forming the demand demand & airports accessing them) are much more complicated than this mere data collection.


(edit: there are some 50 000 'squares' in the world, but according to present data about 9000 of them have some sort of city or village. But seems that the data still has gaps in rural areas.)

[Shubinine]

What about we do the city demand like a sum of the demands by all the airports serving that city, and make it grow according to historical passengers of both airports?

For example, Bucharest has 2 airports, Baneasa(mainly low-cost) and Otopeni.

Bucharest's total demand would look like this:

Year       Baneasa       Otopeni       Total

2005      385,759      3,031,719    3,417,478

2006      673,000      3,513,576    4,186,576

2007      970,000      4,978,587    5,948,587

2008     1,768,000    5,064,230    6,832,230

2009     2,005,694    4,483,661    6,489,355

I'm not saying that you should make it look like the exact numbers, but like make it a sum of the airports serving that city, and when you plan the route to have like a drop-down box where you select at which airport you wanna make that route to... This way we can implement the"profitable" low cost airline aswell