Intercept Games

View the full article

Hey! I’m Jon Cioletti, the technical artist on KSP2. As a tech artist, it is my job to help merge the work done by artists into the more technical side of the project, to assist artists by making tools, and to write shaders for our game assets. The most satisfying challenge of my work is that everything we make is driven by scientific accuracy. Whether it’s the lighting or the VFX, we want to be able to point at something happening in game and have a real reason behind why it appears the way it does. One of the best features to showcase this is with our engine exhaust visual effects. Now buckle up, because the rest of this blog will now be me trying to summarize the lengthy creative process for engine VFX into like a 7 min read. Wish me luck. Setting our goals Step one for any concept investigation work starts with looking at cool images for reference and trying to decide what you want out of a feature. Many conversations occur at the design / art level well before it even gets to me in the pipeline. It’s in this time that people like Nate Simpson, Aaron Lundquist, and Dr. Michael Dodd discuss what our goals are for the effect and what scientific requirements it has. For example, a major driving factor in the exhaust for us is pressure regimes. Pressure regimes roughly fall into three categories: sea level, transitional, and vacuum. We can create mockups for each of these states, then blend between them to create a more realistic depiction of exhaust. From this we can break down other aspects of the exhaust (color, shock diamond, heat distortion) and track them throughout the change in pressure. As seen in Nate’s diagram below, we already have the shape language of our effect planned out early in the process. The first in-engine preview Once the initial conceptual investigation is complete, we move down the pipeline to the art and VFX investigation of the effect. It’s here that we take the concepts and visual reference and start reproducing it in engine. Below is work by Aaron Lundquist to create some initial looks at exhaust using scrolling textures, alpha masking, some vertex displacement and a nice dash of bloom to get that great glow. Here we can see how the combination of textures can create a stunning effect And here it is in motion Taking a look at the Tech! Most of our tech for the engine exhaust is driven by that engine’s throttle and the air pressure at a given location in the universe. As we increase our throttle the exhaust elongates, shows signs of speeding up and glows brighter with the increase of heat. The location in the universe is responsible for our transitions through pressure regimes. As an engine moves through different spaces, the exhaust will distort and tint to differ colors. To pass this data we need a component on the engine object in game. This component will collect the proper exhaust data values and send it off to our meshes, and materials. Script based mesh scaling One part the Throttle Manager handles is the scaling of the exhaust’s shock diamonds. As the engine’s throttle increases, we scale the mesh for the diamonds larger and longer in accordance with the reference footage and diagrams we collected during our research phase. Scaling of shock diamonds BlendShapes The Throttle Manager also controls the blending of our BlendShapes. To maintain our shape language established in the concept phases, we chose to work with BlendShapes, a technique used frequently in games for interpolating meshes. Below showcases some of that work in action thanks to renowned Kerbothropologist Paul Zimmer. BlendShape models for blending BlendShapes blending based on throttle and pressure Materials and Shaders The last thing our Throttle Manager passes data to is our effect’s material and shader. It’s here that we start modifying the actual look of the mesh itself so that it resembles something like the chemical reaction we see when an engine fires off. It’s also at this phase that we finally reach the place in the pipeline where I do my work on the effect. “But Jon, what’s a shader?” I’m glad you asked! To boil it down to the bare essentials, a shader is a program that runs on the GPU that basically answers the question: “What color is this pixel when it is rendered to the screen?”. Like I mentioned above, it’s how we give things like the BlendShape and shock diamond meshes their exhaust look. Every 3D model that we want to see in game needs a Material. Each material contains both the shader and the values we pass to it to modify it’s look. By passing in different values to our shader, we can create a wide range of exhaust materials for our different exhaust types. It’s pretty powerful stuff. On the inside a shader can also be broken down into a few major parts. On the top we have its properties. “What values from the shader do we want to expose to the artist or code to modify?”. Colors, textures, numbers, and vectors are all valid inputs. Next is the vertex function. This is the first pass the geometry faces and is responsible for the altering of the 3D model’s vertices. While the BlendShapes modify the general structure, the vertex function lets us add things like a rumbling offset. Once through, the mesh’s triangle data then heads to the fragment function to receive their final colors. It’s here where our lighting and final surface look is calculated. Example of modifying the Material’s color to get a different exhaust look All together now Okay, now for the big diagram. Below shows the data flow mentioned at the start of this section. Here is the basic flow: The engine part’s Throttle Manager collects the data it needs from the game and uses it to calculate the exhaust data that needs to be passed along to the 3D mesh and material The exhaust data scales or blends the shock diamonds and BlendShapes The exhaust data is passed to the shader’s properties Once in the shader it runs through the vertex function. The data modifies our exhaust’s shape to simulate turbulence and bends under acceleration Next passing through the fragment shader, it receives its color gradient tinting, a scrolling noise to break up the gradient, an erosion alpha mask at the tail end, fresnels to soften up the edges and exit traces Once through this process, the render pipeline renders the final effect to screen. And that’s just a single frame! Getting the tech into the artist’s hands Hey you made it this far! Your reward is the same as ours after this process, some sweet engine exhaust effects. With all these tools in place we can let Aaron loose on creating some amazing exhaust effects. This only covers the exhaust itself, there are still additional lighting and particle effects that need to be added. Enjoy! View the Dev Diaries

Ahoy Kerbonauts! Senior designer Tom Vinita here with a short update about part modules for you today! Part modules are the extra optional bits of functionality that are added to the part in order to allow it to perform specialized functions. For example, if we add Module_Engine to a part, it now has the ability to provide thrust, consume resources for that thrust, and many of the other essential functions required in a rocket engine. If a part doesn’t have any modules, then it tends to be something simple like a truss or an I-beam. Kerbal Space Program has a lot of different parts, and so it follows that it has a lot of different modules. One of our design goals with Kerbal Space Program 2 is to create a simulation that feels as close to Kerbal Space Program’s as possible while building fresh improvements along the way. If you build a rocket that worked in KSP, it is our goal for that rocket to perform in largely the same way if you rebuild it in KSP2. To that end, the team is going to painstaking lengths to document and remake, and enhance KSP’s extensive list of part modules in addition to all of the new part modules coming in KSP2. To see one example of this in action, let’s take a look at lights: Fairly simple in concept, right? They turn on, and they turn off. Well, KSP’s lights have a little more going on than that, and they’re useful in a variety of important situations. At the start of the process for bringing a part module into KSP2, a designer first studies KSP’s documentation and common uses of the module in question during general gameplay and wacky uses the community has come up with. From there, they write a series of user stories that define a list of use cases that this part module must be able to accomplish. A short example for lights would be: • As a player, I want a tool to help me see the ground when I’m landing on the dark side of a planet. • As a player, when I’m docking I want to be able to see my vessel and the vessel I’m docking with, even when both vessels are in shadow. • As a player, I want to customize my vessel with a wide variety of light patterns, whether they’re stylish, goofy, or both! Once these user stories are defined, the designer studies the player-facing tweakable values of the part—in this case things like the blink timer and the dynamic light color—and the list of values that are exposed in the part’s data for fine-tuning its behavior. The designer provides detailed documentation for everything being brought forward into KSP2, and looks for spots where the module can be enhanced. With all these values defined and the module’s functions outlined, the spec is handed off to an engineer who does the hard work of programming the module. Once the module has been written, it falls to a designer (usually myself) to attach that module to all the necessary parts, tuning the numbers of each part along the way as necessary. You can check out the results of this process below, with the new and improved Mk1 Illuminator showing off its new ability to pitch! That’s a look at some of the work that goes into making sure all the fun stuff you can accomplish in KSP can still be done in KSP2, as well as an example of finding a way to make that fun stuff even better in KSP2. Shine on! -Tom

