Software Engineering Daily: The X-Plane Flight Simulator with Ben Supnik

Date: October 28, 2025
Host: Software Engineering Daily (with guest co-host Kevin Ball)
Guest: Ben Supnik, Software Engineer at Laminar Research

Overview

This episode delves into the intricate engineering behind X-Plane, one of the world's most advanced flight simulators. Ben Supnik, a 20-year veteran at Laminar Research, shares how X-Plane merges the worlds of AAA game development, platform longevity, and real-world aerodynamics simulation. The discussion covers X-Plane's unique technical challenges, platform evolution, handling of user-generated content, cross-platform strategies, FAA certification nuances, testing methodologies, and the philosophy and roadmap that keep the project thriving over decades.

Key Discussion Points & Insights

1. Ben Supnik’s Journey & X-Plane Origins

• Ben started as an X-Plane user and modder, intending to leave software for air traffic control, but got "stuck" after being drawn into ongoing development.
• Quote:

  “If you told me back in 2005 you'll be doing this in 2025, I would have been completely surprised.” (01:21, Ben)

2. X-Plane’s Software Architecture: Platform and AAA Game DNA

• Hybrid Identity:
  X-Plane has one foot in AAA games (high performance, advanced graphics) and another in platform software (backward compatibility, modding ecosystem).
  • Games typically prioritize "fun" and can overhaul engines at each sequel; X-Plane must maintain continuity for user-generated content (aircraft, airports, add-ons).
• Quote:

  “We’re kind of a platform as much as we’re an app.” (03:44, Ben)

3. Physics Engine: Deep Aerodynamic Simulation

• Unlike general-purpose game engines using off-the-shelf physics, X-Plane’s engine is domain-specific, modeling everything from airfoils to wind flow, providing predictive simulation (especially for novel designs such as electric VTOLs).
• Proprietary Aircraft Data Format:
  Describes physical properties, airfoil tables, and control surfaces—allowing emergent aerodynamic effects.
  • Quote:

    “We try to derive from the parts what is the net effect on the whole. So there’s a number of aerodynamic effects that are emergent, and we don’t code them in.” (08:33, Ben)

4. Performance Across Hardware (PC to Mobile)

• Modern mobile phones are far more capable than the PCs from when Ben started (~2005).
• Physics simulation is performant due to a limited number of simulation points (e.g., 40 per wing); most computing power now goes to graphics.
  • Quote:

    “The phones are much faster than the computers that were running X-Plane when I started…The physics actually take a relatively small portion of the performance budget.” (10:08, Ben)

5. Graphics: Evolving Realism & Backward Compatibility

• X-Plane pursued physically-based rendering (PBR) and then photometric rendering to align visual content with real-world materials and measurements.
• Maintains backward compatibility by defining what content is (physical properties) instead of how it looks.
• Quote:

  “Anytime we can use the real world as a reference for the content, we have the option of doing better.” (13:06, Ben)

• Content Authoring Costs:
  Increasing graphics fidelity increases add-on creators’ workloads. X-Plane mitigates this by automating complex features (e.g., 3D rain on windshields) to avoid manual labor spikes for artists.

6. Software Stack and Rendering Migration

• Core Code:
  • Written almost entirely in C, with in-house cross-platform layers due to its age (pre-dating many libraries like SDL2).
• Graphics Evolution:
  • Moved from CPU/software rendering to OpenGL, and recently to Vulkan and Metal for modern graphics APIs.
• Migration Strategy:
  • Refactoring required maintaining two renderers in parallel for a safe, extended beta (“never break the universe”).
  • Quote:

    “Austin has always said that he wants our time horizon to be infinity... if it’s going to be inefficient in a ten year horizon...it kills him.” (26:26, Ben)

  • Introduced abstraction layers to decouple old/new rendering systems.
• Practical Lessons:
  • Coexist old and new systems for real-world, iterative field testing.
  • Long-term orientation allows phased, risk-mitigated upgrades.

7. Testing and Quality Assurance

