Good Swedish evening, airport CEO, and welcome to another edition of the Airport CEO development blog! This is the 112th in order and we have, as usual, a lot of interesting stuff to dig into ranging from the recent Steam summer sale and all the new deployments we’ve made as a result of the influx of a lot of new aspiring airport CEOs, to the upcoming major new feature implementations! We’ve really got no time to spare so let’s just get into it…
As of the two last weeks we ran two very successful sales on Steam and Humble Bundle, i.e. the Steam summer sale of 2018 and Humble Bundle’s special “Flight Sale” event. The sales brought in many new players to the community and with them a lot of great feedback, bug reports, new ideas and feature requests. Since we also, in conjunction with these two campaigns, deployed the new UI update we expectedly ran into a few critical bugs here and there given the large number of new players trying out such a large change compared to the previous default version. While the new UI update was thoroughly tested it is, as we’ve mentioned, still nothing compared to having this many new players try it out. “Why then deploy such a large update just prior to the sale?” someone might ask, and the simple answer is that Alpha 26.2 was not representative of the current state of Airport CEO and that it was stable enough (and would be patched over the weekend) and that the benefit of the new UI, bug fixes and other new content outweighed at-this-scale untested code base.
As a response to the bug reports we’ve deployed many updates to the experimental branch and consequently the default branch. The latest one, Alpha 27.8-3, made its way to the default branch today with a few important fixes and the ones before it has had equally important fixes. We’re constantly watching the incoming bug report stream and are organizing our work to target the bugs that are most frequently posted and that has the highest impact. Even though focus is currently mainly on new implementations we’ll still be watching the incoming bug stream and solve any critical issues that continue to persist.
The change log for the most recent version can be seen here!
But lets stop talk about the past of Airport CEO for one in while and instead focus on the future! As a result of the community feature request vote we’re currently working on three major epics, alongside a few other much-needed new features that for various reasons are suitable to implement as of now.
So why not kick things off with talking a little bit about a feature that wasn’t voted on. During the Steam summer sale we received, as mentioned, a lot of new players and with them came a lot of new bug reports. Several of these were related to aircraft being stuck, deadlocked or simply taking strange routes on the taxiways. When we looked into the associated saves, almost all “bugs” were caused by incorrect or lack of holding point design. It is of course very sad that people get stuck so early in the game because of complicated and in some cases ill explained game mechanic, and wile we say “bug” it is still very clear to us that something has to be done in order to mitigate this behavior caused by bad game design. As a fix to this common problem, we have decided to do some more improvements on this area combine with continuous efforts of looking over the overall taxiway and air traffic control system. As of right now we are currently looking into how to make the holding point system easier to understand and we think the solution is to have runway exits and entrances built as separate, modular objects that will automatically attach to the runway. This will give us better control as we can, for example prevent a player from even opening a runway unless there are at least one entrance and one exit attached. An different, more obvious benefit, is that we can experiment with shapes that do not have to have their object borders aligned to the grid to make the exits look more nice and realistic (see below image), as well as defining what types of aircraft can use what type of entrance or exit. All in all, a much more versatile and agile system that prevents faulty construction, enhances realism and airport operation agility.
Please note that graphics for these object are not final and that this is something we’re currently working on. We’re calling the future of runways modular since it will not stop with only these types of exits and entries but because we in the near future want to expand the system with proper PAPI and other various guidance systems.
With multiple terminal floors being one of the highest voted features it was naturally selected and something we’ve started working on. We have done some initial experiments on building objects on different levels and these have been successful, it proves that the preparations we have done in the code and the months of processing this implementation in our thoughts have paid off. The construction part of the multiple floor implementation is not really seen as a major obstacle but there are still a lot to be done and worked on such as the path finding. We will update you on this once we progress more with this feature and when it comes to these types of major, major changes it’s really worth while to let the thought process take its time.
Another feature request that was highly voted and selected for implementation was remote stands. A remote stand is a stand that is not immediately connected to a terminal building but one that requires some sort of vehicle transfer in order to be reached by departing passengers for boarding or from which arriving passengers can be transferred from.
The implementation is fully planned and is executed in three steps. The first step consists of implementing the assets required to represent the entities that are involved in the simulation, i.e. the vehicles and buildable objects that connect the simulation end points. The second step is to implement the logic that will guide the simulation, i.e. the player’s interface on how to instruct the game on what stand is remote and through which point passengers will be transferred there. The last step consist of writing the actual simulation processes, i.e. the code for how passengers will move between a gate and an airside shuttle bus stop, how that shuttle will be summoned and how passengers will move between the shuttle and an aircraft.
Luckily, we’re now reaping the fruits of our labor with writing generic code and implementation is swift. We’ve passed both step one, implementing the airside shuttle bus stop and the required vehicles, as well as step two with how the airport CEO assigns boarding desks to remote stand and all the logical complications that come with such a freedom. The end result is a very agile and versatile system that utilizes out generic object-to-object connection system, allowing for example one airside shuttle bus stop to have several boarding desk connections, or for another example one stand to have two boarding desks with separate airside shuttle bus stops. The below images offer some brief insight into what will be possible.
As of the rest of the week we will be working on implementing the simulation processes which, while also essentially utilizes a lot of already written code, will probably be the bulk of the work since it naturally will contain a lot of testing. The granularity of the simulation will be thorough, i.e. the full transfer path of the airside bud shuttle will be simulated as well as stair trucks for aircraft embark and disembark.
Again, all details and graphics (these images are captured in the game egine’s editor and not in a separate build) are subject to change but we’re looking forward to keeping you updated on the implementation process!
Since the stair truck and belt loader truck simulation in many way share several similarities we considered it to be a waste of time not including it in the work bulk for the remote stands epic. The belt loader truck will assist aircraft in unloading cargo from its hull and while most medium sized aircraft will prefer one (don’t worry, we’ll do our research) they won’t be required. Not having a belt loader truck present however will drastically increase the time it takes to load or unload an aircraft.
Remember, the development of all new features can be tracked in real time via this Trello board.
… are not yet initiated. The current strategy will be to finish at least one of the current epics before tackling the next one.
As our friends and family are now transition into the annual Swedish summer vacation, we will also take the opportunity to reduce the work hours during the next couple of weeks. The summer in Sweden is very short so we would like to enjoy some of it with our friends and family. This means that we will mainly be monitoring the backlog for critical bugs and have the usual presence on our social media channels, however work on new features will most likely be less intense as we enjoy some time off. This is however not to say that we won’t work if we feel like doing so or if the weather gets bad, but progress may not be as reliable as it usually is for the coming weeks.
… and that’s it for this week! Given the summer mode we’re now entering it’s uncertain to what extent we’ll post devlogs for July as it purely depends on the progress we make. The next devlog may either be a simple update in a Forum post or a full fleshed development blog, regardless we will update you on the work as per usual (it’s simply just the format and length that may vary).
Good evening, airport CEO, or something else depending on where you are! Welcome to the one hundred and fifty first development blog in the series and another update on what we...Read more
Well hello there, airport CEO, and welcome to the one hundred and fiftieth development blog! It’s been a little over another two weeks since we last spoke and we are very, very...Read more