Frequently asked questions

For information on expected game content, see Planned features.

Game design

Art style

The art style is under going changes but is planned to be similar to KSP/KSP2 with consideration of real-life counterparts. KSP mods such as Restock/Stockalike are considered inspiration.

Whimsical (KSP) vs serious (JNO) tone

The overall tone will maintain a certain amount of whimsy, given the choice of kittens as a mascot, but still be handled seriously.

Wobbly rockets

HarvesteR has developed an internal stress model that does not generate wobbling. This model is likely referring to his work on KitHack Model Club.

Implementation of parts and/or procedural

Main article: Part

Will the game be "Rocket Lego" like KSP, or "procedural everything" like JNO?

Answer by Dean:

Parts are intended to be (but don't require) to be made out of smaller sub parts. This allows us to batch render them and makes creating stuff easier. It also means you could make custom parts, run multiple fuel line connectors, etc... Parts are then really just a collection of smaller parts. It means someone can just play the game more like traditional KSP and place blocks - or they can make their own standards and have multiple lines connecting different fuels. Hopefully I explained that well enough. Think about default blocks having a central core of fuel connectors, but you could make your own parts from the subparts that allow you to have two separate fuel lines in the same block that would connect if a fellow connection matches in the part above.

And an answer from JPLRepo on Discord:

Think of it like this. A part consists of multiple other parts. The game will come with a series of compound parts.. eg, tanks, engines, cockpits, but the player/modders are able to construct their own compound parts and use them.

Some examples: A tank will consist of several fuel container parts, a fuselage part and end cap parts. A deployable solar panel consists of several single panel parts all connected together.

And another answer from Dean on Discord:

We haven’t really settled on the design stuff there but for parts absolutely like wings and such. But generally some of this might be encapsulated in our “sub part” system. So you’ll still be using prepared parts mostly but you can go into a sub editor and fiddle with that part.

Think how universal storage 2 lets you pick from a few options rather than a pure tweakble

More details can be found in the Parts wiki article.

Solar system scale (RSS and fictional system)

From Dean in the Discord FAQ:

The core game data is essentially a mod, so anything we do with the game is open for modders to change. This means our core focus is on providing a base solar system, with ease of use for modders to add their own.

At this stage our current thinking is basically do do somewhere between current KSP and x2-2.5 current KSP size for both the bodies and their orbits. In other words, we are aiming to replicate the same feeling, commitment, and challenge of existing KSP. We feel like base KSP is a great compromise between many factors when it comes to scale, and so we are not trying to reinvent that - instead focused on solid datastructures and ease of development for modders to fill any gaps.

Use of Real Solar System data a this stage is for testing and development, since it's readily available, and a fictional system will be made later

Caves

Caves will not be implemented in the game for a variety of technical and performance reasons.

Kittens as characters

Main article: Kitten

From Dean on Discord:

[Kittens] weren’t “chosen” (at least for now) because they were a great idea. They were chosen on the balance of a variety of things and because they were the “least disliked” of our options that also had the least roadblocks

This project though is focusing almost all of its ambition on the technology and simulation. Which, is quite ambitious really. So that’s why we tend to make a lot of other decisions that are very safe. And by safe I mean, low development risk

We wanted kiwis too but there is not a clear obvious pathway to animating them simply. So they are extra development risk and time

Kittens, especially as concepted so far, are very easy and very forgivable for animation and rigging

In a long comment on reddit, he explained that he really wanted to do kea in KSA, but there were serious technical issues since they would not be traditional bipeds. Kittens ended up winning over kea because they are "extremely low risk, they use known solutions and techniques, and they’re insanely easy content wise to produce."

Kitten body proportions

From Dean on Discord:

I definetly understand that there will be many people who'd want us to head away from the proportions we have (which are very close to the kerbal ones). However this is set in stone, for production, technical, cost, and risk reasons. It's a lot easier for our pipeline to have these "cartoonish" proportions. 50/50 [head/body] proportions make it much, much more forgiving for animations. Animations become 'representative" of an action. the animations can be almost garbage, and you won't really notice. even technically, keyframe wise, we could skip keyframes and you won't even notice

After the revised kitten model was shown:

In terms of proportions. We had meetings, discussions, and analysis. We made a decision. And then move forward with that. Daishi and others have already been factoring the proportion decisions into their work. This shows why it is important to make decisions like this early, and stick with them.

I’m not perfect; but I do think I’m consistent and I stick with things. Some game dev bosses might be kinder, but also some tend to change their mind a lot on this kind of stuff. But that gets exhausting

Animation and pipeline issues nearly bankrupted the studio. We are sensitive to that and nobody wants to go through it again.

Development team

Developers

Answer by Dean here:

My game studio is RocketWerkz, we've made a few games most notably ICARUS and Stationeers. Originally I made the DayZ Mod. Incidentally prior to that I actually made a lot of KSP mods, in particular the Component Space Shuttle (CSS) and was very active on the KSP forums.

Our studio actually was in the bidding to make KSP2 and we made it to the top three bids. The final step was a call Private Division. I put a lot of work with the into a good design document and opted to keep the focus entirely on this design and the technical aspects of the project - this was a serious problem for two of the people on the call who said we were the only pitch that did not contain art. Obviously out studio wasn't chosen.

We have been working on custom technology to allow us to build games that really scale for some time now. This is called the BRUTAL Framework which is similar in approach to the older XNA Framework. The desciption:

BRUTAL is a C# game framework that is designed to be complicated, slow, and difficult to use.

KSP Team members + RocketWerkz

> We have employed some of the original KSP and KSP2 team and a number of modders and expect the team to continue to grow. Here is a video demonstrating a unique approach we have been able to take with rendering, given BRUTAL gives us direct access to everything Vulkan can do.

> There is also a key person we are still sorting out the exact details for but I'd love to introduce them once that is done. I think this person is a key individual in our industry as a whole and our studio will be backing them and their future endeavors as well.

> The original crew are providing a lot of assistance and we are bringing technology, production, and approach from our own work.

This group of modders and vets includes HarvesteR (Felipe Falanghe, KSP's first developer), Blackrack (modder, known for Volumetric Clouds in KSP1 and worked on the same for KSP2), JPLRepo (modder and former KSP developer), and others.

Release plans

Main article: Help:Installing

The game is available for official download exclusively from Ahwoo for free with a give-what-you-want model. If contributions end up not being sufficient to support development, the game will pivot to a paid model that provides future updates to users if they made sufficient contributions, while keeping existing builds free.

Distribution platform

The game will not be available on other platforms such as Steam, Epic Games Store, itch.io, or others.

Linux and macOS

Kitten Space Agency has a number of BRUTAL developers using macOS and Linux, so the studio ensures that the game compiles and runs on these platforms. Native builds would require significant financial contributions to be considered economic, on the order of $10-20 million.

Console

A console release is not currently planned for and would depend on the success of the PC version.

Technical and modding

Floating-point precision

Most coordinates in games use Vector3 which is a spatial unit made up of three “floats”, which is a 32bit number format. This is useful for most rendering and spatial purposes, a floating-point variable can represent a wider range of numbers than a fixed-point variable of the same bit width at the cost of precision.

So essentially, a floating-point number will have a point at which noticeable precision begins being lost. If we define 1 unit as 1 meter, this often becomes noticeable at around 8 kilometres from the origin. You will see lots of “shaking” and other problems, but with rendering but also physics.

There are lots of possible approaches. For KSA the main aim is to keep the core architecture as simple as possible. The simulation is powered as much as possible by “doubles”, which are a 64-bit floating-point precision number. Rendering is then done with the camera always at zero, pushing any floating point issues far out to the edges of the camera where they are not perceptible. This approach has been working very well with the KEPLER simulation layer.

Combined with this on the physics level by having different contexts and handling the simulation of those contexts independently, we can avoid having to deal with everything in one “scene”. The key benefit of this context handling is performance but an additional benefit is being able to avoid precision issues with physics handling.

Simulation and rendering of parts

Rendering parts in batches

In BRUTAL a lot of our rendering is done using instanced meshes. So we don't have a "Renderer Component" like in unity, instead - each "thing" that needs to be drawn can batch together with all other like things. BRUTAL allows this new "instance" to be done directly to the GPU, which is even more efficient than commands in unity like Graphics.DrawMeshInstanced. In fact, we can send such information once to the GPU (either in a batch or each instance) and then ask the GPU to keep doing it until we stop. This means there is no conversation between the CPU <-> GPU which can give enormous benefits in both performance and memory churn. It is worth mentioning, this is not straightforward. There is no convience for us that engines like Unity/Unreal give - this means that all the buffers need to be configured - yet again our framework is named BRUTAL for a reason. But we trade that convience for scale, both in frame by frame performance but (perhaps more importantly) drastically reducing memory churn.

Simulating parts

A wider topic will cover our various "layers" and groupings in our simulation. I'll introduce a few concepts here, being Pieces, Part, Vessel. A "part" can be made or many pieces, these pieces can use common meshes that we can then batch together. A game that does this very well is Cities Skylines - where building are actually collections of other meshes. This allows us to maximize the use of batched rendering. There is then a common library of "meshes" that you can use when making parts - or you can just ignore them all and add in a custom mesh as well (very useful for modders with specialist parts).

This requires a much more detailed topic, but "sub part" is a key aspect of the current design. This very much is inspired by mods like Unviersal Storage, together with the technical implementation in AotR and games like Cities Skylines around batch rendering.

This is all a long winded way of saying that in an engine like unity/unreal - a "part" is actually quite a high-cost thing in the games scene. In BRUTAL and KSA, it is simply a C# class that likely has some pointers back to a core template. This drastically reduces the memory cost, the memory churn, and allows us to fine-tune the simulation and rendering approaches.

Maximum part count

The expected maximum is 65535, or ushort.maxvalue.^{[Citation needed]}

Modding support

Main article: Help:Modding

Yes. It already does. The very core game data itself is a mod. Which means that essentially everything we do, can be done as a mod. This includes:

- C# injection - Changing data, such as solar systems and planets - Customizing shaders

Really pretty much everything. Modding is considered essential to every aspect of the game. This means it factors into our designs not just around how data is loaded, but how data is structured within the code.

Early builds will allow us to stress-test our decisions early, with modders able to highlight issues with how we structure things. This is important to minimize core data structure changes during Alpha and Beta (and beyond), as such changes are enormously frustrating for users and modders at best - and destructive to the community at worst

And a separate answer from Dean on Discord:

I think the single most important thing we can do is establish a reasonable and solid base and ensure modding is as fully supported as possible

N-Body orbital simulation

From Dean on Discord:

Ive now discussed [N-body gravity] with a number of quite experienced people in astronautics, including two people from a major nations space agency. All of them so far were like "do patched conics". I'm certainly open to being convinced otherwise but, so far, the direction i've received from experts I can find is that, at a base game level, doing patched conics makes a lot of sense. So I'm not against N-body but it *probably* will be better as a mod, or optional addition

Game engine

Main article: BRUTAL

We have developed in-house technology we call the "BRUTAL Framework". Instead of an engine, it is more like the XNA Framework developed by Microsoft. BRUTAL allows us to access graphics (and other) API's like Vulkan directly. There is a massive focus on scale, which means a heavy focus on what is called an "interop" layer. This is the layer between which C# (the base language used in our projects using BRUTAL), and C++ which our plugins and APIs like Vulkan run on.

The purpose of using our own framework is that many of the games our studio makes need to scale, and we want to have complete agency over fixing the bugs and problems that are encountered. While both Unity and Unreal are perfectly good tools for many games, our studio has grown intensely frustrated with both of them for developing the types of games we want. They are also both very expensive to utilize.

BRUTAL is named very deliberately. It is not easy to use, and it does no hand holding. It simply exposes the functionality, with nearly it's entire focus providing an extremely efficient interop layer between the two. This results in incredible performance, at the expense of ease of use.

So it is important to clarify, BRUTAL is not a silver bullet. It is simply a tool developed for a very specific purpose - to build games that really scale.

Physics

Dean and others stated that they had trialled the use of the Jolt Physics SDK for some physics tasks (see this livestream clip from swdennis for more info), but as of August 2025 all physics is custom. (link)

C# / DotNet version

From Dean on Discord:

As someone else said .net 8 is what we use. And we can explicitly support loading of custom DLLs, using interfaces for security. This means you should have least as much code feature set as Unity provides. We also give access then to all our libraries as well, so UI multiplayer etc.

BRUTAL licensing

Dean stated that BRUTAL will "100%" be made available to use, hopefully with a plan like Vulkan. It will be most suitable for games that are "hard to make", ie. systems-heavy games that require minimum overhead and maximum control. (link)

Data structures

From Dean on Discord (link)

[For modding] you will need to make the planet definitions and make new billboard sphere LODs. this is because the billboard spheres we ship will be configured mostly for the sizes of our planets. Basically, we take a sphere and say the base number of polys. then you do a "select" on it in XML, this "selects" a region heading out from the front vertex. Then you subdivide that based on the number entered.

And a separate answer:

Yeah. We follow an approach inspired by Space Engineers. Celestial body data is loaded from XML as a "reference" and then that reference can be instantiated but it is not the reference that gets instantiated, but something else. This means we always maintain the library objects and they can have different data structures.

And some examples from the same Discord chat - a planet:

    <Body Id="Venus" Parent="Sol">
        <SemiMajorAxis Au="0.72" />
        <Inclination Degrees="3.39458" />
        <Eccentricity Value="0.0068" />
        <LongitudeOfAscendingNode Degrees="76.680" />
        <ArgumentOfPeriapsis Degrees="54.891" />   
        <MeanAnomalyAtEpoch Degrees="181.97973" />
        <MeanRadius Km="6051.8" />
        <Mass Earths="0.815" />
        <Diffuse Path="Textures/Venus_Diffuse.jpg"/>
        <Color R="1.0" G="0.87" B="0.68" />
        <Rotation X="0.021" Y="-0.9998" Z="0" Retrograde="true">
            <Period Days="243"/>
        </Rotation>
    </Body>

And an example of a "Spherical Billboard":

    <PlanetMeshCollection Id="Example">
        Just exists for demonstration purposes
        <CubeMesh Id="Example">
            <Distance M="-99" />
            <Face Resolution="4" />
            This will select the whole front face, and half of the back faces then subdivide
            <Select Offset="4">
                <Subdivide Ratio="2"/>
            </Select>
            This will grab the whole face from before, and subdivide the whole face
            <Select Offset="4">
                <Subdivide Ratio="2"/>
            </Select>
            This will grab the only 25% of the face, and subdivide that
            <Select Offset="4">
                <Subdivide Ratio="2"/>
            </Select>
        </CubeMesh>
    </PlanetMeshCollection>

File formats are supported by BRUTAL

From Morrow on Discord (link)

So the renderer wants textures/images on the GPU in its own happy special formatting that we let Vulkan handle. But, we have a few different loaders for different file types that let us get it to Vulkan (and rendering). So, we can (hypothetically) support whatever formats and get it loaded up. We use quite a few .PNGs and .DDS files right now but .KTX support is right around the corner iirc.
For current support [of other file types], I believe we use a combination of gli and stb_image [libraries] so what they support we currently support. With the addendum that everything could change of course.

Followup question: "I am curious, how are the models currently being loaded? Is there some fancy special file format like ksp's .mu, or can one just drop-in an .obj or something similar?"

Followup answer:

We use gltf/glb files for meshes and image files standalone for textures currently. But again, the renderer itself is orthogonal to the loading of the data so we can realistically support whatever if there's a strong enough interest and we have some dev time to spare (rare).
Modding is a big priority for us so hopefully that process [of authoring models and putting them into the game] will be easy for people. I find it rather simplistic to add something right now but I also wrote chunks of the pipeline so I'm a bit biased 😁

Part modding guidelines

See "Modding guidelines" in the Parts article for the semi-official modding guidelines for KSA.