• Expanded over time—from ad-hoc user reports to automated unit/integration tests (Catch2, Python scripts), black box image comparison, and manual testing from expert QA engineers.
• Challenge:
  • Impossible to test all combinations due to vast third-party content diversity. Still working on broader test coverage, especially for rare/complex aircraft configurations.
  • Quote:

    “I would always love to have more testing...because X-Plane is a platform, you can make an almost infinite combination of aircraft.” (33:20, Ben)

8. Flexibility in Content Validation

• Enforces some semantic validation but must allow exotic/edge-case models (e.g., RC planes).
• Tension between strict correctness and openness for creative exploration.

9. FAA Certification & Professional Use

• X-Plane is supplied as software to device integrators, who certify the system (hardware + software + controls), not just the software itself.
• FAA is more concerned about reliable operation than absolute physical accuracy—e.g., the simulator must not run if the joystick is unplugged.
  • Quote:

    “If your flight control hardware is not working...your simulator has to not start.” (39:08, Ben)

10. Cross-Platform, Input & UI Strategies

• X-Plane runs across Windows, Linux, macOS, Android, iOS.
• Keeps platform-specific layers as thin as possible—custom UI, input abstracted via libraries, plug-in support for customization.
• Applauds Microsoft for maintaining exceptional backward compatibility, easing cross-version support.

11. Roadmap & Feature Pipeline

• Upcoming Patch 12.2:
  Focused on massive rendering, lighting, and graphics improvements—a culmination of a year’s work post X-Plane 12.0 pressured by Microsoft Flight Sim 2020’s surprise entry.
• Future work includes advanced weather/system modeling (weather radar, FMC updates), new network synchronization (for multi-monitor/multi-system setups), and more features under wraps.
• Development Principle:
  • Estimating feature work is hard—almost everything being tackled is a new technical problem.

12. Industry Change, Concurrency, and Language Evolution

• New programming paradigms (coroutines, structured concurrency) are enabling safer, easier concurrent code on multicore machines as hardware advances.
  • Quote:

    “Structured concurrency has become something that people understand. So you can program with language support for these multi core machines in a way that isn't the more equivalent of GOTO for concurrent programming.” (53:57, Ben)

• The ever-increasing demands of users for fidelity mean that, unlike some maturing software markets, X-Plane always has “room to grow.”

Memorable Quotes

• On Platform Longevity:

  “We have to ask ourselves, how do we upgrade the engine and still keep this content working? So it’s kind of one foot in AAA games and one foot in platforms, which is sort of a unique niche that we sit in.” (04:12, Ben)

• On Emergent Aerodynamics:

  “There’s a tendency of aircraft to pull to the side because of the twisting motion of the propeller. And we didn’t say this is how much it pulls...it comes out by itself.” (09:26, Ben)

• On Content Author Burden:

  “The labor to go into the airplane is going up...so when we’re going to add things to the feature...how much labor are we going to bring in?” (18:30, Ben)

• On Testing Realities:

  “Most importantly, they just sniff out bugs. Like, they’re really good at that...they’ll come in and they’ll kind of shake it and get that Spidey sense.” (35:57, Ben)

• On OS Backward Compatibility:

  “As much as we sometimes say mean things about Redmond, I do recognize the value of having the thing keep working so we can focus on features and not just rewrites.” (46:42, Ben)

Notable Timestamps

• Ben’s origin story: 01:21
• AAA vs Platform distinction: 03:44
• Proprietary physics engine: 04:53
• Performance and hardware evolution: 10:08
• Graphics pipeline and content compatibility: 13:06
• Migration to Vulkan & Metal: 21:33–27:00
• Testing stack details: 33:20
• FAA certification and hardware constraints: 39:02
• Release roadmap & new features: 47:34
• Concurrency and code evolution: 53:16

Conclusion

This episode offers a compelling look into the design, technical debt management, and long-haul planning that enable X-Plane to serve hobbyists, engineers, and professionals alike. From domain-driven physics to the realities of backward compatibility and the challenges of managing a massive, evolving codebase, Ben Supnik’s candid insights are invaluable for anyone curious about complex simulation software or large-scale, enduring software projects.