The way I see it is that most of the issues described here do not really relate to one-way doors per se
but instead of zone control. It’s more an issue of instructing passengers to walk within certain areas instead of blocking path requests with directional doors. Another issue here is that all examples discussed are perfect solutions, but as game developers we must also always think of the broken cases, when people build incorrectly and how the simulation engine will handle that in a sensible way while also instruction the player of the cause of the issue. It’s only us, the developers, who have insight into the code so it’s of course impossible for anyone outside so estimate the technical challenge of this feature but I’ll try to explain the core issue:
If a seat, toilet, or some other intractable item is placed in an area that is only accessible in one direction, which without a doubt is something that will happen if this feature were released to the public, a passenger has no sensible way of checking whether or not they can get back to their main point of interest (such as a check-in desk or boarding desk) which would cause them to deadlock and thus break the entire flight. This could be solved in two possible ways, none of which are feasible:
-
Verification using path finding, i.e. before a passenger would interact with a seat they would need to run an additional path request from that seat back to themselves. Since a one-way door could be placed anywhere, we would need to run this check every time a passenger would make any path request meaning that we’ll double the number of path requests in any game, which is simply not going to happen due to the extra performance load we put on the simulation engine. We need to be extremely careful with path requests and keep them to a minimum at all times, and this would be a luxury that we cannot afford.
-
An arrival zone and a departure zone. In ACEO we have two levels of zone depth, generic zoning which is either open (default) or secure. On top of that zone we layer a specific zone which is at this point either staff or international (only in Alpha 35). To make the above screen’s layout feasible, you would have to individually zone areas for arrival, departure and both which would not only be very tiresome and unintuitive but also, of course, add a lot of extra performance overhead.
Zones are a core part of the difficult work the path finding system needs to do and adding more layers will mean a very notable, additional performance cost.
With realistic international stands we could after your feedback make time to provide you with additional complex behavior, because the code would allow for a toggle that could switch it on and off. Path finding and zones however, are much, much, much more complex and something, for us to be able to maintain, that needs to be generic and the same for all. With the above technical challenges in mind versus the value the feature would bring, we cannot deem it feasible at this point. Things might change, adapt and improve before or during beta but that would be contingent on us or anyone else providing a good solution that is both intuitive and that works with the code base but so far we have not seen it. I hope this text sheds some light on what the challenge is.
This is a game in development under an early access flag, we make multiple changes during each sprint with both addition and removal of planner content as a result of how the current work progresses. Sometimes we discover that we can cram in additional content, sometime we discover that we need to move around or cancel features due to technical limitations.