Blog

ATC Part II – A Dilemma

Here’s a thought experiment for you: you have a new version of X-Plane with new global scenery, new rendering engine options, new weather, a whole fleet of new planes, and new ATC. That new ATC is rewritten to support realistic IFR flight, the AI planes participate, the system includes ground ops and it uses audio files to “talk”. But the AI planes don’t have real-world liveries, and they don’t follow real-world schedules for major airports. What do you do?

1. Release this new version of X-Plane with the ATC as is, and continue to improve it in a patch.
2. Release this new version of X-Plane, but ship the old ATC from version 9, because while the new ATC is better, it’s missing some features that some users have asked for.
3. Delay the release of the entire sim because ATC is missing some features that some users have asked for.

Clearly options 2 and 3 aren’t options at all; you wouldn’t ship the old ATC (which is clearly inferior to the new code) just because there are more features you could ship, and you wouldn’t withhold the rest of the new version’s features for the same reason.

No feature is ever done unless a program is dead. Austin hired me about five years ago to work on the scenery system, and it is no more done now than it was five years ago. It is a lot better than it used to be; more efficient, better looking, more realistic, etc. But the bar for what is possible keeps moving. That’s part of what makes working on flight simulation software so interesting.

In yesterday’s post I tried to clarify why we are using real physics in the AI ATC planes; a lot of the discussion surrounding Austin’s original announcement made some assumptions about where CPU time is spent that aren’t correct. This post describes how features are incrementally added to a release – without understanding release planning, Austin’s description of 20 AI planes makes no sense.

Stretching the Playdough
Programs aren’t just born whole, complete, never to be modified again. If there is one consistent misunderstanding of software, it’s this notion that you “build” software the way you might build a bridge or a house. The truth is, software is made out of a building material that is nothing like bricks or steel, and thus the engineering practices have to be quite different.

If you build a house and decide you want a different exterior floor plan, you’re pretty much hosed. No one is going to change the outer shape of a house because the materials used to build the house are not particularly pliable to modification. The cost of moving a foundation is about the same as building a new foundation, so modifications are made as minimal as possible.*

By comparison, code is a lot more like playdough than bricks or concrete. You want the master bedroom a little bigger? Great, we’ll just streeeeeetch it out. Code is always modifiable after it is “finished” – if treated right, it never hardens and sets, and this is why successful programs are often on version 10. The problems a computer program tries to solve change, but code can change with them.

So my first take-away point is this: if we add a feature to a program later, it is not because the program was “incomplete” or “unfinished” before – perpetual improvement is the expected norm in a healthy computer program. In fact, perpetual improvement is desirable because it lets us match changing technology and because it lets us incorporate feedback we get from our user base.

(There’s an old saw in computer software that the reason to put out version 1 is to learn what you did wrong so you can make version 2. That’s a bit of an exaggeration, but the truth is that the only way to get really solid user feedback is to put something out there and then listen.)

Roadmapping

Given that we expect our software to change perpetually, how do we plan? The answer is that we need a road map for the next several steps that the software will take as it evolves. By knowing where we are going we can be reasonably well-informed on the features we code now.

A road map of features needs to be prioritized for two considerations:

• What do users want first? The things we code first, we can ship first, so high priority features should go first.
• What features have to be implemented first? You can’t build the roof of a house first, and we couldn’t have programmed orthophoto paging of DSFs until we programmed loading DSFs themselves. Sometimes the features “have” to go ina certain order for programming reasons.

ATC AI Airplanes

At this point we finally have enough common vocabulary to sanely discuss the AI airplanes for X-Plane’s ATC. So far I have tried to establish that:

• The AI airplanes are going to get better over time.
• We will almost certainly ship ATC AI before the AI airplanes are perfect.
• The order that we implement ATC features will be a mix of what we think is most important and what has to go in first for engineering reasons.

The first stage of the roadmap was to use X-Plane’s built-in AI planes as AI traffic. There were a lot of reasons to do this as the first step:

1. The code’s already there, so it let us get some airplanes moving around quickly. Inventing a fully separate system from scratch would have taken time away from the rest of ATC.
2. Virtually every optimization that has been suggested (and several that haven’t been) can be applied to the AI ATC airplanes, so there’s plenty of room to get faster. (If we thought we couldn’t optimize, we might not have put the flightmodel in for AI at all.)
3. By sharing the flight model code with AI, the optimizations we do pay twice – to make ATC faster and to make the framerate faster for all users.
4. Inventing a new way to make airplanes (only for ATC) would mean two sets of editing tools, which would invariably mean worse tools in all cases.

With the AI planes running, we then have a lot of ways we can improve things. We can optimize performance. We can optimize memory use. We can increase the airplane limit. We can virtualize the flights (so far away flights exist only in the ATC DB and don’t use a “real” AI plane). We can sever the 1:1 mapping of airplane model to flight. We can recycle airplanes when they get too far away to be adding anything to the user experience.