Hi, my name is Michael Dodd, and I’m the Physics Engineer on the KSP2 development team. Before joining KSP2, I studied fluid mechanics using supercomputers for 8 years and obtained a Ph.D. in Aerospace Engineering. My goal is to add physical realism to the game while keeping the physics simulation robust, efficient, and scalable. One of the problems we’ve had to solve was the ability to accurately detect and resolve collisions at orbital velocities of 10 kilometers per second or more. Collisions in KSP can be grouped into two main categories: (i) collisions with static objects like terrain and buildings and (ii) collisions with dynamic objects, like vessels. I want to tell you about some of the work we have been doing to improve both. KSP is special—and challenging from an engineering perspective—because gameplay occurs over a vast range of length scales. Players may want to travel lightyears across the galaxy to a distant celestial body and then perform an orbital rendezvous that requires millimeter precision. Computers have limited precision to represent these distances, and when it comes to rendering objects to the screen or performing rigid body physics simulations, we are limited to 32 bit floating-point numbers. Floating point numbers are ideal for representing numbers spanning multiple orders of magnitude. However, floating-point numbers are distributed unevenly on the number line. As their value, or distance from the origin, increases, so does the difference between successive values. To maximize numerical precision in KSP2, we use two approaches that work in tandem. A floating origin like that used in KSP1, which we’ll discuss later, and hierarchical positioning. In the latter system, a tree structure is used to organize and store relative offsets to a nearby object (see previous Dev Diary by Paul Furio). For example, Kerbin is positioned relative to Kerbol, the Kerbal Space Center (KSC) is positioned relative to Kerbin, and so on. However, this approach can still lead to numerical errors, especially on larger celestial bodies. If we consider positioning the KSC on Kerbin, which has a 600,000-meter radius, it can be positioned with a maximum of approximately 10 centimeters of accuracy relative to Kerbin’s center. While a 10-centimeter error may sound negligible when compared to the vastness of the KSP galaxy, at the scale of an individual Kerbal this inaccuracy is noticeable. It causes objects to visually jitter and reduces the accuracy of collision detection. In some scenarios, the collision algorithm will miss the collision entirely, leading to tunneling: the object passing through the mesh, which we will discuss in more detail later. To improve collision fidelity, we created a system that positions surface objects, like terrain colliders and buildings, relative to a local origin located at the planetary surface instead of the center. As the player moves, we dynamically reposition this local origin and the objects that are positioned relative to it, so that surface objects near the player keep their positional values close to (0,0,0). This greatly increases the accuracy with which we can detect collisions and eliminates issues like a landed vessel jittering on the ground. While this works well for low-speed collisions, high-speed collisions need additional care. We define a high-speed collision as when the distance traveled by an object in a single frame is greater than its own size. Let us consider a command pod with a nominal size of 2 meters hurtling towards the surface of the Mun at 1000 meters per second. Assume the timestep between physics simulation states is 0.02 seconds. This means the object travels 20 m during a physics update. Given that the command pod is 2 meters means the object’s entire geometry could pass through the surface of the Mun without intersecting it. One solution is to decrease the time step, but this would increase the CPU workload. Instead, we use a continuous collision detection algorithm. Instead of advancing the object forward in time and checking if its mesh intersects a collision mesh, we use the object’s current motion to predict if and when it will collide. It is important to note that this only works if the mesh colliders of our static objects are stationary. In addition to the floating origin system like KSP1 used that ensures our point of interest is centered in the scene, we added the local origin for planetary surface objects and dynamically update their positions. Specifically, the player’s active vessel is simulated in a coordinate system that is traveling with a constant velocity (inertial frame of reference; “Krakensbane” from KSP1) so that it appears at rest (or close to it) from the viewpoint of the physics simulation. The position and velocity of the reference frame are updated whenever the vessel’s position and velocity deviate from it by some margin. That means when your command pod is falling towards the surface of the Mun due to gravity, the ground is moving towards it instead of it moving towards the ground. This causes the continuous collision detection algorithm to fail. Why? The terrain and other surface objects are kinematic objects, i.e., objects that move without any notion of mass or force. To maximize performance, the positions of kinematic objects are updated outside the physics engine because we do not need to model their dynamics. Therefore, the physics engine knows the current positions of kinematic objects, but it is unaware of their motion. To solve this problem, when we expect a collision between an active vessel and a surface (i.e., kinematic) object, we switch the reference frames of the physics simulation. Instead of the ground accelerating towards the vessel, we switch back to the vessel accelerating towards the ground. The result is accurate collision detection at extreme speeds. Snapshots of a vessel traveling at 1,596 m/s on a collision course with the Kerbal Space Center grounds. (Top row) Prior to improvements, showing mesh tunneling (middle row) after improvements without collision damage (bottom row) and with collision damage. We also want to be able to detect high-speed collisions between vessels, especially in a multiplayer setting. Because vessels are dynamic objects, their positions and rotations are being updated by the physics engine based on the applied forces and torques. The physics simulation has full knowledge of each dynamic object’s motion and therefore it can perform continuous collision detection. So when flying around space, our goal is that player’s ability to collide with objects is not limited by the collision system but only by Kerbal piloting aptitude. Slowmo-Collision.mp4 Four command pods each traveling at 2510 m/s on a collision course with and without using the continuous collision detection algorithm. Until we collide again, Michael Dodd, Ph.D. View the full article

Kerbal Space Program has now been out for a full 10 years, progressing alongside the space industry and the various people that operate within it. This documentary-style video takes a look at the people that have been influenced, inspired, and introduced to the wonder of space exploration by this bizarre game about little green beings, created by a small group of developers in Mexico City. We want to thank you, the community, for helping us turn KSP into the launchpad for the next generation of space explorers! View the full article

View the full article

