Part

Parts are the components used to build vessels in Kitten Space Agency.

Anatomy

Most parts will be made up of a collection of "pieces"/sub-parts. Fuel tanks may be comprised of fuel containers, a fuselage, and end caps, while a larger solar panel may be comprised of several single panels connected together. Many parts will contain mesh(es) which will be toggle-able, and will also be editable/dynamic so that they can be used in different sizes. Parts will have defined attachment nodes where they can be connected together.

Daishi explained the part structure in more detail:

Internally we've been having great discussions about how to add depth and modularity to the experience of KSA when you're building craft; and we've focused on a few core concepts that KSP modding explored. Restock, BDB, Universal Storage and many others utilized a concept called "part switching" where a single part had multiple variants, giving craft design both greater utility and visual depth. One part could be adjusted in the VAB to suit the mission profile at hand, giving you freedom to adjust a rocket stack's appearance or function without tearing your whole craft apart to do so.

Another concept was service module building - US2 leaned on this heavily. KSA will have a service module system where specific parts (we're calling them bay parts at the moment) cleanly interface with a common profile of central cores. This enables a cleaner more aerodynamic craft, alongside more conventional parts like radials and stack-mounted items. These bay parts have a common profile, radial symmetry, and fit in every available service module cleanly (including sockets in more advanced capsules).

For our first batch of parts, we're focusing on a small suite that will set a great foundation for both of these concepts:

• A "medium" sized capsule, holds two kittens. This will have two or three customizable skins, options for crew passage on both ends, alongside a substructure that can be used as a lightweight rover body. This is designed as a homage to the Gemini spacecraft capsule - not intended to be an exact replica but a stylized "kittenized" version of it with tweaked proportions and style. Three sockets for bay parts exist behind the Kitten's heads; with cavities in the substructure for smaller radially attached parts.
• A small selection of bay parts (RCS tanks)
• RCS engines
• A heatshield
• A small profile service bay
• A small profile fuel tank
• And a Gemini-esque service module bay

Size

Parts in KSA will come in standard sizes to make rocket assembly easier, similar to size classes in Kerbal Space Program. The preliminary size standards have been set based on real-world parts (subject to change):

Potential profile	Diameter	Inspiration
Tiny	1.0m	Scout solid fuel boosters
Small	2.0m	Mercury capsule base diameter
Medium	3.0m	Gemini service module diameter
Large	4.0m	Apollo capsule diameter
XL	6.5m	Saturn V third stage diameter
XXL	10m	Saturn V first stage diameter

Doors, hatches, and crew tunnels are currently set to 0.75m diameter, while smaller parts may be developed if there is a gameplay niche that they serve.

Art style

Daishi, an artist at Rocketwerkz, had the following to say about Kitten Space Agency's art style:

We're aiming for a visual style not unlike what Restock acheived (aka the design fundamentals the modding community at large adopted); with a focus on painterly styles, a tight control on PBR material use (only on exposed metal, foil, and highlights like lenses and screens) and a slightly chunky part design that doesn't get too detailed, and reads well from near and far.

Saying that, we'd like to push the boundaries a little bit, and would love to bring in a more retro-futurism\cassettepunk\NASApunk vibe to things; something I personally loved bringing in with my Universal Storage 2 science parts. If you google Paul Pepera, I think he represented the style wonderfully. It's hard to see on work at this early stage, as proportions and scale have to come first, but his portfolio lives permanantly on my second monitor for reference 🙂

On a technical standpoint, we've settled on doubling KSP's radial "standard" of 24 polygons around a part's circumference to 48. Part diameters are standardized (internally) in tidy meter-by-meter steps. 1m (tiny) 2m (small) 3m (medium) 4m (large) etc.

In other words, the art style for parts in KSA would be based on the foundations of the Restock/Stockalike part mods for Kerbal Space Program: "flatter materials, edgewear, selective highlighting where it matters, etc." Nertea's KSP mods were also cited as inspiration. Daishi shared the following on the topic of whether KSA parts would look like those in KSP2:

KSP2 leaned a bit heavy on reflections to make things look good - when you're in space and there's very little reflected light, mostly everything looked either black, monotone, or plastic. Their parts looked amazing when rendered in an HDR lighting environment, but fell short in-game. So def not "metal everywhere" [for part appearances in KSA]; things will be painted carefully and highlighted where it's needed.

Daishi stated that KSA parts would look like the KSP modded parts in the following image, but "a little better":

Visual target for KSA parts (KSP part mods developed by Daishi)

Interiors

Dean has emphasized how much he likes the FreeIVA mod for Kerbal Space Program (which allows players to move Kerbals around inside their spacecraft), so KSA parts will also have interiors in Kitten Space Agency. The target level of detail will be similar to FreeIVA with instanced rendering used to optimize performance. Ray tracing will be supported as an optional feature for interior views.

Modding guidelines

Daishi posted the following "semi-official" part modding guidelines for Kitten Space Agency:

KSA is being built to be as user friendly for content creators and modders as possible - a great game outlives its studio and is supported by the community for years (pls support us tho) and we want KSA to thrive as much as KSP did.

To make part mods, all you need is Blender, an image editor, and a little bit of knowledge of xml (how parts are defined). How we define parts and their relationships with each other isn't set in stone yet - so what I would do is just start modelling and getting things ready.

Some guidelines for modelling...

• Cylindrical parts are 48 sides around their circumference, vs KSP's standard of 24.
• We step in 1m (tiny) 2m (small) 3m (medium) 4m (large) profiles, plus some large ones I haven't really blocked out yet (think the Saturn 5). Small capsule is 2m, the medium capsule sits at 2.5m (kinda the outlier, as to get a proportionate Gemini-esque craft I had to bridge the gap); large will be 4m. Things are 99% as close as 'real' scale as I could make it
• Parts are made out of subparts, so for example you'd model one endcap for a tank and reference it twice in XML to appear on both sides. Same deal with the RCS system, for all 16 parts variants there are only three nozzles. Because our rendering system is super efficient, this means complicated ships end up being easier and easier to render because you only have one RCS thruster, one fuel tank end, etc.
• Part models are centered at 0,0 to make sure XML subpart coordinates are consistent.
• Assets are imported into the game in the GLB format. This can be exported from Blender by going to File->Export->glTF 2.0 (.glb/.gltf) and in the menu that appears, select "Format glTF Binary (.glb)"
• Try be efficient with polys as you can be - more density on part silhouettes and less where you can't see it. Rim of an engine bell, for eg.

Guidelines for texturing...

• I work with atlases, so one texture serves multiple parts. In xml you define what part uses what texture, so it's easy to make things efficient.
• A part has one diffuse, one normal map, and one PBR map (so far). PBR maps are three maps in one (Red channel Roughness, Green Metalness, and Blue Ambient Occlusion)
• Diffuse maps thus have no AO, make sure you save them without AO baked in, and put it in the PBR map.
• Most parts are 350ppm (pixels per meter), but as things get bigger you want to step down so things don't use too much texture space. Not by much, it was kind of what the Restock team did with KSP, the largest tanks were about half the density. So my 3m\4m tanks are about 200ppm. Rule of thumb, give more texture density to parts that you're going to interact with (IVA's, Kitten-interactable parts, science equipment, etc); people don't necessarily zoom in on tanks.
• Compress textures in .dds format, more details on compression standards coming soon™
• Roughness maps are greyscale, Metalness maps are binary black and white. You can approximate a roughness map with an inverted Ambient occulsion map overlaid over a diffuse map (in sRGB) that has had its contrast tweaked, but it's all about iteration until it looks right. Metalness maps are strictly "is it metal? Yes\no", as a black and white binary map. I haven't been happy with how glass looks so i'm still working out how to define that.
• So texture these individually, then flatten them, paste them into a PNG file's RGB channels, and then save that PNG as a .dds through Nvidia's texture tool program (standalone and free). You can also use the same tool to convert heightmaps into Normal maps, but those compress differently again. More info soon!