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?
- Release this new version of X-Plane with the ATC as is, and continue to improve it in a patch.
- 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.
- 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:
- 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.
- 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.)
- 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.
- 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.
Just please do not prohibit the -possibility- to select tons of AI aircraft (50+) as some of us are in fact running the sim on true hard core systems and really want to take advantage of the fact.
Also really looking forward to x86-64.
Cheers!
My point is this: we don't prohibit _anything_. The system is _meant_ to grow!!
RE: Prohibiting stuff
– Two thumbs up!
"It is forbidden to prohibit!" 🙂
I am truly hopping that XP10 way to deal with ATC/AI planes borrows lessons from what the team appears to be doing with cloud rendering, read: "I don't care if the plane is 100 feet higher or lower if it is 50 miles out (that is not even a pixel high diferent from what it would be in the screen), I might start to care as it gets to be 40 – 30 – 20 – 10 – <10 miles out."
Does the current engine allow for that kind of scaling in the precision with which it comes to a value? Is there any possible performance gains along this route? I am actually a bit sceptical.
Unfortunately, and so far, 20 planes topping an 8 core/16 threads CPU does not augure much good feelings.
I will wait and see…
Can you consider the possibility that 3rd party devs will be able to do a much better job at ATC (player and AI) and real world AI flight schedules.
The reason is they can dedicate a lot more time and leverage a lot of existing (FSX) based code.
But you need to give them the plugin SDK "tools" to do so.
I've not recently checked in detail what the XP plugin SDK is capable of but IMHO the plugin SDK should have the following capabilities:-
1) Completely turn off default XP10 ATC/AI aircraft, since the plugin wants to manage all this.
2) Create object (ie aircraft model file + livery if XP stores liveries independently of the model) at given lat/lon/agl and return an object "handle". If error creating object (eg too many objects) then return error code. This would allow a ATC plugin to decide which objects it's already created to destroy in order to make room for new objects. Typically this might be aircraft that are a long way from the users aircraft, or maybe an aircraft sitting at the gate.
3) Destroy object by handle.
4) Issue waypoint list (lat/lon/agl/spd) to object. XP10 should then move the object along the waypoint list whilst applying
the appropriate flight/ground physics. Note that it would be a requirement that objects might be created already "enroute" at AGL/SPD above 0, eg users aircraft
is sitting at the gate at VTBD and plug-in needs to create a Thai 747-400 already at 9000AGL/240 KTS
at the location of PAULA (about 20 nm south of the airport) which a waypoint list that will make the 747 follow the PAULA star into 20R.
5) Allow new waypoint list (lat/lon/agl/spd) to be issued to object, replacing the old waypoint list.
6) Return list of object handles within given radius of lat/lon
7) Return info (lat/lon/agl/spd etc) for object by handle.
I think its a pretty basic list of requirements and maybe the plugin SDK already allows all this anyway? But the point is that by giving a plugin this type of low level control there should be no reason why AI ATC (incuding real world schedules) and player ATC cannot be implemented by 3rd party devs.
Regards, MatthewS
Will there be cows?
Yes but you'll be limited to only 20 cows…they will graze and chew realistically though. I hope they add SDK support for custom cow actions. I want to make mine jump over the moon.
Listen – you don't just build a cow all at once. First you build the cow without its rumen. Sure, it will be really hungry, but hell, we just feed cows corn in the US anyway, and you don't really need a rumen for that.
Then you check the cow's performance. Is it getting fat? Sick? Okay, now we can decide what's more important. Do we add a rumen or virtualize the cows or optimize their weight? Maybe our users want pork instead.
This is what makes software 'special'. In the real world (that big overlit room with the blue ceiling) if you want to convert a cow into a pig the procedure is, well, it's messy, and the results aren't usually very good. With software, however, you can make these kinds of changes. The cow is never done!
OMG it's so hilarious. People asking for a cow in a flight sim. Hell I want some fishes in the water too 😛
I appreciate all the hard work going into x-plane v10 and likely will be purchasing the upgrade. The key things to consider for me as a user is how much of extra value am I going to get out of this purchase. Good AI is welcome of course, visual improvements as well, new weather system kind of cool as well. So, by what I'm reading I think you have got the basics pretty well covered in terms of added value.
The AI doesn't have to be perfect from day one as long as it is a significant improvement over what you ship now. And what you ship now basically means a pretty lonely experience at most international airports because there's maybe a handful of very random planes flying around at random places miles away from you. You have to work pretty hard to get close enough to admire the physics in v9. So, as far as I'm concerned, solve that problem first and worry about the rest later.
I'll be thoroughly impressed when I have to start queuing for takeoff at big airports that would add some realism to the sim. If the planes also fly on schedule (unrealistic at some airports 🙂 ), have correct liveries and 'wiggle' correctly that will be even more impressive of course. But the key thing is a realistic traffic density that a user on a normal setup can enjoy, which inevitably is going to mean compromising elsewhere. I'd rather have 50 not so realistic planes than 1 or 2 realistic ones.
I'm a developer too, have been for the past 20 year and I appreciate so much your way of writting and saying things, Ben. I really enjoy your posts besides loving how X-Plane has evolved along the years. Much is due to your efforts to which I can only say sincerely thanks for this wonderful x-plane experience. Live long and prosper!
So now when i fire up the XP10 beta, i certainly won't be surprised if a cow lands on R16 Left, taxis to gate 23 and unloads its udders, All under ATC control!.
Definitely go with option 2 ben! Those who want real AI can use VATSIM anyway.
The cow discussion is humorous, but relevant, ESP when you see ORBX's latest videos of groundcrew operations. That's why yes, the cow is never finished!
Hope the AI GA aircraft are as unpredictable as in real life, maybe their AI can be set lower. 🙂
Ok, well, I guess I wasn't totally kidding about the cows. I can hear the doppler moos already.
Or the field mice, then, as long as the physics are ok.
Hopefully part of what's on the list is making the AI smart enough to fly helicopters – at present in v9 it tries to control them just like a plane. That most definitely doesn't work 🙂
No improved ATC ? No X Plane 10.
We can wait a couple of years no problem, but please do not release a flight simulator with X plane 9 ATC ! It would completely ruin the new simulator, it will smell, this way, of a rusty and dusty repaint of X Plane 9.x.
Tweaking it later it not an option, the shining of the new product will be ruined for ever.
I can understand it is tricky to properly program an ATC but we can wait 2-3 years to fix it, no problem.
I would much rather have AI traffic. Even if that means a delay. You absolutely cannot ship without some type of reliable impressive AI. I personally would scrap any and all physics on AI aircraft, they are there that is good enough. Just remember the most important part of AI is a 70 mile radius from the airport you are landing at and the airport you are taking off from… Even less so on the airport you take off from.
AI on the ground is just as if not more appealing as airplanes in the air. Full terminals and taxi-ways are the important part.
ATC must function correctly in the game, it doesn’t have to be a mirror of real life, but if they clear me to land there better not be anyone in my way… The same goes for calling an approach for local traffic, if I call out “on final” that other guy better go around.
Just remember KISS… Keep it simple stupid…
I honestly don’t care if the airplanes are pixelated mess. What I really REALLY dream for is an ATC system that realistically replicates the procedures in the real deal NAS. Implementing SIDS, STARS, and DPs in some fashion, holding if the airport reaches capacity limits, an AI that gives speed restrictions and vectors for spacing or across the localizer for spacing.
Now I understand that the programing required to effectively maintain 3 to 6 miles in trail at a busy airport with multiple parallels may not be obtainable, at least the capacity to fly a STAR, SID, or file one using waypoints would be excellent.
I would just kill to hear an AI ATC saying “Fedex 311 maintan 170 knots till RIPIT caution wake turbulence following a heavy Boeing 767 contact tower 128.8”
Can you add the ability for the ATC to make mistakes? Like a failure mood? ( referencing the TV show mayday) also add a mayday feature and have to land with it.
Very good idea! Like we already have equipment failures (VOR, for example), we could have ATC mistakes (simulating an human “failure”)
And of course, we also need virtual controllers that fall asleep or have a stuck mic while watching a movie on the midnight shift… 😉 SCNR
Dave took the words out of my mouth…
i think option number 1 is best because then the rest of the program will be available and the newest ATC system can be patched in a later update
can’t wait to buy!
Is the ATC really worth delaying the release of an entire sim that MILLIONS of people are waiting for. How many people actually use this ATC anyway. There comes a problem that most people use VATSIM with real people instead of a computer. Other networks such as Pilot edge are going to be released. You could use the ATC but then again most people prefer to fly online with other people. Currently Xplane’s multiplayer really kills frame rates and hogs up bandwith. Netflights, a plugin developed by Sandy Barbour has solved the problem, but is obsolete when it comes to VATSIM or Pilot edge because of the ATC. Also a problem with Xp’s current ATC is that it does not use realworld charts with SIDS, STARS, Approach Plates, DME arcs, etc. When you apply these though, you need to update the AIRAC and all of these charts. There are millions of them and that would take A LOT of time. All these problems could just be resolved if you just had XP users resort to VATSIM or Pilot Edge. Who knows you guys could just make an online network of your own without having to waste time working on ATC no one is going to use. So please before you delay a program people have been waiting months for consider VATSIM, Pilot edge or even make a network of your own. Thank you thats all I have to say.
Oh I mentioned VATSIM and pilot edge up there. These impliment SIDS, STARS, etc with REAL PEOPLE. They follow ASDE procedures, and cover everywhere in the world(besides pilot edge its still in testing). To use VATSIM you must have 2 things. Xsquawkbox the plugin to run it and an account.
http://www.xsquawkbox.net/xsb/
http://www.vatsim.net/
The only problem with VATSIM and the like is that traffic levels are completely and utterly unrealistic. Heck, most of the time there’s not even a controller in the area I want to fly, at the time I want to fly – so what’s the point?
Judith