Backward compatibility

I just finished reading a couple pretty extensive threads on AvSim on how important customers think backward compatibility (specifically to accomodate third-party add-ons) should be when designing the next version of Flight Sim. It's actually nice to see this sort of discussion happening among community members who are so heavily vested in the hobby since the decisions we make will have a significant impact on their transition to a new version. I thought I'd get back to blogging with a couple comments on this topic.

First off let me say how entertaining some of the posts are, especially those that suggest how they think the FS engine works or should work. There seems to be a common misconception that innovation and backward compatibility are mutally exclusive. A number of comments suggest we should start from scratch in order to achieve some sort of graphic and feature nirvana. In fact a good portion of the engine gets overhauled every version and we've taken steps with each version to make this easier. For example, there used to be very little abstraction in our graphics language. This made it easy for people to 'tweak' the routines we used to achieve what were some really cool effects. A problem occurs on the next version when we change the language and the tweak no longer works (or worse, crashes the app). We've since provided SDK tools that provide a better abstraction by focussing on data structures rather than executable code. A good example is the way we now handle simple buildings. The author now provides meta data along with abstracted geometry data and the rendering engine computes the drawing routines at runtime. Now if we find a better way to render, the content still works.

Whenever possible we try to architect the engine to be data and metadata driven so add-ons developed for one version will work in the next. Over time (typically 2-3 versions) we may change the architecture to such an extent that we have to break compatibility but we try to limit these changes so users get a reasonable return on their add-on investment. I should point out, though, that one reason we do break compatibility is when customer value dictates it. For example let's say (hypothetically of course) we have a developer working on a new animation system for things like doors, jetways, etc. He will try to accomdate add-ons that use the existing animation technology but if a cool new feature that adds a lot of value to the customer experience simply cannot be done without breaking compatibility he might decide to make the break.

There are also misconceptions about what value various versions of DirectX bring to the table and a belief that someone we're not taking full advantage of the GPU. DirectX is a general purpose graphics technology. It is not a rendering engine unto itself. There are no 'CreateRealisticJetExhaust' or 'AutomaticallyBlendTheRightTerrainTextures' APIs in DirectX. Saying we should scrap our current engine or move to a different graphics technology would be like saying, "I don't like my 3-year-old metal Volvo. I want a new one built from carbon fiber." Is the material going to make the difference? Won't the new one still be a car?

Developers use technology like DirectX to create engines that must be optimized for a specific purpose. Any game title is a result of tradeoffs, especially in the graphics area. Many techniques made possible by DirectX APIs look great in single purpose conference demos but don't work as well when combined with the gazillion other techniques a real game needs. Even version we try to take advantage of state of the art techniques, APIs and hardware but the inevitably those compromises will always provide fodder for those who want to point out the techniques we didn't use. And I'm sure when people see our implementation in the next version of DirectX shipping in Windows Vista they will say the same thing. Hopefully I'll be able to blog about that sometime in near future. (By the way, all of you claiming to know what we should do to our graphics engine can now put your money where your mouth is. We're recruiting. <g>)

FS gets compared quite often to RPG and FPS games like Far Cry and Half Life. The thing to know about those games and engines is that they are optimized for a very different set of conditions than a flight simulator. Level-based games can be 'stage crafted' to keep the user's eyepoint within a specific range that lets designers, artists and graphics developers create a very tailored experience. Most flight simulators need to provide a seamless user experience from ground level to many miles in space. Yes, we could break these out and make each one better but would you really want a series of loading dialogs whenever you passed through different altitudes? Would you want an on-ground experience where visibility was limited to less an a mile all the time in order to get high-detail with good performance?

[As a side note I've been playing a lot of Dungeon Siege 2 lately and having a lot of fun doing it. It's also a very visually stunning game but, then again, your view distance is never, ever more than a few dozen meters. Hmmm. I don't think that would work well for flying.]

But getting back to backward compatibility...we have and will continue to strike a balance between enabling users to continue to get value from their add-on investments and give them a new, unique and compelling experience.