Jump to content

Intercept Games

KSP Team
  • Posts

  • Joined

  • Last visited

Everything posted by Intercept Games

  1. Hello, my name is Jim Peck, a.k.a Just Jim here on the forum, and today I am excited to talk to you a little bit about writing for KSP2! First I should mention how this all happened. A lot of newer members probably don’t know the story, but it really all started here on the forum. I first discovered KSP (and this forum) about 8 years ago and was instantly hooked. Something I really liked was all the fan-fiction stories being written. I have been fascinated with space and science fiction all my life. I have also been writing all my life. I still have piles of notebooks lying around filled with all sorts of fun stuff I may revisit someday. So I decided to start my own fan-fiction story “The Saga of Emiko Station”. And it was really popular. A couple years later I was still writing Emiko when I heard about a QA position that was available for KSP, and I applied, and to my delight I was hired! I spent the next 3 years working on KSP and learning a lot about how the game really works. And having way too much fun. As far as KSP2, I was honored to be one of the very first in Squad to be given access to the game, and it gave me a lot of insight for what was to come later on. Last year I moved over full time to help on KSP2, and a few months ago I was super excited to become a full-time KSP2 writer! So enough about me, let’s talk about the game. To be clear, when I say I’m a writer, I do not mean writing/designing the game on a large scale. Those are design decisions that fall mostly on Nate Simpson, Shana Markham, and the rest of the senior staff. My job is writing out all the text that is used in the game, and it is a little more involved than you might think. One of the most important aspects of my job is maintaining the spirit and flavor of the original KSP as closely as humanly (Kerbally?) possible. I can safely say everyone on the team feels the same. KSP is incredibly unique and continues to be so. Not just for the game physics, but also because of the Kerbals. Kerbals are a vital element in adding some fun and humor to what is otherwise a very challenging subject. But the game is not about the Kerbals directly, it is about building and flying rockets. It's up to me to help bring life to our little green friends with the writing; help the players know who they are, how they think, what is driving them to the stars. OK, so one of my largest and most involved tasks is writing up the text for all the parts. There are somewhere around 600 parts currently planned for KSP2. I do not have the exact number off-hand, but somewhere around there. And this is a very big chunk of what I’ve been working on these past few months. For each part in the game there are 4 items I need to focus on: Title Part titles can be a model or designator number or a name, and often both, which can get a little confusing, especially to newer players. KSP parts will keep their existing titles, such as the FL-T400 fuel tank or LV-909 "Terrier." To make things a little more understandable, we added subtitles. Subtitle Subtitles are more descriptive than our colorful titles, and they help players identify a part without having to dig around the tooltip. This is especially handy in cases where we got a little crazy with the titles: Title: Advanced Photonic Generation System Subtitle: Lightbulb Manufacturer All of the existing KSP manufacturers will be in KSP2, along with some new ones! We are giving them a little more of a voice and influence, some of which is reflected in how they name or describe the parts they make. All of this is to add some variety and humor while also maintaining a sort of consistency between parts and manufacturers. For instance, despite being fierce competitors, Kerbodyne & Rockomax have very similar writing and naming styles (but would never admit it). C7 Aerospace considers themselves a little “better” than the rest of the manufacturers and would never, ever admit to a mistake, whereas Jebediah’s Junkyard would pride themselves in inventing a new engine by accidently exploding a bar-b-q grill. Description Part descriptions are where things get really fun, but also a little more challenging. In KSP, part descriptions were funny, but sometimes not very descriptive. There is a real opportunity for them to tell you about the use case or the science behind a part, so we are making these more descriptive while also including the Kerbal style of humor whenever possible. The biggest challenge is I have to do all of this with 300 or less characters, including spacing and punctuation. This is to ensure they fit into the pop-up window properly, but means I have to choose each and every word very carefully to make these as beneficial and funny as possible for the players. For new KSP2 parts the process is very similar. I will give a new part a title and subtitle that matches up with other parts of that type, and assign it to the most appropriate manufacturer, including several new KSP2 manufacturers. One of my favorite new manufacturers is: Shakeproof Atomic Fusion Engines (SAFE) Shakeproof Atomic Fusion Engines are the designers and builders of some of the newer tech engines, such as the Orion-style fission engines shown in our previous videos, and guarantee all their products to be completely safe. I mean, it’s right there in their name, so they must be safe… right, right??? While I’m on the subject of the newer technologies, one of the really fun things I get to do is researching the new techs. Everything we’re doing is grounded in real science, even if some of it is theoretical, and all of us on the team spend a great amount of time making sure everything is as accurate as possible for you, the player. Now once I’m done writing these, they are all checked over (and often tweaked) and approved by our senior design manager: Shana Markham. And let’s not forget our legal team. They also have to approve everything I write, and are another reason why finding the exact wording is so important. Once everything has been approved it must be implemented into the game. There are tags in the game everywhere, each with its own text string attached. Usually the person(s) working on the feature will do the set-up, I just provide the text. It is a huge process, and I am grateful for all the work that my teammates put into it. Another very important part of the writing process is we are localizing KSP2 into several different languages. This means we have to be extra careful about the writing process in general, as well as finishing far enough ahead for our localization teams to have enough time to translate everything. Sometimes there might be an issue with a particular translation, such as how a joke is perceived in a certain language, and we need to work out the proper wording. I helped the KSP localization teams quite a bit and I had a lot of fun. It can be a really unique and interesting challenge playing the game in the different languages, and I got quite good at it after a while. OK, so this does not just apply to parts. It is an example of everything that must be written for the game: experiments, the tech tree, celestial body descriptions, etc, etc... Every written bit of text in the game goes through the same process. Literally thousands of text strings that must be translated into all our different languages, and then implemented into the game in order to inform, teach, and make our players laugh and have fun. And that’s it, that’s what I do. Best job ever!!! One more thing. I would like to point out that we all work on this together. There have been a few times where I was stuck on a word or phrase and posted it on our slack channel and the next thing I knew I had 5 or 6 terrible jokes or puns from the rest of the team to choose from… And what would KSP be without the occasional horrible joke or pun? Seriously, we are a very tight-knit team, and we have a lot of fun, and I wouldn’t have it any other way. I’m going to end this with one last note. To those of you that want to be writers, or whatever your dream may be… Please don’t ever give up on it. If you like to write, then write, and write a lot. Not for money or attention or hits on the internet. Do it because you want to. The rest will come later. Trust me, I’m living proof. -Cheers Jim
  2. Hi, I’m Jamie Leighton (JPLRepo). Yes, I am, or was, one of the Lead Engineers for KSP1. As you probably all know (since it was announced last year), we have stopped development on KSP1 and the KSP1 team have now transitioned over to KSP2. I am now a Senior Engineer on the KSP2 team, and my job is to technically design, build and implement the systems and technical functionality we need to make KSP2 a fantastic game. Of course, having worked on KSP1 for many years, I can apply all my KSP knowledge, familiarity, and learnings from spending years on KSP1 to solving some of the bigger problems we had with KSP1. With that in mind, today we are going to talk about just one of the many things I’ve been working on, the KSP2 Resource System. There aren’t any glitzy visuals, pictures, or videos we can show you for this system, but it is a fundamental underlying system that is critical to the function of rocket ships and planes. Sorry if this gets a bit too technical for some, but without further ado, let’s go! The KSP2 Resource System In KSP2 The resource system consists of two main components: The Resource Core Subsystem The Resource core provides the building blocks for the resource system for defining, storing and accessing resources. It contains definitions and data for all resources in the game. Resources are stored in containers and there can be multiple containers on a part. Containers on a vessel can be grouped into collections based on various parameters – such as the resource type, a particular priority, in order of hierarchy and so on. This is all managed “under the hood” by the Resource Core Subsystem. The Resource Flow Subsystem The Resource Flow subsystem provides the management, graphing query and request brokers to manage all resource flows in a vessel and is dependent on the Resource Core subsystem. Fuel and resource flows between parts are handled via resource requests. For any part on a vessel and a given fuel flow mode and type there is a corresponding sequenced group of containers (created and managed by the Resource Core Subsystem mentioned above). The Resource Flow Subsystem is split into two halves: Flow Requests – which consists of the Resource Flow Request Broker is responsible for marshalling resource requests and interfacing between requestors (usually Part Modules) and the vessel’s Resource Flow Manager. Flow Management – which consists of the Resource Flow Manager, Resource Flow Priority Query Solver and Resource Flow Graph, is responsible for creating and caching the resource container groups and processing Flow Requests. KSP2 Resource requests are rate-based, which is to say that they are “set and forget”. A requestor can setup a flow request and specify the units of a resource it wants at a fixed rate per second. The resource system will automatically continue to process resource requests at the rate specified and provide a request response to the requestor. It will continue to do this, even if the resource runs out, until the requestor turns off the request. The requestor can adjust any of the resource request parameters at any time (such as the amount requested per second) and the resource system will automatically begin processing the request with the updated details. Like KSP1, KSP2 resource requests can also be on a once-per-update tick of the game. n KSP1, one of the most common issues was that resources could only be accessed, consumed, and generated if the parts of a vessel were loaded into memory/within physics range. What we referred to as “loaded” or “off-rails”. In KSP2 these issues are no longer a problem/restriction due to the KSP2 Resource System being Architected and built from the ground up. All of the components of the Resource System live and execute in the Simulation side of the KSP2 Architecture which means they are independent of physical objects and parts. Hopefully this gives a little insight into just a small part of what we have been up to when it comes to building KSP2. Until next time, Thank you! View the full article
  3. Hi, I’m Eric DeFelice, a graphics engineer on the KSP2 team. My job is to create technical solutions to the graphics features we have on KSP2. One of the most obvious of these systems is how we generate, position, and render the planets in the game. We need a system to render the planets while in orbit and interstellar travel, as well as up close, on the planet surface. We want transition between these distances to appear as you would expect, as you get closer to the planet surface, you just see more detail. How do we solve all the problems associated with a graphics feature such as this? Can we just use traditional approaches for level of detail? Lets dive a bit deeper into how we solve this problem in KSP2. I’ll try to give as much detail as I can without having this take an hour to read… Basic mesh rendering & LOD systems Lets start by looking at how most meshes are rendered in KSP2 (and most games for that matter). Generally, the mesh data is sent from system memory over to the GPU, where shaders read it, place it at the correct pixels on screen and output the correct color given some material properties. We could try and use this approach for our planets, but there are a couple big issues we would have when trying to achieve the level of detail we would like. The biggest issues we would have revolve around the memory usage that it would take to store all that vertex data for planets that are as large and detailed as we have in the game. We could mitigate these problems with level of detail approaches, and perhaps trying to break up the planet into chunks, so we could only load in the chucks that are relevant. GPU tessellation is also a possibility, but that wouldn’t really give us much control over the terrain height. One other big issue has to deal with the size of our planets and precision issues when trying to position the planet in camera projection space. I’ll talk more about this shortly. 002_precision_issues.mp4 Pre-Alpha, Not Final Given these problems, we don’t use this basic approach when rendering planets up close. We do however use this basic approach when rendering planets from further away. This allows artists to have full control over the look of the planet from this distance, and is a good starting point to add more detail to as you approach the planet surface. Planet Positioning Another core gameplay feature we have to keep in mind when rendering the planets is that their position may be moved around relative to our floating origin (for more info, see the previous dev blog by Michael Dodd). For our planet rendering purposes, this means that our planet center will usually be further from the origin than its radius. If we defined the planet vertex data in model space, then during rendering, when we transformed its position to camera projection space, we could possibly be dealing with some large transformation values. If we then are viewing the terrain while it is close to the camera, creating very small distances in camera space, we may have some visual artifacts (as seen above). How do we deal with this possible problem? Well, one simple solution is to generate the vertex data so it is relative to the floating origin already. That way we don’t have to deal with the model to world transformation, keeping the position values in a reasonable range. So now that we have our key concerns listed, we can finally look at how we solved these problems in KSP2. PQS System Overview for KSP2 In KSP2 we use a very similar PQS (procedural quad sphere system) that was used in KSP1 (here is much more detail in the basics of that system). We have made some updates to the system, namely that we now generate all of the planet mesh data in compute shaders. This planet vertex data never gets sent back to the CPU, and we just send a procedural draw call to the GPU to render the mesh with the compute buffer data. We do determine quad sub-divisions in a similar way as KSP1, but we generate the output mesh positions relative to our floating origin, instead of relative to planet center. When calculating each vertex position, we also calculate the height, slope and cavity for the mesh so that we can perform procedural texturing in the planet shader. One caveat we needed to account for in our procedural parameter calculation is that we need to make sure we have stable values for any given position on a planet. This is needed because we don’t want the texturing to visually change at a given position, which could occur if the slope changes at that position because of mesh tessellation. For tessellation, we have to balance the level of detail we want at various distances with the performance concerns of generating more vertex data. The goal is to bump the level of detail for the terrain at a distance that isn’t really noticeable, so we don’t have a ton of visual detail popping in. We are constantly improving in this area (for reference, here is some previous footage of our planet tessellation tech). 004_gurdamma_flyover (2).mp4 Pre-Alpha, Not Final 005_minmus_flyover_wireframe.mp4 Pre-Alpha, Not Final One other feature we have to help improve performance is basic frustum culling. Since we don’t have a bunch of mesh data on the CPU we can’t rely on traditional approaches for culling, so we have to do this on our own. Since we already have a bunch of quad data, we might as well just use their positions for this purpose. On the CPU we can determine which quads are within the camera frustum, and only generate visual mesh data for those. This prevents us from doing a bunch of work on the GPU that we know will be thrown away later, since that part of the mesh isn’t even visible. 006_gurdamma_occlusion_culling.mp4 Pre-Alpha, Not Final PQS Collider System Overview Terrain colliders need to be created by this system as well, since they rely on the mesh data for the planet. There are a few differences in the requirements for collision however. We no longer want to tessellate collision mesh data based on distance from the camera, but rather on distance from possible colliders that could hit that terrain. Because of this, we need to keep track of separate collision quad data. We also can’t perform the same frustum culling that we do for the visual mesh, as a vessel could be out of view when it collides with the terrain. Can we still do some sort of culling though? You guessed it, we can. We just cull any terrain colliders that we deem too far away to possibly have a collision in that frame. This does the same job as frustum culling does for the visual mesh, prevents us from doing a bunch of work on the GPU that we know is useless. 008_gurdamma_collider_tool.mp4 Pre-Alpha, Not Final 007_gurdamma_collider_visualization.mp4 Pre-Alpha, Not Final Everything coming together Hopefully I gave you some more insight into how we generate and render our planets in KSP2. The key goals of the system are to provide a high level of detail of the planet at all distances while maintaining a solid frame rate. There are many unique problems in KSP2 compared to most other games I’ve worked on, so we definitely had to get creative with our solutions. One final tidbit I’ll leave you with, is our system for how we transition to our PQS generated mesh from the low LOD mesh. Borrowing a technique from basic LOD systems, we actually just perform a cross-fade dither between the two meshes. And lastly, all the systems coming together! 009_minmus_crossfade_dither-1.mp4 Pre-Alpha, Not Final 010_gurdamma_vessel_collision.mp4 Pre-Alpha, Not Final View the full article Jon-Dev-Blog-Exhaust-Throttle-and-Pressure-Transitions.mp4 1060038740_004_gurdamma_flyover(2).mp4 005_minmus_flyover_wireframe.mp4
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  • Create New...