Dev Blog 44: Lighting System, Continued Serialization & Polishing…

October 31, 2016

We’re on the brink of November and development blog 44 is, as you can, not delayed! We’ve had another productive week despite having to deal with classic autumn sickness and a lot of other life distractions and looking ahead it seems as if life seems a bit less congested compared to the previous week, always feels great to be able to prioritize development.

Lighting System

We started the week by doing some very much needed changes to the lighting algorithms, replacing an unnecessarily complex looping algorithm with an animation curve that gave us a lot greater control over the lights. Each lamp in Airport CEO is a single object (yes, every runway and taxiway lamp as well) and almost all structures will most likely be fitted with some kind of light source (excluding the terminal). This called for a better lighting system and what we ended up with is that now can we not only simulate cool lighting delay effects depending on if the light is, for example a big spot light that takes some time to spin up, or if its a runway LED lamp that lights up instantly, but CEOs can now also decide themselves when the lights turn on and off .

The lighting system also affects the sun, and we can now simulate different sun rises and sun setting times depending on the season of the year (or region if we want to really push the details…) so that those cold winter mornings really are extra long, depressing and dark (basically December in Sweden).

We tweeted out a .gif of the improvements which was very well received and so we’ll post it here for everyone to see. For effect comparison, the first .gif has lights on at sundown and the second .gif shows lights on at midnight.

Of course, if an aircraft was going in for landing and the lights being turned off you’d likely have an incident on your hands. Making sure that lighting requirements are adequate for your flight planning is initially the responsibility of you, the CEO and perhaps later the COO.

So what’s the purpose of being able to control when the lights go on? Well, lights require power and so we are thinking of adding another resource in to the game: Electricity contracts and power consumption. Most objects already have an hourly operation cost whereas a sofa’s operational cost is $0 and a basic fuel deposit has a substantially larger sum (not yet decided). In order not to make it too complex the electricity cost could make up like 30% (-ish) which would ultimately mean that when you’re running all the lights at night you’ll experience an increase in power consumption whilst the concept of electricity consumption still is graspable. What do you think? Too much micromanagement? Or another nice tradeoff simulation?

Continuing the Serialization Quest…

The ongoing quest of serialization continues! Testing of passenger and employee serialization has reached the point of where we have test case scenarios requiring us to implement serialization of other stuff. For this reason we have moved on to prepping for serialization of vehicles and bags. This includes cleaning up model classes and at the same time preparing the for modding support (similar to what we did the aircraft model classes) and during this week effort we will implement the same system we use for saving and loading passengers. In short, we’re simply continuing the work of converting and adapting existing models into functioning serialization practices: Progress this week on vehicles and bags should be swift.

We’ve also spent a few hours fixing additional errors related to saving and loading of franchise contracts as well as clearing up som UI stuff related to that while also adding some more variables that were forgotten during a save.


As focus right now is on quality and making sure that stuff don’t break, we’ve done some overall polishing and fixing…

  • Rooms have been fitted with a new selection image
  • Rooms had an issue where the canvas text was out of bounds – resolved
  • Stupid and redundant code for getting items within a room has been removed
  • Static as well as dynamic queues are now visible by toggling U (and they also become visible when building)
  • Multiple issues resolved with passenger activity methods
  • The staff room panel lacked a “remove room” button, which has been added.
  • A lot more…

That’s it folks. And oh right, we also put some time into correcting a small login issue with the forum even before anyone reported it …and also fixed an issue with the devlog posts breaking the page and blocking the footer. Interesting, huh? That’s it for this week. See you later and have a good one!

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.