Needless to say, week 30 was all about the roll-out of “return traffic distribution” to Paine. Interestingly, one of my main concerns with this release was about performance. But this turned out to be no problem at all (which might be due to Paine’s relatively small dataset compared to, say, Idlewild). Instead, I clearly underestimated the impact the changes would have on existing airlines built around the assumptions of the previous system.
I don’t want to go into too much detail about this. You can find an in-depth discussion on last week’s devlog if you’re interested. It basically boils down to this: Previously, there was no need to build a network that actually ensures return connections. So many airlines, even larger ones, didn’t. If traffic distribution requires the plating carrier of both the outbound and the inbound segment to be the same, though, this has substantial consequences.
Paine is an experimental preview server, but I still didn’t feel like lighting all the airlines that exist there on fire at this time 
. So on top of several other adjustments and optimisations I did post-release, I reverted the “same plating carrier” restriction on Saturday morning. Return distribution as such stays active as I still believe it’s a good model, especially as foundation for things to come. Later in week 31 I plan on doing a before-and-after analysis of booking behavior to see where we’re at.
Generally speaking, my take-away from this experiment is that the idea behind return traffic distribution is solid and that it’s in the long-term interest of the game to make it harder and more costly to run a connection-based airline (aka network carrier), but with two caveats:
- I got the order of changes wrong: It should be “tools first, booking behavior changes later”, otherwise it’s too hard for players to deal with the consequences, especially in an existing game world.
- Return traffic distribution without a longer booking window (currently 3 days) is a crutch and the goal should be to arrive at proper return flight bookings as defined on the long-term roadmap.
Concerning the “tools”, I am glad that many of the missing pieces are on my near- to mid-term roadmap already anyway:
- Most importantly: Fares and Fare Rules - these make the choice whether outbound and inbound segments have to be plated by the same carrier an explicit one to me made by the player. They’d also allow much more dynamic price adjustments even after flights have been made available for booking, which is a prerequisite for a longer booking window.
- Similarly, Custom Booking Classes would allow some level of dynamic capacity adjustment after flights have been made available for reservations.
- A new search interface for the DS which allows players to gain more insight into how well their connections work by allowing more filter criteria (like permitted carriers, number/locations of stops etc.) and the option to search for one-way or return connections.
- Auto-ops could support much more dynamic flight assignments (among other things), something that would almost certainly be required with a longer booking window.
- Being able to view the itineraries booked by the passengers would provide valuable insights into where passengers actually come from. The respective item is on the roadmap, but it’s deemed experimental, because it would generate a lot of data to be managed and being able to query it for ad hoc reports on a level higher than a single flight or itinerary would likely require some proper R&D.
- Codeshare Agreements or even Capacity Purchasing Agreements could provide more control over who plates a connection and could help with flights of regional subsidiaries causing connections to not be counted as “direct” (because mainline and regional subsidiary are technically two different companies).
Generally, all the features in the Distribution section of the roadmap would play into this, plus some more that aren’t on there yet (like a different revenue accounting model so players don’t have to wait for two weeks for their revenue to come in when a flight finally takes off, more powerful controlling features etc.), but the above are likely the most important ones.
But working on the underlying model also drove home the need for required work under the hood of traffic distribution:
- As discussed, for proper return flight bookings, a longer booking window is desperately needed. The current 3 days make it hard to make long-range connections work. And simulation-wise, it leaves not enough room to implement very interesting and imo important aspects like minimum/maximum stay constraints, preferred days of travel and so on.
- The weird way in which airports are the source of demand in AirlineSim and how they are connected in ground networks caused me several head-aches during the implementation of return traffic distribution. I look forward to the day that location-based demand becomes production-ready, which is just a much cleaner and more versatile approach.
- On the note of ground networks: Before the roll-out, I had to implement a last-minute fix to ensure ground networks are symmetric, otherwise they would break return bookings. The resulting solution is a stop-gap at best and a proper data-driven approach is long overdue.
- With outbound and inbound segments of a booking request now booked in a single go, the booking requests could be generated on the fly (ASTD-style) whenever demand for an airport is distributed. This would provide a bit more variance, as the set of smaller destinations in particular wouldn’t be the same every day.
- While I don’t think pax traffic should have a lot of (long-term) imbalances (as in: many one-way booking requests) the situation should likely look very differently for cargo, where imbalances are likely the norm. Something to look into for a more realistic cargo model the latest.
- Last but not least and on a far higher level: The discussions reminded me of just how much the (air) travel landscape has changed over the past few decades and thereby the lifespan of this project. So much so, that I think that some of these aspects should at some point be modelled for proper historic game worlds…like the rise of direct booking via the internet and the slow and steady decline in the importance of Global Distribution Systems and other legacy Distribution Channels as well as the changing preferences of passengers.
But enough of me brain-dumping…back to work on a good old boring maintenance patch before summer break 