As you know, AirlineSim 6.2 has introduced Speed Overrides and Departure Offsets. Their primary purpose is to allow for easier scheduling of regular flights at slot-congested airports and to permit easier up- or downgrades of aircraft types without changing the schedule. But there’s an obvious problem with this: Although flight times can remain unchanged now, turnaround times are still a big issue with the current absolute planning model. If the changed turnaround times overlap with other items on the flight plan, the plan cannot be executed. Even if it’s just a minute of overlap. But there’s a solution to this problem: Dynamic Turnaround Times and Delays.
The current model: Static Turnaround Times
Currently, turnaround times in AirlineSim are taken from a simple matrix that holds a static time value for each combination of aircraft and airport size in the game. This is an easy solution, but makes no sense at all: Just imagine the (slightly constructed) example of one Boeing 747 configured at maximum capacity of 660 passengers and another one as a VIP aircraft with only 10 seats. Both aircraft would have exactly the same turnaround time because the size of the aircraft is the same in both cases.
A similar, more important issue with this static model is the fact that similar aircraft types might fall into different size categories. So even though type B only allows for 20 additional seats compared to type A, the turnaround time might differ by half an hour. This means that you cannot simply switch type A to type B because it would most likely mess up your schedule.
Last but not least, the turnaround is an important part of what makes the difference between a „Ryanair“ and a „Lufthansa“: The amount of baggage to load, the kind of cleaning and catering to be done, the number of doors used for boarding or the seat density on the plane all determine how long the turnaround will take and what kind of utilization you can achieve. Neither of these things is currently modeled in AirlineSim.
The new model: Dynamic Turnaround Times
Our new model for turnaround times changes this: Every turnaround will be a sequence of interdependent activities. Each of these activities has a duration that is influenced by the conditions under which the involved flights take place. The total duration of a turnaround will be determined by the so-called critical path: The sequence of successive activities that takes the longest to complete (the activities marked in orange in the picture below).
This means several things:
- Differences between aircraft types are now secondary. What matters are the actual seating or cargo capacity of an aircraft. Upgrading to a slightly larger model will not cause the massiv differences you’d see today.
- It provides an almost unlimited amount of ways to influence the duration of each and every turnaround activity. For example, instead of using a gate with jetways you might decide to use a remote stand, allowing you to use two doors for boarding and de-boarding instead of one. You could decide to never accept cargo on your flights so you don’t have to worry about this step during turnaround. Similarly, granting your passengers less checked baggage reduces the amount of bags that need to be hauled into and out of the cargo hold, again shortening the respective turnaround activity.
- It allows the game worlds to become more dynamic: When an airport grows over time or becomes more congested, certain activities might take longer than they used to. Want short taxi times? Better don’t use a large international airport!
Why delays?
So what have delays to do with all this? As mentioned before, one of the primary goals of the variable turnaround times is to allow for more flexible flight planning. But even though turnaround times make a lot more sense now, overlaps can of course still happen. So instead of simply marking a flight plan with overlaps as „inoperable“, the flights will be booked into the ORS as scheduled.
Once the flights are operated, the actual turnaround time required between the flight to take off and the previous flight is calculated. This turnaround time will take into account the actual conditions at the time. If the load factor of a flight is only 70%, chances are that boarding will be completed faster than planned. If the previous flight happened to arrive a few minutes earlier, this gives you some buffer to compensate random delays during turnaround or a short time window.
But obviously, it can also go the other way: Due to random factors, flight times or turnaround activities might take longer than initially planned. If you did not leave any buffers in your flight plan or even accepted overlaps, your aircraft will probably accumulate delays over the day. Depending on their severity, these delays will cause monetary and image penalties and might even lead to flight cancellations at some point, for example when maximum delay times are exceeded. Besides being quite realistic, this should prevent the misuse of the more flexible turnaround system. If you don’t leave any buffers or deliberately cause overlaps in your flight plans to reach maximum utilizations, delays will come and get you. If you plan ahead or only accept minimal overlaps due to a changing environment, you’ll probably be fine. In the newly adjusted flight plan view, overlaps will be indicated by respective markers (see picture).
Note that one of our design goals is that delays will not require micro-management of your airline. Think of it this way: As the manager of an airline, you have certain tools at hand to influence the probability of delays, but your „operations“ will deal with them once they happen. In case of cancellations, automatic transfer flights will ensure that aircraft don’t get stuck.
Our roadmap for AS 6.3
As you might have guessed, AirlineSim 6.3 will be mostly comprised of the two features described above. We have most of the core functionality implemented and are currently working on the basic definitions for the various turnaround activities. Once that’s done, we will commence internal testing which will probably involve several iterations of adjustments and take a couple of weeks. Once we feel the feature is ready to launch, we’ll start a new game world in which the new features will be enabled from the start.
Note that the means of influencing the activities will be rather limited initially. Those will be added over time and as part of reworks of other features.
Will this feature destroy existing airlines?
In case you’ve been worried about the effects of this update on existing game worlds: All legacy game worlds will be patched with the new version, but all turnarounds will consist of a single dummy activity which simply uses the static turnaround times in use today. Random factors will stay disabled. This way you can only cause delays manually by planning overlaps in your flight plans but you will never be confronted with automatic changes, for example after installing a different cabin layout or changing catering options. At a later point, when the new system has matured, we might decide to introduce it in old game worlds. But that’s something we’ll decide when the time comes.