Hello all, I’m Johannes Peter – A programmer on Kerbal Space Program 2 – and I love solving interesting problems! The problems we face in game development rarely have a single “correct” answer. The more specialized your game is, the more specialized your problems are, and the more creative your solutions need to be. As a rocketry simulator on an interplanetary scale, Kerbal Space Program has already tackled a wealth of unique programming challenges. Today I want to share a solution I’ve worked on for a problem that is fairly unique to KSP: How to draw accurate orbits that look stellar regardless of where they’re viewed from? I’ll briefly cover a standard approach for drawing orbits, touch on some of the issues with that approach, and then look at the solution that KSP2 is using now: screen space orbit tessellation. This dev diary will get a bit into the technical side of KSP2’s development, with diagrams to help illustrate some of the core concepts. We will mainly focus on this test scene of Kerbin orbiting Kerbol: Quick disclaimer: All visuals were created specifically for this dev diary, and are in no way representative of how anything may look in the final game. It’s just programmer art. All code, while functional, is simplified for clarity. All orbits are to scale and celestial bodies are a constant screen size to make them easy to see. Orbital Trajectories in KSP I hope it isn’t too hyperbolic of me to say, but KSP is all about orbits. Building, flying, and crashing rockets are all core to KSP’s identity, but if I had to describe KSP with one defining characteristic, it would be that it teaches you how orbits work on an intuitive level, just by playing it. While there are definitely exceptions (you know who you are), most players depend on the Map View to plan their journeys from launchpad A to crater B, so being able to display lots of orbits without visual artifacts is critical. What is an Orbit? An orbit is the path that an object takes as it moves through space while under the gravitational influence of other objects around it. Real life orbits are chaotic and not deterministic. Without performing many small iterative calculations, it is generally not possible to say for certain where an object will be in space at an arbitrary point in time. This is one of the reasons why KSP simplifies its orbital mechanics so that generally you’re only within the sphere of influence of one celestial body at a time. These kinds of orbits are known as Kepler orbits where position and velocity at any point on the orbit can be described using parametric equations. With a parametric equation we can plug in a parameter—like a time or an angle—and get an accurate position or velocity. If a curve can be described as a parametric equation it is easy for us to draw. Drawing Parametric Curves In general, to draw a parametric curve we need to: Choose a start and end parameter, as well as how many points we want to generate. Generate the points by passing values into the parametric function that range from start to end. Draw a line between each consecutive pair of points. For example, to draw a standard sine wave, we can use this parametric function: Vector3 GetParametricPoint(float parameter) { float x = parameter; float y = Mathf.Sin(parameter); return new Vector3(x, y, 0); } With that function we can use a start and end parameter to generate our points: void GenerateParametricPoints( List<Vector3> points, float start, float end, int count) { points.Clear(); // Need at least two points to draw a line if(count < 2) return; // Generate points using a parameter that // inclusively ranges from 'start' to 'end' float stepSize = (end - start) / (count - 1); for(int step = 0; step < count; ++step) { float parameter = start + stepSize * step; Vector3 point = GetParametricPoint(parameter); points.Add(point); } } And assuming that we have a function to draw a line between two points, we can finally draw the lines between the points we just generated: void DrawParametricCurve(List<Vector3> points) { int count = points.Count - 1; for(int step = 0; step < count; ++step) { Vector3 from = points[step]; Vector3 to = points[step + 1]; Draw.Line(from, to); } } Here is an example of what that looks like: 03_Parametric_02.mp4 The green line is the ideal sine curve that we want to draw, and the blue line is the result of our GenerateParametricPoints and DrawParametricCurve functions. Changing the start and end parameters (shown here in degrees) affects the position and length of the curve and the more points we generate the better the lines match the ideal curve. Drawing an Orbit Let’s assume that we have the following: A parametric equation of our orbit. The exact equation is outside the scope of this post, but for those curious, you can see better results if it uses the eccentric anomaly as its parameter. A start and an end parameter that we’ll step between. A full orbit’s parametric equation generally ranges from 0 to 2π radians, or 0 to 360 degrees. The number of points we want to generate. The default in KSP1 is 180 points for a full orbit. A graphics package to do the rendering. We need a way to draw a line between two points. As with the sine wave, we generate points using parameters ranging from the start to the end value, and by increasing the number of points we generate, we get a smoother looking orbit: 02_AddingPoints.mp4 Of course there’s a lot that I’m glossing over here, such as more efficient ways to draw lines than one at a time or other optimizations, but in a nutshell this is how orbits were drawn in KSP1. Adding some Perspective Evenly distributing the points of an orbit yields excellent results when viewed from far away, specifically when the camera is not close to the plane that the orbit is on. However, in KSP you frequently view orbits from extremely flat angles. For example, when zoomed in close enough to see the moon of a planet, the orbit of the planet will be almost completely flat. Let’s add the orbits of Kerbin’s moons Mun and Minmus to our example scene: 01_ZoomInCorners_02.mp4 When we zoom in on Kerbin’s moons, we see sharp corners on Kerbin’s orbit. The orbit line also misses Kerbin by a significant margin. Even though we generated Kerbin’s orbit with 180 points, the distance between two points is still about 5 times larger than Minmus’ entire orbit: 04_GapZoom_02.mp4 If we evenly distribute the points around the orbit, then with orbits as large as those in KSP we run into scenarios where there may not be enough points from the camera’s point of view to look smooth. We could increase the point count, but we’ll quickly run into diminishing returns. Much of the orbit already looks smooth so adding points there would be a waste, while due to the angle of the camera other parts of the orbit don’t have enough points. … What if we could add points only where they’re needed? Screen Space Line Tessellation If you have two points that were generated with a parametric equation you can generate a new point between them by averaging their parameters: Vector3 pointA = GetParametricPoint(parameterA); Vector3 pointB = GetParametricPoint(parameterB); float parameterMid = (parameterA + parameterB) * 0.5f; Vector3 pointMid = GetParametricPoint(parameterMid); We can start with a small set of points and insert new ones by averaging their parameters. The curve becomes smoother each time we do this: In computer graphics tessellation is the process of dividing geometry to make it smoother. We are effectively tessellating our parametric curve. We really only care that the curve appears smooth on the screen, so we want to evaluate the smoothness of our points in screen space, where the X and Y coordinates correspond to the point’s screen position: Vector3 screenA = camera.WorldToScreenPoint(pointA); Vector3 screenB = camera.WorldToScreenPoint(pointB); Vector3 screenC = camera.WorldToScreenPoint(pointC); With our points in screen space, we can insert a new point between points A and B based on how smooth the curve is there. But how do we define ‘smoothness’? Choosing a Smoothness Heuristic A heuristic is a rule-of-thumb; a method for solving a problem very fast while being adequately accurate. We need a heuristic to efficiently decide if our points are ‘smooth enough’. We’ve mentioned two heuristics so far: The distance between points. If points are visually close together then they’re less noticeable. The angle between points. The closer three points are to a straight line the less their middle corner stands out. A convenient heuristic that incorporates both is the triangle area, which we can compute very quickly using the Shoelace formula: float ComputeTriangleAreaXY(Vector3 a, Vector3 b, Vector3 c) { return Mathf.Abs(a.x*b.y + b.x*c.y + c.x*a.y - a.y*b.x - b.y*c.x - c.y*a.x) * 0.5f; } If the triangle of a, b and c in screen space has an area larger than a given upper limit, then we insert a new point between a and b to smooth out the curve. We evaluate our heuristic on every consecutive set of three points, until all points satisfy our heuristic, or we reach another end condition like how many points we have in total. It can help to visualize the triangles: 08_TriangleHeuristic.mp4 Putting it all together We can apply the triangle heuristic to our orbits, coloring each point based on the Iteration it was added in—red first, then orange, yellow, and so on:The orbits are tessellated using the top-right camera and the turquoise lines show the viewing bounds of that camera. The top-left shows a close up of Kerbin and its moons. 06_Subdiv_01.mp4 The closer the camera moves to the orbit, the more iterations need to be performed to satisfy our heuristic, but we also use far fewer points overall because we only generate points where needed. For example the orbits of Mun and Minmus only generate new points when they become visible. Here’s the original shot again with tessellation enabled and all debug drawing removed: 02_ZoomInSmooth_02.mp4 And that, in a nutshell, is how orbits are drawn in KSP2. Closing Thoughts When working on programming problems your first solution is rarely perfect, and it’s possible for your solution to have its own problems that you need to solve. There is far more that went into the development of this feature that I’d love to share here, from implementation details like additional heuristics, culling optimizations and choosing the right data structure for efficient point insertions, to how this can be used for more than just Keplerian orbits, but this is enough for one post. If you enjoyed this technical deep dive and want to see more stuff like it please let us know! Having the chance to share something like this with you all is very special to me. I wouldn’t be in this industry if it wasn’t for so many developers sharing their passions and inspiring me through their work online. I’ll leave you with one last debug visualization, showing the spatial partitioning used to decide when points are worth subdividing even if they’re not on screen (but one of their descendants might be): 07_Bounds_01.mp4 View the full article

Hi, friends! I’m Nate Robinson, senior producer on the KSP2 team, and I watched a lot of Apollo 13 as a kid – to the point that I practically wore out our family’s VHS copy. Naturally, I always imagined myself in the role of astronauts Jim Lovell, Fred Haise, and Jack Swigert. Every 90s kid wanted to go to Space Camp, become an astronaut, and fly on the Space Shuttle, and I was no different. But a funny thing happened a couple of decades later when I watched the film again as an adult: I didn’t find myself associating with the astronauts. I, of course, had long ago moved on from any dreams of being an astronaut myself (I blame my poor vision, but trigonometry was truly where I gave up the ghost). Instead, I found myself far more engrossed in another role – that of flight director Gene Kranz. Kranz, spends the entirety of the film not in space, but on the ground, trying to keep on top of an ever-shifting situation. He works feverishly with the bright minds around him for clever solutions to unpredictable problems and to keep everyone focused on the important goals in front of them. In other words, he’s a game producer. A game producer in their natural habitat. The role of production in games is often tricky to define as it can vary from studio to studio and game to game, but it’s similar to that of a Product Owner or Project Manager in software development and other industries. At Intercept, we have a team of three terrific* producers – including Fernanda Diaz and Paige Ketcham – whose job it is to ensure that development is running smoothly. We create and manage team processes, set goals and measure deliverables, coordinate cross-discipline efforts, prevent roadblocks, and do our best to keep everyone pointed in the same direction. Doing the job well requires strong communication, organization, multi-tasking, and leadership skills, along with a deep knowledge of the game you’re trying to make. As you can imagine, it’s a lot to manage across a game with the mind-boggling size and scale of Kerbal Space Program (I have incidentally come to understand flight director Kranz’s evident chain-smoking habit), but it’s also the most rewarding job I’ve ever had. Establishing or optimizing a workflow that lets your team’s talented artists, engineers, or designers do their job even better may not sound sexy, but the reality is that it results in a much better game — and that never really gets old. The KSP 2 dev team celebrates a successful milestone On the KSP2 team, production’s fingerprints are everywhere. One day, we may be helping sort out the pipeline for creating new parts (What are the requirements for the part? Who will do the modelling and texturing? How many parts are needed and how much time do we have?) and another you may find us sort through bugs from a recent playtest (What is the priority of this issue? Who can help fix it on the dev team? When should it be looked at? Who replaced the Poodle engine with an actual dog?!). We are intimately involved in practically every aspect of development, which keeps us on our toes and no two days from being quite the same. Of course, in order to get the answers to a lot of these questions and to ensure that the whole team is on the same page, we make use of another superpower of ours: Meetings. It’s a terrifying power, one that has been known to break lesser men (noted Kerbothropologist Paul Zimmer among them) and one we do not wield lightly. Running a meeting well is a criminally underrated skill and one that is essential to keeping a diverse, multi-discipline team moving forward hand-in-hand. The normal dev-team response to me scheduling a meeting Perhaps our most important responsibility, however, is managing the team’s short- and long-term tasks. Like much of the software world these days, the KSP2 team runs on a version of Scrum. Every three weeks, we gather our teams to review the previous cycle’s work, discuss how to improve our processes, and then get alignment on what the goals are for the next three weeks. There’s a lot of overhead involved in keeping a team of 30+ people busy, so we are constantly juggling a backlog of tasks in JIRA, our task-tracking software, so that the tasks are correctly prioritized and groomed (read: documented and clear). For long-term planning, we build and maintain a development roadmap. A roadmap is simply a development schedule that lays out major milestones and when game features will be built. Some sections of the team — the part and planet artists, for instance — have their own roadmaps, but all development efforts are coordinated around a central roadmap for the entire project that is constantly being refined with adjustments to specific features and new estimates from the team itself. Even NASA’s Artemis team has a roadmap: Though, where they’re going, they won’t need roads We talk a lot about the roadmap on the production team because everything stems from it. No games are made by accident and one as complicated as Kerbal Space Program requires a lot of forward planning to ensure that our rocket leaves the launchpad on time and in one piece. In future dev diaries, I hope we can give more insight into different aspects of production work as I barely scratched the surface of what is involved in this role. We didn’t get to cover our coordination with the marketing team or Squad, our instinctual need to document everything, or our unshakable convictions as to why Google Docs is a poor substitute for traditional Excel sheets! But I’ll just have to leave you with that tantalizing teaser — nothing gets people more excited for a dev diary than promises of spreadsheets! … or maybe that’s just a producer’s thing. *: I’m admittedly biased View the full article

View the full article

Have you ever pulled on a door that was meant to be pushed? It’s a frustrating mistake that often leaves you blaming yourself, ultimately bringing your intelligence into question! HOWEVER, the fault is not yours! It lies in a failure in the door’s design to communicate the action you should take. Hi, my name is Levin [ luh–vin ] Sadsad. I’m the Lead UX/UI Designer here at Intercept Games. Welcome to my Ted Kerbal Talk! “What even is UX/UI?” one might ask. Well, it stands for User Experience and User Interface. Where Game Design provides KSP2’s vision, the UX Team delivers the look & feel. Generally speaking, we’re the architects for the game in that we make the Game Designer’s ideas tangible. We work alongside them to create and construct the tools and equipment the player interacts with to play the game! Fun fact, it’s often said around the office that we’re the “Yang” to Game Design’s “Yin.” [*] [*] No one actually says this Anyway! I mentioned we maintain the look and the feel of the game—feeling in the tangible items, but also the emotional senses. How do we deliver on the latter? Emotions are directly linked to cognition, or one’s means of collecting and understanding information. Simply stated, when an action is taken, and the result doesn’t line up with expectations, the player experiences frustration. We want to align expectations of how a player perceives things working to how Game Design envisions them working. “But WAIT! What does that have to do with pulling on doors and communication?” I’m glad you asked! A common misconception is that our profession is solely associated with how things look: buttons, icons, etc. While the presentation is essential, UX is more of a conversation, one between the player and the game. Our goal is to make that dialogue feel as fluent as possible to be clear about the actions a player can take, can’t take, or has taken. We achieve this by addressing the player’s senses: sight, sound, and touch. We converse, not only through the user interface, but the game inputs, player camera, visual FX, sound FX, animation, and environment. An example of this multidisciplinary effort can be found in KSP2’s VAB among the part interactions. For the player to understand all the actions they can do or have done, we’re providing several new assists. This’ll allow the player to focus on their build and not be concerned with proper part connection or different camera behaviors across scenes. Those assists are: Expose both stack and surface attach nodes to distinguish the differences between the two. Add welding spark FX and following sound effects once a successful part connection is made. Display a part connection line to show when and where attachments can be made. Provide an on-object icon of the Assembly Anchor (prev. known as the Root Tool). Without having to interact with an assembly, a player can identify what part to grab to move the group as a whole. Unify the camera interactions across the build experiences of the vehicle assembly and colony assembly editors to remove camera confusion between the different builds. Enlarge the assembly buildings to provide more space within which to work. Part Connection Mockup These are a subset of small refinements that add up to allow the player to spend more time enjoying the game’s experience instead of figuring out how to play it. We like to think of every interaction the player makes as a series of tiny trust falls between them and the game. The more clear the conversation between the two, the greater the feelings of understanding, control, and satisfaction! Ultimately we, at Intercept Games, believe in the importance of space exploration and Kerbal Space Program’s potential to deliver that message to the community as a whole. From the seasoned Kerbonauts to the budding cadets, we want everyone to enjoy their journey through our game and not get caught up at the door. – UX Team We Fight for the User! (That’s you!) View the full article

As a licensed Kerbothropologist, it is my distinct honor, pleasure, and purpose to study and report upon the dominant, sentient, bipedal species living on Kerbin, their home planet. Kerbals Yes, Kerbals. A spacefaring species, brimming with optimism, ingenuity, and a dangerous abundance of “Can Do!” attitude (with almost no regard for “Should Do?”) You may already be familiar with this inspiring species, but I have the distinct honor of diving deeper than most into the societal, cultural, and psychological aspects of our little green friends (even in their space suits they’re not as tall as the average adult human.) For example, despite sharing the same surname, Kerbal astronauts and employees of the Kerbal Space Center do have ways of exhibiting their individual personalities. While regulation uniforms are required for all space center personnel, hairstyles and garment colors are not so strictly enforced, seen here in these candid shots I took during my visit to Kerbin. One observation of note was a bit of harmless drama discovered among the staff at the Vehicle Assembly Building. It appears that the experts responsible for the actual rocket science have a friendly rivalry with the staff responsible for building and engineering said rockets, as illustrated here in a few more candid photos. As flight training happens daily at the KSC, I had the opportunity to witness the paces they put themselves through. Here, I noticed distinct differences in the performance and attitudes of each Kerbal astronaut, which I will try to describe and illustrate below: I first noticed that the demeanor of each test subject, while waiting for their tests to begin, differed to such a degree that I labeled the observation “Optimism.” Some astronauts sat uneasily as they waited, while others seemed very amused with themselves. As testing began, I noticed almost every Kerbal appeared to relish the strenuous challenges, but each only enjoyed them for so long before their mood soured. It shows a distinct cultural enjoyment of thrill seeking, not too different from our own delights with carnival rides. Their words for these phenomena were puzzling (and wholly unpronounceable as their language has a literal backwards sounding quality to my human ears.) They seemed to have two interchangeable terms for what I would have called “thrill seeking” and “fear.” While both of which indicate some level of bravery, one refers to their enjoyment of thrills and can be used to tease one another, whereas the other term is used to refer to the limits of their bravery in a more serious tone. I have casually labeled them “Stupidity” and “Bravery” in the chart, for improved context. On the subject of “Bravery” and its limits, I witnessed a range of responses in the breakdown of their resolve. I have attempted to organize these responses into 3 stages as illustrated below from clips of their test footage. Stage 1 Panic — The Kerbal shows clear concern, shaking with energy, or anticipation, but otherwise in control of themselves. Stage 2 Panic — As the situation worsens, each astronaut seems to kick in to an “I Can Fix This!” state of mind, and instinctively attempts to address the danger by any means within their reach. Stage 3 Panic — Beyond some point, many Kerbals seem to lose confidence in their ability to fix the situation and begin to flail indiscriminately in what can only be described as pure panic. Of note: Not all Kerbals seemed to reach Stage 3; at least, not in the tests I observed. Others even fell unconscious before exhibiting some of the later stages. As for unconsciousness, I observed a limit to the amount of pressure and jostling each test subject could withstand before they appeared to grow sick, or perhaps drowsy, followed ultimately with unconsciousness. I labeled their capacity to stay conscious as “Constitution.” I have much left to learn about our spacefaring friends, but they inspire me every day to stay curious, and be brave in the face of uncertainty. As for now, I must leave you to continue my obligated studies, as the grants I’ve accumulated require it! Luckily, I love my job, and lucky for you, there should be a new video coming out that will further sate your curiosity. -Paul Zimmer (Kerbothropologist, 3D Animator, & Content Engineer) View the full article

Hello! My name is Rafael Calonzo Jr., and I am the Senior 2D Animator on Kerbal Space Program 2. You may be wondering — as I did when they first approached me for this role — why would a realistic space travel simulation need two-dimensional animation? Let’s go back to a weekday morning in 2013. Nate Simpson (KSP2 Creative Director) and I are working on an ill-fated mobile title. He mentions how tired he is from playing some game into the early morning hours and — as proof — sends me a link to a forum post featuring his very complicated (yet still plausibly realistic) spaceship. It was gathering ample praise from the other forum dwellers. I poke around the site as he continues to rave about the game’s unyielding faithfulness to real science and technology. I nod politely and promise to give it a try, but in my head I have already decided that some nerdy pastimes are too impenetrable, even for nerds like me. Four years and several jobs later, Nate inquires whether I’d like to join him on a new project that is basically his “dream game.” As he starts describing it to me, I interject that it sounds like that game he was obsessed with years ago that, full disclosure, I never actually tried. As you can guess, he confirmed that yes, that was the game, the new project was its TOP SECRET sequel, and actually it’s fine that I didn’t play it because now could I help make tutorials for people like myself? Tutorials? Nobody LOVES tutorials. They are the vegetables Mom makes you eat before you get any dessert. It doesn’t matter how essential those vitamins are or how fancy the veggies are dressed up, you just want to choke them down (or slyly spit them into a napkin) so you can get to the chocolate cake. Figure 2 It’s not rocket science (yes, it is) But from our very earliest meetings, we wondered how we could recapture that cohort of players who tried the original KSP but would give up before they got to experience the real “magic” of the game. However, to actually progress that far, they’d need to — NO BIG DEAL — learn a little bit of rocket science. What could we do to keep those players engaged, while stealthily imparting the skills and knowledge they’d need to really flourish? Eventually the question became: Is it possible to make tutorials that … sneak veggies into the dessert? Could we make instructional media that was approachable, with lessons that would creep into your head without you realizing? What would those tutorials look, sound, and feel like? We spent some time reflecting on what types of instruction managed to survive in our brains since childhood. Like most Gen-X kids raised by television, we could count to twelve before kindergarten because that pinball machine from “Sesame Street” looked cool and had a soundtrack that slapped. We can still sing about how bills and conjunctions function because of “Schoolhouse Rock.” We’ve won half the battles by knowing how to pet strange dogs and not hide in old refrigerators thanks to “GI Joe” PSAs. And as adults we binged dozens of Kurzgesagt explainer videos like the colorful, addictive-yet-informative fun-size candy that they are. Our super-unscientific findings: WORDS + MOVING DRAWINGS = IDEAS STICK TO BRAIN GOOD. Some of the concepts we experimented with in pre-production had mixed success. You could tell we watched and rewatched the classic music video for “Remind Me” by Royksopp (still so good!), whose “Airline Safety Brochure” style was fun but a bit labor-intensive. Especially when I tried to portray actual vessels and parts from our game. And unfortunately the strokes around everything were prone to making weird seams on the characters. Figure 3 Please turn off all personal electronic devices and 12 point outer strokes, Jeb At different points of pre-production, we even considered making the tutorials pre-rendered 3D, real-time 3D, or real-time 2D puppets. Eventually we settled on a flat, pre-rendered 2D style that would be easier on production and (hopefully) more legible for the player. Figure 4 Goodbye outer strokes, hello outer space Pre-production was also the perfect time to refine the content of the tutorials before we made any final assets. Each completed tutorial script was run through a text-to-speech utility to create “Robo-talkies” of the narration. Then I would draw dozens of corresponding storyboards and combine them with the Robo-talkies into an “animatic.” This picture book-style rough cut of the video gives enough of a sense of the visuals and timing that I can share it with the team. Figure 5 A storyboard from a scene I was really looking forward to animating, but it didn’t make the cut. Get well soon forever, Buzz. The completed storyboards and animatics for all 32 tutorial scripts added up to 47 minutes of animation — half an animated feature! Which is kind of a lot for one guy (me) to produce and more importantly, way too much for the players to sit through. So we redistributed the content, making skill-based lessons into interactive sequences, while reserving the animations for scientific concepts. Figure 6 We heard you liked planes in your rocket game Once we had our scope dialed in, we conscripted a ragtag production team to bring the videos to life. My fellow “Rafael” at Squad, Rafael Gonzalez, and a selection of other talented artists cranked out the cartoonified planets, backgrounds, and vessels in record time. Tom Witte and Cisco Martinez, two colleagues of mine from the CD-ROM Wars who’ve since graduated to the motion graphic world, lent their multitude of animation super-powers and made my life so much easier. Figure 7 Dream, build, fly… into the ground As much as we enjoy making these things, we know that nobody buys this game to sit and watch cartoons. They want to fly things and blow them up! Our sincere hope is that they’ll watch enough of these to know *why* their things blew up. And as the saying goes: Knowing is half the tutorial. KAY-ESS-PEEEEEEEEE… View the full article

View the full article

Hi, this is Paul Furio and I’m the Senior Manager of Engineering on KSP2. As I like to tell the software engineers on our team, I have two jobs. First, make sure all the code that makes up Kerbal Space Program 2 does what we expect it to do, delivers amazingly fun features, is highly performant and stable, and ships on time. Second, help every engineer on the team to grow their careers and become better versions of themselves. When I think about engineering for the next Kerbal chapter, I’m working with the engineering team to balance out a variety of different requirements. For example, how do we take advantage of the hardware capabilities of modern gaming systems and deliver an experience that is beautiful and cinematic? Obviously we’re building on an updated version of the Unity 3D game engine, which brings a large number of visual and performance improvements to the table. But we’re also working with people behind some of the biggest Unity features and plugins so that we can offer incredibly detailed stellar body surfaces from approach, through orbit, right down to surface landing, all while maintaining a smooth frame rate for our brave green astronauts. In Development Screenshot Next, how do we deliver an experience that grows beyond just a single star system? Because of the enhanced scale of the game, we had to update how we handle positioning. To quote author Douglas Adams, space is “vastly, hugely, mind-bogglingly big”, and representing the relative locations of ships, planets, and distant star systems requires a bit of cleverness. Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year. We could use double-precision floating-point values, but then we start to lose fidelity as the numbers grow larger, which leads to instability in physics and jumpy positioning as we move away from the origin. With interstellar travel being so important for Kerbal 2, we’ve solved this by implementing a Spacial Scene Graph at Interstellar Scales, which allows us to arbitrarily “break off” sections of space and simulate them with a high degree of precision while still fully understanding their physical and positional relationship to the stars and planets around them, and all while not sacrificing compute performance that might slow down frame rates or lead to spaceships that are more wobbly than our Kerbal Engineers intended! How do we deliver new spaceflight challenges and experiences? We’re enhancing our physics simulation above and beyond the original Kerbal Space Program to account for some more complicated orbital dynamics. One example that has already been shown in the trailer are the binary planets Rask and Rusk, which orbit each other. One approach to simulating this would be to have an invisible gravitational center point between the two worlds, but this would make orbiting Rask and Rusk just like orbiting any other body, with slightly different parameters for collision, and the side effect that ships would be drawn to the barycenter between the two bodies. We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly). Full system n-body gravity is, of course, not planned for KSP2, as it would be overly compute intensive and also require complex station keeping on all vessels in orbit that, we feel, distracts from the fun of the game. However, we look forward to how players will deal with, or take advantage of, some of the interesting properties of the special cases where physics gets far more interesting than we’ve grown accustomed to in the original Kerbal Space Program. A final exciting engineering challenge is around Multiplayer. My first role as a software developer in the games industry (several decades ago) was writing the network code for some automobile racing and real time strategy games, so I have a long-time passion for how we make our game experiences able to be shared between friends. We have dedicated engineers on our team to ensure that playing with your friends, docking at each other’s colonies, and trading resources is a fun and seamless experience whether you’re playing in the same room, across campus, or with friends who might as well be on another planet. Of course, delivering all of this in a stable, high performing manner, across multiple platforms, takes time. At launch, we want to ensure that the only crashes we experience are the onscreen “Rapid Unscheduled Disassembly” of our Kerbal-commanded ships. Despite the unprecedented challenge posed by the global pandemic, we’re still coding away on KSP2 from the safety of our homes thanks to the magic of distributed development, and the unsung heroes of our IT department, who have kept our team humming along. Every week we see new features added, and we’re super excited to be working towards delivering an amazing new experience for all our fans and players. View the full article

