I mentioned on this on this week’s devlog:
So I went ahead and started writing up my thoughts on this. Once I was done, I decided I might as well drop it on the forums to see whether anyone has any good comments on this…I am sure I missed some important aspects.
Note that this is an unpolished brain-dump and very much work in progress!
Goals
- Implement the core parts of the new DS: Individual travel requests, booking classes, fares and any feature required to make the three work in a baseline fashion (like interlining)
- Continuous Delivery: Implement this bit by bit without ever breaking the game, feature-flagging new parts if necessary
- Keep old ORS behavior mostly identical so old game worlds do not break
Target Definition: DS search/booking results
No matter whether you are using the old ORS or the new DS: At the end of the day, you (or the booking engine) want to be able to search for connections and receive results in the following structure:
- One or more itineraries
- Fare (plating carrier, fare code, service class and total price)
- Outbound Segment
- Optional ground connection
- One or more legs (origin/destination, flight dates and times, booking class)
- Optional ground connection
- Inbound Segment (future DS only)
- Optional ground connection
- One or more legs (origin/destination, flight dates and times, booking class)
- Optional ground connection
This isn’t too different from what it currently looks like. The key differences are:
- The fare is matched to the whole itinerary. There are no prices per individual leg.
- Legs refer to booking classes, not service classes.
- Future versions of the DS will/might support return itineraries, so there could be an outbound and an inbound segment.
Phase 1: ORS-compatible structure adjustments
Goal: Adjust code and data structures such that the ORS continues to work unchanged but could be replaced with the DS based on configuration alone.
Booking Classes
Likely course of action: Introduce booking classes behind the scenes, with a one-to-one mapping from the current 4 service classes to identical booking classes. UI-wise, little would change as players are not allowed to adjust booking classes in this phase just yet. But behind the scenes, this is likely the single-largest task to complete to get all of this to work.
Fares
Completely new concept as flight prices are currently defined per flight segment and service class. This must not be changed if existing game worlds are supposed to continue functioning without player intervention.
Current idea:
- Behind the scenes, create individual point-to-point fares for each flight segment.
- Each such fare will have a Category 4 (“flight restrictions”) fare rule tying it to a specific flight number.
- During fare matching, create “auto fares” that use the per-leg point-to-point fares to create a simple combined fare that is essentially the same as we have today.
New “plating carrier logic” will already be used when “matching” fares, especially because as a side effect of said logic we can determine the most relevant leg which in turn defines the primary booking class. To stay compatible with current-generation ORS logic, it must be possible to “downgrade” the service class on other legs if no matching capacity is available (classic example: intercontinental flight has first class cabin, but most feeders do not, so business or even eco need to be booked).
EDIT 2024-08-27: At the moment, I think handling this special case would just make things more complex and should be kept for later in case we actually decide to roll out the DS to old game worlds. Then, such a legacy rule might be necessary, but for any world that starts out with the DS, players just need to set up their inventory accordingly (to stick with the example above: define a First Class inventory in a Business Class cabin on a short-haul flight).
Demand Distribution / Travel Request Generation
This will and has to stay mostly the same to keep the booking behavior unchanged in old game worlds. This means: Demand distribution once every day for each airport and bulk distribution per destination. Rating algorithm will remain the same as today (three passenger types + cargo). Any required changes will be purely technical in nature and should remain invisible to players.
Ground Networks
This one is tricky: The DS actually generates requests between so-called “locations”, not airports. But the UI presented to players would only allow searches from and to airports, so ground connections exist during booking, but not in the UI. In the ORS, ground segments are possible between airports and are visible to players. Will likely maintain the current behavior and generate dummy segments and fares for the ground segments.
EDIT 2024-07-04: We could also “fake” locations based on the city of the respective airports and/or actually introduce the location data structure based on a one-time aggregate of the existing airport data (so not the full dataset from DS, but a much smaller one), essentially replacing current-generation ground networks with DS ground connections. Just not sure whether this would have too much of an impact on current-generation ORS behavior and whether we might run into performance issues with the way the ORS generates connections. If done properly, this change would mean that demand moves from airports to location, and the ORS actually processing locations instead of airports.
Cargo
Cargo and the DS do not go very well together, at least not in terms of realism. But since current-generation AS treats cargo like 100kg people, we might as well stick to that for the time being. When we tried to add booking classes to AS about a decade ago, I intended to give cargo a special range of “booking codes” from 0 to 9, so it would still be a single character code but clearly differentiated from the pax classes. This way, cargo classes wouldn’t cut into the 26 classes (A to Z) available to passengers. Might just reuse that.
Booking Data
Storage of individual bookings has a dedicated entry on the feature roadmap, but at least some parts of this might be required for technical reasons, too. Right now, prices are fixed the moment a flight is booked into the ORS. So when it “flies” and accounting happens, we just have to take “price times bookings” to compute the revenue. With fares, this isn’t the case: In principle, one can change fare prices all the time. On top of that, not all the revenue necessarily goes to the plating carrier alone, but there might a revenue split involved in case of interlining. So the price(s) at which an itinerary has been booked need to be tracked somewhere, so we can do proper accounting. Whether and to what extent these data will be available to players is to be determined.
Phase 2: Open up fare and booking class UIs
Continuously add basic tools that allow to add and manage custom fares and booking classes if the DS feature is enabled in the respective game world. This will likely require additional adjustments in other areas, for example booking class mappings in interline agreements etc.
Eventually disable automatic generation of point-to-point fares (see phase 1) and “auto fares” so players have to manually set up their fare structure.
Phase 3: Experiment with Travel Request generation
This is experimental because I am unsure whether and to what extent we will be able to implement the original DS-idea of “individual travel requests”. Might start by generating individual travel requests per destination and only switch up distribution (using the ORS’ bulk distribution method) before actually diving into generating individual location-based requests.
Phase 4 to n
TBD, but general idea: Add all the bells and whistles to the DS that make it the powerful tool it’s intended to be.
