First thing I have to say that it is a brilliant plan. It may not be instantly responsive - as in instantly responsive to guy at the other airport going into a C check, instantly shifting demand to another airport - but responsive enough to the normal scheduling of flights. And the potential slowness (speed) of responsiveness will eventually depend on the performance on real data, and that is something that would be extremely hard to determine now. But if the world can be updated once per month, that could serve as a minimum.
- Then the system figures, bit by bit (one longitude at a time for sake of CPU/mem usage) potential passenger demand between each square from that longitude to any other squares around the globe. Done using the variables assigned for each square, and country relations data, and country GDP, and other such factors. Result is passengers per day (/month, whatever) between each square (or 0 if not possible/no demand). Demand is allocated between four travel types: leisure travel, business (= not business class, but business related travel), premium (= high-paying business or holiday travel etc.) and cargo. This all is of course the trickiest part, in order to tune the calculations so that the results actually make sense compared to reality.
Sounds good. But I guess this is not really a "step" (since the data is not being stored anywhere), just a description of a concept / algorithm of how it will be done.
- Once the square-to-square demand for each square from the given longitude is done, system will then make this into airport-to-airport data that will be saved. (square to square data cannot be saved since there would be ~100-250million data entries; airport to airport gives a manageable number of results.) System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative.. some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.
I think it might be useful to store the info that is static, as in aiprort - square table, something like:
So that it would be quick lookup to go from square to airports (where square is within its catchment area) and squares belonging to an airport (within its catchment area). This would be done one time before the game start, or when something about an airport changes.
The initial allocation of square to square demand to airports within origin's square while no-one is flying seems straight forward conceptually. I think the tricky part will be to figure out how to update and what has already been updated.
Let me give you an example. Suppose this process is run for the first time for all squares to prepare the game world. Suppose we calculate the demand for JFK-LHR route. This demand (or more precisely, the 4 components of the demand) are an aggregation of square to square demand between these 2 airports, store as a scalar (one per each of 4 demand categories), without knowing how much each square contributed. Let's call it old aggregated value.
Now we are going to update, and we are updating LHR square 1 to JFK squre 1. We figure out the new value, but how do we update the aggregate figure of JFK-LHR if we don't know the the old one? If we knew the old, it would be simple as: aggregate - Old_LHR_Sq_1_to JFK_Sq_1 + New_LHR_Sq_1_to JFK_Sq_1.
So the updates would have to performed on route basis, route being JFK-LHR. So let's say we are doing JFK-LHR route, we zero the 4 components, and then process the set of combinations of JFK squres to LHR squares. Anyway, you may have planning on doing it this way all along...
The concept of quality of connection affecting demand is great. I guess where it fits within steps is in the square to square demand calculation. So we might have this set of possible contenders for one of NYC and one of London squares (probably the worst case scenario):
(total 15, could be more if we the squre is within range of smaller airports such as ISP, HPN)
So to figure out JFK-LHR demand for the square, we need to figure out what fraction of the set of possible direct routes our JFK-LHR route is. If there is no connection of, say LGA-LCA, it should be possible to make that a zero.
Now, this is the worst case, but if we include the routes with 1 stop, the set will defnitely grow substantially
- The above demand figures are updated once or twice a game month for each airport with a rolling background calculation (or instantly in case of any events, or airport data changes). This is a tradeoff between balancing the calculation CPU usage, data storage size and playability. This way everything is calculated only at background, data storage is still within reasons and any changes in the demand will be gradual to players (= if a player enters to another airport overlapping your airport, the demand will shift to that airport over time, if he is "much better" than you.. or other way around). My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.
- Actual pax demand distribution is then another module, that checks the apt-to-apt demand figure and uses it as a baseline for the distribution of passengers. For first test version we could actually even use the present demand allocation module, and then move to next version that can handle connections etc. (demand storage in this format poses on problems to it)
- Also some thought must be given on how the data is displayed to players. We naturally will keep the airport to airport style route planning search still, but if there are many airports overlapping some demand, how would that be shown so that it is clear. ("demand from X to Y is 500 pax, but it includes 200 pax that can be flown from Z to Y" .. ?!?)
..This is just the rough baseline, but comment if you wish. Posting it here just in case someone figures something essential or an idea on how to do it smarter (my brains are overheated ....)
As far as representing the demand graphically, for JFK-LHR route, there are a lot of values that can be shown, that may need to be considered:
- local demand allocated to this airport: what we are calculating
- base local demand: demand between JFK-LHR absent of any flights, where the square demand is split just based on distance of squares to airports
- maximum potential local demand: if all passengers of all JFK squares to all LHR squares use JFK-LHR route
- potential pax from connecting flights (might be too difficult to figure out, and would be huge potentially), so we may just as well skip it.
(each one of these would have the 4 components).
- actual number of local passengers flown on average for last week
- actual pax from connected flights
- total actual pax: total of actual local + actual connecting
Supply is another story, and how to show it.
- direct route supply: sum of flights on JFK-LHR - easy enough to figure out
- neighboring airport direct route supply: Looking at all of JFK squares, what other airports could JFK squares be served by? We get one set for JFK, another set for LHR, so we sum the supply of all combinations (minus JFK-LHR). Still straight forward, but we are back to a lot of calculations just to show the demand screen
- connecting, 1 stop supply: yet another set of flights.
Of all of these, some may be too difficult to implement. Differences in values may be too great that we may need to use logarithmic scale (if the graphing software supports it). Monday - Sunday demand display may have to be discarded if some of this other useful data is going to be shown.
I will try to think of ways to display it in next few days....