Started by edidiot, January 05, 2009, 01:48:19 PM
Quote from: JumboShrimp on March 27, 2012, 07:43:14 PMI was wondering if it would bot be possible to have "suggested values" for squares pre-filled.
Quote from: sami on March 27, 2012, 10:20:16 PMNot really since if we have a country with industry, then certainly not all squares have industry in them etc. The whole idea of the squares is to override the general "mass" calculated by GDP and other factors, to pinpoint the demand into the certain cities and areas that have the major action places.
Quote from: sami on March 28, 2012, 10:18:03 PM- 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.
Quote from: sami on March 28, 2012, 10:18:03 PM- 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.
Quote from: sami on March 28, 2012, 10:18:03 PM- 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 ....)
Quote from: JumboShrimp on March 29, 2012, 01:29:05 AMVariable catchment area:It may be useful to have a variable catchment area. This could be independent of airport "size" as it is currently defined in the system. It could depend strictly on number of passengers flown. The system could have a simple function of:Catchment radius = Function of (Passengers flown from the airport).The system could have a minimum of say 50km as a base, and every airport would start with that. Than, as the airport grows (as far as passengers served), the radius could grow to potentially to 200km or even 300 km for the busiest airport (not sure if the picture around Helsinki is radius of 200km or diameter. This way, with radius of airports with very low number of passengers would stay very small, the system will not be wasting too much time calculating square to square demand of squares that may never really end up being connected by supply.And since this would be a very simple calculation for the catchment area radius (and the table of AirportIDs to SquareIDs) it could be updated as part of every round of updates.It might be useful for playability as well. The system would not start with astronomical demand and no supply. The demand would build up as the catchment area grows, as more passengers is brought in through connecting flights, and as the catchment areas grow, there would be more overlap, and more indirect competition as the game progresses.It would be a great way to make the game world more dynamic. Also, with airport growth, there could be some way to grow slots as well, to make that area dynamic as well. The game could start with number of slots that is lower than current start, and then grow with number of either pax or take offs and landings.
Quote from: sami on March 28, 2012, 10:18:03 PMSystem 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.
Quote from: sami on March 28, 2012, 10:18:03 PMMy 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.
Quote from: Riger on March 29, 2012, 02:10:41 AMThis sounds/feels like a pretty good way to make the game more dynamic/variable. It might be worth considering "letting go" of the logical geographical (country) restrictions (people will not come overseas from Estonia to Helsinki!) because while this may not represent reality, it will add another dynamic factor and will probably make for easier algorithms for the code.If nothing else, this would certainly be a good starting point for at least 1 game world as a test.RegardsRichard
Quote from: alexgv1 on March 29, 2012, 04:22:42 PMThis would be strenuous as it would have to have a route made for each airport to fly to through connections (but no more work than making a non-stop route). Of course at first it is limited to your own bases as a first stage to keep calculations simple, but eventually it can be expanded to alliance bases and regional flights to feed long haul flights from non bases. Just an idea, please let me know your thoughts.
Quote from: sami on March 29, 2012, 07:13:04 PMWhen you create a route the system will show you all potential connections within your network, automatically. You can tick and choose the ones you wish to sell tickets to (default = all), and adjust prices if you wish. (or later)
Quote from: sami on March 29, 2012, 07:13:04 PMSimple.For pax calc each connection shows like a regular flight, having extra stop.Connection thresholds would be for example, only one stop (2 consecutive flights max) and connection leaving no earlier than 60mins from arrival and no later than 4 hours. Would prefer to keep these as fixed values.Actual flight data stats/info will be shown like they are today, with perhaps added by data of amount of connecting pax share, or smilar. But still very simple too.