Dev Blog 43: Person Serialization, Flight Operations & Starting with Aircraft Modding Support

October 25, 2016

Hello, this is your Captain speaking. Welcome to development blog 43, finally departing after a weeks’ delay! We apologize for this, but as the fans over at the forum said, “life has a habit of getting in the way of important stuff”. Men den som väntar på något gott väntar alltid för länge, and therefore we’ll jump straight to it:

Flight Operations

This week we’ve done some general work in airport operation. We added holding points which are automatically created when a runway intersection is built, if an aircraft wishes to enter a runway it must stay here and hold short while request permission to continue from ATC. Also the ATC have been improved by adding automatic runway direction shift depending on the wind direction. This system makes sure that aircrafts, both landing and departing, will take off or land into the wind just like in real life. We have also started working on runway upgrades that has been discussed a bit before. Runway lights and approach lights can be purchased as well as general extension of the runway. More features will be added later such as various navigation aid (ILS, VOR, PAPI, NDB you name it) so there is still a lot of things we wish to implement here!

Person Serialization

The week before this as well as the previous week we finally dug into one of the biggest hills to overcome yet, saving and loading of people. Instead of a devlog last week, we wrote a short blog post on the forum explaining what we’ve been doing and just as promised, this week has continued down that path. The forum post pretty much says it all, it’s a lot of work that goes in to code level stuff and not something that can be displayed bur rather so experienced. The code, before this major reconstruction, was not at all compatible with serialization and required us to revamp a lot of stuff in order to get it going. However, we’ve now ended up with a super flexible, low impact method for saving and loading simulated agents at any stage in their journey across the airport, a system that also gives us a lot more control in terms of handling unexpected behavior and stuff which means that whenever something goes wrong, as for example a result of a not yet found bug, an agent will not “die in its simulation” (stand in one place) but rather carry on with the next task.

As some of you might know we are currently developing the game using Kanban and this is the current overview for the serialization and deserialization tasks:

Each activity is color coded and consist of a number of sub activities. The sheet currently only covers what data objects are currently implemented and as we expand functionality and simulated objects (for example baggage carts) more activities will be added over time.

  • Red: Simulated Agents
  • Blue: Variables and data objects interacting with UI
  • Turquoise: Placeable Objects such as Structures and Items
  • Green: Simulation Packages, essentially aspects of saving and loading we couldn’t fit to any other category and which requires a number of dedicated methods to resume properly.

I guess we also should mention that Passengers and Employees are sub classes of Persons, since they have shared as well as individual aspects which needs to be serialized it’s been divided into three activities. What this sheet doesn’t show is the weight of the activities in terms of invested development time, where placeable objects and persons share an equal significant part (as well of course as for the entire saving and loading framework). Since we’ve now got a working framework with a working concept for saving and loading simulated agents, the remaining activities are expected to be taken care of very quickly.

We’ve also dedicated a lot of the past week’s time into finding and squashing more bugs! Especially, of course, related to saving and loading as stuff like that has a tendency to throw a lot of messy nullrefs and stuff like that.

Aircraft Modding

We know that modding and in particular aircraft mods will be a very important feature to add after the release, so we are already now thinking ahead and planning for this. We did some restructure and refactoring of the aircraft code, making it better prepared for future modding and much smarter in general. Be aware that we are not focusing or spending any more time at this as of now, however, we want to let you know that we do think about these things already at this stage.

Due to the nature of the current work we’re putting in right now, focusing on systems and code, there’s not a lot to put up on display right now. However, you haven’t seen the current drafted weather panel (we think?), so here it is:

Still a lot of variables to go in here, a more clear hour-per-hour forecast as well as diagrams and stuff like that. The small metal box thingy is the most basic of weather stations that can be built, needed for rendering any weather data. That’s it for now, but we’re most likely going to release another full view gameplay .gif later this week so stay tuned for that! See ya later.

Related blog posts

Dev Blog 131: Alpha 31 released on experimental (the multi-floor update), aircraft cabin cleaning and NG19 postmortem

June 7, 2019

Good day airport CEO and welcome to the 131st development blog, a few days delayed but with good reason. Today, after months of development, we’re launching the first of several...

Read more

Dev Blog 130: Last phase of multiple floor, completing the de-icing implementation, localization tests and NG19!

May 25, 2019

Hello airport CEO and welcome to the 130th development blog! We’re writing to you from the floor of the third day of the Nordic Game Conference 2019 here in Malmö...

Read more


Enter your email to get the latest updates and news.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.