Today, we wanted to share with you the name for the studio dedicated to the Kerbal Space Program 2′s development: Intercept Games Here is an explanation of how the name came to be by its originator and Lead Designer on KSP 2, Shana Markham: You could argue that intercepting planets is the goal of Kerbal Space Program. You’re trying to figure out how to get this comparatively tiny rocket to meet up with a planet that’s moving crazy fast through an infinite space without running out of fuel or ripping itself apart. It’s a scary prospect. It’s a thrilling prospect. Developing for KSP 2 evokes the same feelings. We’ve got a beloved game that we want to do right by. We want current fans to find something to love all over again. We want new players to discover this gem of a game and learn something about our own universe in the process. Fortunately, an intercept course is planned. It doesn’t leave things to chance. We have industry veterans, and we have a team that is passionate about the product. We have experts we consult, and we’re working alongside Squad even as they’re continuing development of KSP. We have a committed publisher who is willing to take some big steps to ensure that the product that we send out into the world is the best that we can make. The name reminds me that the day to day of development can feel scary, but we’re set up for success. View the full article

Hi, my name is Shana Markham and I’m the lead designer on KSP2. I’m the “why” and “how” to Creative Director Nate Simpson’s “what.” I work with him to ensure what we’re building meets our vision for the game, and that it results in the most enjoyable and worthy successor we can build. I’m more of a scripting-and-spreadsheets sort of designer, so you’re going to get some “interesting” art here. Sequels are a balancing act. If we only added more content, that would be better done as DLC. If we revise gameplay wholesale, then we run the risk of not making a sequel anymore. How do we make sure we don’t fall to either extreme? By understanding where we came from and where we are going, and then framing our design around this context. We start by defining the key features and experiences of KSP — what we call our “pillars.” Ideally, anything we add or change enhances at least one of these pillars. For KSP, the pillars are: Sequels are an opportunity to do things that would be difficult to do through patches or DLC. We can take advantage of new technology that’s become more common for our players, apply the lessons learned from other games that have come out, and rework systems and content that would be too involved to do otherwise. If we did it right, then we’ve enhanced the game for our veteran players while enticing new and lapsed players to join in the fun. Our goals for KSP2 are: Make it easier for players to understand what is happening in the game, so they can confidently plan and execute missions Educate players on rocket design and space travel, then show them how to apply that knowledge to the game Explore next-generation space-program concepts, including new rocket technology, colonies, and interstellar travel Explore the possibilities of solar systems beyond our own How does this apply to our day to day? Let’s look at colonies. There are entire games dedicated to the creation and management of colonies. When we players see the word “colonies,” we have expectations for what that experience should look and play like. We also have reality to draw upon: Just think about what it takes to keep the International Space Station running. It’s easy for us to use that wealth of knowledge and propose new features to make colonies engaging and strategic by layering on resource systems and complex interrelationships between structures, colonists, and different types of colonies. Even with infinite time and money, KSP2 would not make a colony system as complex as a game that is dedicated to them. Why? KSP2 is a game about building and flying cool rockets, so our colonies serve rocket gameplay. We’ve minimized colony micromanagement to make sure that our players are free to build their next great idea and are not babysitting an interstellar empire’s worth of needy Kerbal colonists. We all know that Kerbals just need cool suits, snacks, and something fun to crash. When we talk about colonies, we frame the experience in terms of rocketry. The player builds a rocket with inflatable colony modules and flies it to a location to establish a colony. The colony synthesizes fuel to refuel rockets. Players fly missions to provide colonies the resources they need to become self-sufficient. The colony grows to allow players to build and fly rockets from these new locations, opening a host of new possibilities for missions. While colonies are subservient to rockets, that does not mean that colonies are a dry, minimal experience. We’re researching the mechanics of space colonization with the same attention to detail that we apply to vehicle parts and planets. We want players to build crazy orbital drydocks and mining colonies on stalactites. Colonies need to be fun to create and build up, and they need a wealth of possibilities. Nate describes this as a “toyetic” experience. If someone happily spends their play session rearranging the modules on their Ultimate Mun Spaceport, then we’re doing the right thing. Much like a toy, the experience is in how these modules fit together and give the player new things to do. Finally, while we’re responsible for the core experience, we know we won’t be the only experience. KSP has a fantastic modding community, and while our visions for colonies may differ, we need to make sure our systems are designed to be open for new interpretations. Each proposal we reject internally shows us the wealth of opportunities colonies have. Hopefully this gives a little insight into what we’re thinking about when it comes to design. We’re excited to develop this game, and we’re just as excited to see what you’ll make of it. Thank you! View the full article