Which techniques will we do, and what will the airplane limit be? I don’t know. Optimization really needs to be driven by testing – that is, we need to improve the system by measuring it to see what the next best step is, not by speculating about what problems we might hit in the future. Over time, we will repeatedly optimize and the capabilities of the system will steadily grow.

If you want to know the final specs and capabilities for the ATC system, I fear you’ll have to wait until X-Plane 10 ships. When we are in development, any planning for future features is just that: a plan. As we hit real bugs and learn more about the features, the plan can, and often does change. Thus estimates of what X-Plane 10 will do won’t be truly reliable until we ship.

* I should be careful here; I used to have these conversations with Sergio, who is a professional architect among other things, and he would have to correct me on a million different aspects of construction technology.

ATC Part I – Real Physics

This is a repost of a reply I wrote on avsim that sort of grew out of control. In part II I will try to explain what we’re doing with the ATC system and how far we will get in X-Plane 10.0. Anyway, post follows.

I will have to write a blog post to go into this in more detail later, but I think a lot of what has been written here is wrong. Y’all started under the assumptions that:

1. The flight model is going to be too expensive to run on AI planes and
2. A table based flight model would be faster.

Those are both questionable assumptions at best…pretty much everything you can conclude from that is, IMO, dubious.

(I should mention at this point that I am unaware of any “dumbing down” features in the FM right now. My understanding is that we will pre-process control inputs in a number of ways, and the frequency of the FM can be set to multiples of the framerate, but even at the lowest setting, we do a full physics integration and the plane is the sum of the physics that are applied to it. I mention this now because I am about to speculate on some optimizations that _could_ dumb down the physics model, and I want to make clear that shipping X-Plane 9 does not do this!!)

Here’s the short version:

The most expensive part of the flight model is ground interaction – that is, the flight model doing collision checking with the ground and various parts of the airplane. When an airplane is “clearly in the air” (e.g. an initial test shows it has high altitude) the FM isn’t very expensive; when it is near the ground, CPU time cranks up as we make sure to get the touch-down characteristics just right; same with taxiing.

So if we want to make the FM faster, there’s really only one place to attack: ground interactions – it’s the lions share of CPU time. There are a number of simple things we could do to improve ground interaction. For example, we could stop checking for body scrapes – since X-Plane has to handle physics correctly even if the user lands gear up and scrapes an engine, the sim normally tests the full geometry of the plane against the ground (which is not flat, even at an airport) – that adds up. If we are willing to trust that the AI planes don’t screw up a landing* we could cut down ground check to only real landing gear, which would improve performance.

Now what if we did some kind of ‘lo-fi’ AI, whether it’s table based or it simply says “move the plane forward by this much” (E.g. a sort of track-based system)? If we want the airplanes to ‘sit’ properly on the non-flat airport surfaces, we _still_ need to do the most expensive part of the FM – the wheel-ground collision checks. So the total savings of a ‘lo-fi’ AI flight model would be very small, because at best we might partly improve the performance of code that doesn’t have much impact on the sim.

(To understand why you can only boost performance by attacking the biggest pigs, see here.)

However, there would be a pretty huge cost to a lo-fi flight model: we would have to code a SECOND implementation of pretty much everything we already do in the real flight model! We would have to have new flight model files to support this new alternate flight model. The opportunity cost here is in developer time…the time spent building a separate flight model could have been spent performance-tuning the real flight model…even if we had a second flight model, performance tuning time would now be divided between the two flight models, and neither would reach its optimal performance.

Besides my explanation above of why a lo-fi flight model wouldn’t really be a win, two more comments:

In software development, it often pays to try the simplest thing first, see how it works, and go from there, rather than speculate how a system may perform and write a ton of code up front before you have real data. This is what we are doing…the simplest thing we can do is to run the real FM on the AI planes, and so far it looks like it’s going to work reasonably. IF we hit data that says “no we have to do something radical”, then we will…when the data says so, and no sooner. So far indications are that the real FM is going to be fine, and this makes sense from what we know about its performance characteristics. We also know that we have a lot of tricks we could pull to make the real FM faster for AI planes (e.g. removing engine scrape-checks, per above) before we have to go and write a whole new FM.

And finally, dude, the real FM looks good. With the real FM, the AI planes move the way big heavy airplanes should move. They track the ground perfectly. If the ground has a bump and the airplane’s suspension is loose, it sways like it should. The control surfaces deploy with their real time. When you’re at an airport performing ground ops, you can get really close to the AI planes, and at that point these things matter! I speculate: once you take follow an AI plane running the real FM on the ground, it’ll be hard to go back to a ‘synthetic’ FM.

* This may not be a safe assumption…what if a microburst hits an AI plane?