Developer Insights #13 – KSP2 Resource System
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.
In 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!