Hi, I’m Aaron Lundquist, the Senior Visual Effects Artist on Kerbal Space Program 2. As an artist, I look at color, composition, and silhouette, but the little green scientist inside me wants to know the how and why. With that in mind, let’s jump on in! On KSP2, a major goal is to expand on diversifying the visual effects to reflect a more scientifically accurate depiction of what space exploration actually looks like. An example of this is showing the visual differences between an engine’s exhaust in an atmosphere vs the vacuum of space. Changes in atmospheric pressure directly affect how exhaust plumes look. Higher pressure compresses the exhaust causing a long and narrow silhouette. In a vacuum, the exhaust is wider, expanding outward as soon as it exits the bell nozzle. In addition to pressure, an atmosphere’s chemical composition can affect the look of engine exhaust. An atmosphere with a lot of water moisture will cause more vapor in the exhaust plume. This is a result of the high temperature of the exhaust vaporizing the moisture in the air, causing visible cloud-like trails. Another goal is to craft visual effects that reflect the unique fuel used by each engine. KSP2 features a variety of fuel types, some with pretty extreme qualities. To achieve this, we’ve reached out to subject matter experts to help determine how various fuels burn. “Does this fuel need an oxidizer?,” ”How quickly does it burn?”, “What temperature is it?,” “What color is it?,” and “Does it create soot?” were just a few of the questions we asked to help shape the effects. Based on expert answers, we developed color pallets for multiple situations: For explosions, we consider how it was triggered. This involves investigating various real world vehicle incidents. By looking at different types of wreckage, we can piece together key information. That sets an example for how and when to trigger visual events in-game. Using game logic, we can query specific conditions during destruction events. Examples include if a vehicle has fuel, what kind of fuel, whether it hit something, what type of thing it hit, is it in a vacuum, and so forth. We track quite a few variables in order to make sure that a pressurized vehicle with non-combustible contents reacts differently from a non-pressurized vehicle with combustible contents. Once we have the relevant game info, our system then looks for all vehicle parts in proximity to each other. If two or more parts with similar attributes explode at the same time, the system will combine these into one large explosion, as opposed to multiple smaller explosions. The goal is for each explosion to be its own special snowflake based on how, where, and why the vehicle failed — or, for some of us, how the vehicle succeeded. I hope you enjoyed a taste of our process. For me, learning about these details is fascinating and enriching. It allows me to improve my craft and keep growing as a professional. We can’t wait to learn even more when the vast knowledge of the KSP community chimes in. Until the next blog… Cheers! Aaron View the full article

View the full article

Hi! My name’s Nate Simpson, and I’m the creative director for KSP2. Welcome to the first official KSP2 blog post. In the coming months, the Star Theory team will be checking in here periodically to give you glimpses of what we’re making and how we’re making it. Now that the trailer’s out, I can finally tell the story of how we went from “it should probably have some rockets in it” to “whoa, this is making me cry” in less than two months! The story begins with Tom Bass, the head of Private Division marketing, and Ara Josefsson, the KSP marketing lead, who put together a trailer animatic and flew out to our office in Bellevue to show it off. This thing was monumental. Tom is a huge fan of The Right Stuff, and his trailer had all the hallmarks that made the film one of my all-time favorites: the score, the sense of adventure, the reverence for NASA’s golden age. The opening sequence showed a crowd of Kerbals gathered to watch Jeb blast off for the first time, and it was full of Spielbergian reaction shots of awed families watching history being made. Though we all loved the tone, we wondered if it was too nostalgic — after all, KSP2 is also about where we’re going, not just where we’ve been. Tom and Ara immediately pivoted into a deeper conversation about the soul of our game. I showed them Wanderers, an amazing short film by Erik Wernquist that offered brief glimpses of humanity’s expansion through the solar system. That video has always given me chills – the immense scale of everything, the increasing audacity of our interplanetary ambitions, how tiny we seem even when we’re creating space elevators and O’Neill Cylinders. We kicked around a few ideas, and Tom and Ara flew home to New York. To our surprise, they called us up first thing the next morning: did Star Theory have time for a surprise video conference? Something exciting was afoot! On the screen, Tom and Ara performed their new trailer idea – Ara held a series of flash cards on which he’d sketched storyboards (on the plane!) and narrated. Crucially, Tom also played music in the background. It was a song that we all recognized from the Build, Fly, Dream fan film created by Sean Esau for KSP (one of my favorites, and the first thing I showed our team when we learned we might get a crack at the sequel). We loved how M83’s music went with the images of a lander descending from a huge mothership and landing on an alien world. It was hard to deny they were onto something, and the idea that we could pay homage to Esau’s fan trailer – looking forward while acknowledging the past – was very exciting! Tom, aware that history was being made, took this pic of Ara and his flash cards I asked for permission to try putting together another animatic using the same music. Time was running out, but to my everlasting gratitude, Tom let us have one last crack at it. Over the following week, I put together an animatic that told a story about Kerbals progressing from tentative first steps on the Mun to building an interstellar civilization (with some Kerbal-style mishaps in between): Tom and Ara loved it! We were off to the races, and there was no time to lose. PD got in touch with the animation geniuses at Halon, who dove straight into planning the final trailer. This project presented unique challenges – a host of new environments to create, characters to animate, and most annoyingly (for me), two dozen unique vehicles to design. We all had our work cut out for us. Here at Star Theory, artist Steve Snoey and I divvied up the vehicle list and got to work assembling all the vessels and bases from part assets that had been created for the game (there was no time to test the rockets in-game, so we’ve been relieved to witness fan recreations actually flying in KSP). Then it was all in Halon’s hands. Over a month of weekly video conferences, we witnessed the miraculous birth of a full-fledged trailer. We nitpicked about everything from vehicle exhaust to solar panel deployment speed, and someone joked that Halon probably has a voodoo doll of me that’s completely full of pins by now. It’s a very funny joke that I’m sure is just a joke. Regardless, Halon delivered a jaw-dropping trailer in an astonishingly short time. We were still asking for big revisions the day before the end of Halon’s contract – we needed a cool reveal for the company logos at the beginning and nothing was clicking. Halon must have done about a million versions of that first shot, and it was only on that last morning that something clicked and they came up with something we all loved. It was done. Halon had knocked it out of the park. We couldn’t show it to the world just yet, but we could show it to Squad, the creators of the original Kerbal Space Program. Was it true to the spirit of Kerbal? Did they like it? Did we do good? Thankfully, they agreed that it was a trailer for the ages. With that vote of confidence in our back pockets, we only had to keep the secret for a few more days. I passed the time by watching the trailer on repeat. That part where the radial boosters decouple still gives me chills. To give you an idea of how badly we needed to let our Kerbal flags fly — the Star Theory and Private Division folks who flew to Cologne to attend the trailer’s premiere at Gamescom all wore hidden KSP undershirts, to reveal at the moment the trailer debuted. It turns out the grand t-shirt unveiling was kind of anticlimactic, as it happened at the back of a very large auditorium while the audience’s attention was focused on the actual trailer. But still, it felt great not to have to hide anymore! (Left to right) – Michael Cook (Executive Producer, Private Division), Nate Simpson (Creative Director, Star Theory), Nate Robinson (Senior Producer, Star Theory) Opening night jitters are no joke. I felt like my heart was going to pound out of my chest as the opening notes of our trailer began. This was it: after all the dreaming and arguing and obsessing behind closed doors, now was the moment when we would officially join the greatest game franchise of all time. Never has a trailer felt so long… how would people react? Would I need to put my overshirt back on and run for the exit? There were laughs at the Kerbal reveal! A good sign! And people cheered at the end! And then the internet exploded. I told everybody beforehand: “I’m not going to read any of the YouTube comments. I’ll be on Reddit if anybody needs me.” But then the weirdest thing happened — somebody started digging through the comments on the trailer, and they were having trouble finding anything but enthusiasm. We started to get hopeful. Then Scott Manley, the human embodiment of all that is Kerbal, appeared in the comments. “Don’t mess this up,” he said. The dude who taught me how to play this game was now talking to us about the thing we were making! Holy cannolis, this is real! We’re doing this! — A week later, Scott came to our office to see what we were working on up-close, and he was joined by a gathering of heavy hitters from the Kerbal community, including EJ, Jatwaa, DasValdez, ShadowZone, BadNewsBaron, Snark, LinuxGuruGamer and Galileo. This was another nail-biter for us — our assumptions would be questioned, and this would be our first chance to find out if we’d misstepped. They’re a very smart bunch, and they weren’t going to pull any punches. To our huge relief, they walked out of the meeting even more excited about the game (and having shared a few useful insights with us over the course of the day). The gathered KSP experts do their best to embody “explodiness” Then we all went to see the Apollo 11 Command Module at the Museum of Flight, where I was reminded that these guys really know their rockets — three of them (you can probably guess which three) were mystified that there was a tiny protuberance on the capsule that they couldn’t identify. A handy reminder that this game has not only the friendliest, but also the most knowledgeable, fanbase in the world. Speaking of fans, we finally got to meet a few of you in person at PAX over the following weekend, where many of our dev team members helped out at the booth. Huge thanks to everybody who made it out to see our gameplay presentation, especially given how long many of you had to wait in line to get inside! As slow as that line was, it was also a great chance for us to get to know a few of you — old fans, new fans, space industry professionals, even a few kids! Our team handed out KSP flags after the presentation ended, and while we were happy to sign them, we were even more excited to collect your signatures on our flag. Check this thing out: Matt Cech, one of our cheeriest engineers We heard so many great stories — engineers who’d been inspired to pursue aerospace careers by the original KSP, folks who were spooked by the original game’s hardcore reputation but had decided to give it a try anyway, fans of the original who couldn’t wait to experience the same magic all over again, and even kids who wanted to talk to our engineers about what it’s like to program games (I’m told it’s hard). We had so much fun! We can’t wait for the next opportunity to share our progress with you all. In the meantime, we’re still hard at work in the radness mines, discovering and extracting new veins of totally sweet gameplay. I’m very sorry for this last sentence, but I’m leaving it in. Thanks for reading! -Nate S View the full article