Noodloft.Components 0.0.1-alpha4

This is a prerelease version of Noodloft.Components.
There is a newer version of this package available.
See the version list below for details.
dotnet add package Noodloft.Components --version 0.0.1-alpha4
                    
NuGet\Install-Package Noodloft.Components -Version 0.0.1-alpha4
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Noodloft.Components" Version="0.0.1-alpha4" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Noodloft.Components" Version="0.0.1-alpha4" />
                    
Directory.Packages.props
<PackageReference Include="Noodloft.Components" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Noodloft.Components --version 0.0.1-alpha4
                    
#r "nuget: Noodloft.Components, 0.0.1-alpha4"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Noodloft.Components@0.0.1-alpha4
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Noodloft.Components&version=0.0.1-alpha4&prerelease
                    
Install as a Cake Addin
#tool nuget:?package=Noodloft.Components&version=0.0.1-alpha4&prerelease
                    
Install as a Cake Tool

Noodloft.Components

Engine-agnostic gameplay components for .NET games, with save/load built in and a Godot 4 addon on top.

The gameplay rules — how armor and resistances combine, when a level-up fires, where an item stacks — live in plain C# classes that can be unit-tested without an engine running. The engine layer is a thin shell over them.

Projects

Project What it is
Noodloft.Components The reactive component base: ReactiveComponentBase, ReactiveResult, IStatefulComponent, ILogger. Zero dependencies.
Noodloft.Components.Games The seven component families. Zero dependencies.
Noodloft.Components.Persistence Save/load. References the two above; System.Text.Json is in the shared framework.
Noodloft.Components.Games.Godot GodotLogger and GodotUserSaveStore. Compiled, shipped as a DLL.
Noodloft.Components.Games.Godot.Addon The nodes, resources and autoload. Shipped as source — see below.

The component families

Family Owns
Health A pool with a floor and a ceiling.
Damage Crit, armor, typed resistances, invulnerability frames, death, revival. Composes a health pool.
Attributes A modifiable stat: flat, additive-percent and multiplicative-percent modifiers, removable by id or by source.
Progression XP and levels, over a pluggable curve.
Cooldowns One cooldown, or a whole ability bar under a CooldownRegistry.
Inventory Slot-based container with stacking, an optional weight budget, and all-or-nothing or partial operations.
Interaction Focus, hold-to-complete, lock, one-shot.
Input Three components: a buffer (press buffering, hold-to-charge, double tap), a rebindable action map that saves the player's control scheme, and movement intent (circular dead zone, snapping, ramping).
Camera Trauma-based shake, an orbit rig with clamped pitch and zoom, and frame-rate-independent follow damping.

The shape every component takes

Model            mutable state, with internal setters
DTO              a readonly struct describing one operation
Evaluator        a pure static function: (DTO, Model) -> result
Component        wires them together and raises events

An operation returns one of three outcomes, and the difference matters:

var result = cooldown.SetModel(CooldownOperation.Tick(delta));

result.Outcome switch
{
    ReactiveOutcome.Applied   => // the model changed; OnModelSet fired
    ReactiveOutcome.Unchanged => // legal, but a no-op. Silent: this is the per-frame path
    ReactiveOutcome.Rejected  => // the caller asked for something impossible. Logged, with a reason
};

Input, specifically

The two halves are split because only one of them is save state.

// Timing. Never saved: restoring a half-held button leaves it stuck down forever.
if (buffer.TryConsume("jump"))   // pressed up to BufferDuration ago, and not yet claimed
    Jump();

buffer.HoldRatio("charge");      // 0..1, for a charge meter

// Bindings. Saved — but only the actions the player actually rebound, so retuning a
// default control scheme still reaches everyone who left that action alone.
bindings.SetModel(BindingOperation.Rebind("jump", new InputBinding(InputDeviceKind.Keyboard, "Enter")));

A rebind onto a button another action owns is refused and names the clash, which is what a controls menu needs in order to say "Space is already Jump". InputBindingsNode is the only thing that turns a stored binding into a real InputEvent, so a save survives an engine upgrade renumbering its keycodes.

Movement intent is the third piece — the one usually written inline in a character script and usually written slightly wrong:

movement.Set(rawX, rawY);        // straight off the device, before any dead zone
movement.Intent;                 // ramped: what the character moves along
movement.RawIntent;              // unramped: what a dodge or a dash fires along

The dead zone is a circle across the pair, not a threshold per axis. With a per-axis dead zone of 0.2, a stick pushed exactly diagonally to 0.19 on each axis reads as nothing — while its true magnitude is 0.27, well past the threshold. That is how a worn controller ends up drifting diagonally while nobody is touching it. Everything past the dead zone is rescaled from 0, so crossing it is a nudge rather than an instant fifth of full speed.

Camera

shake.Add(0.4f);        // trauma, 0..1 — adds rather than replacing
shake.Offset;           // where to displace the camera this frame

orbit.Look(dx, dy);     // device units; sensitivity, inversion and clamping are the component's
orbit.TargetYaw;        // what a character should face — leads the camera's own angle

Trauma, not "play a shake for 0.3 seconds". A duration-based shake restarts on every hit, so a machine gun produces one permanent small shake instead of a build-up, and two sources at once means whichever fired last wins. Trauma adds, saturates at 1, and drains from wherever it reached. The displacement is trauma squared, so the tail of a shake fades out instead of leaving the camera buzzing at low amplitude — which reads as a rendering fault rather than an impact.

Follow damping is a critically damped spring rather than the lerp(current, target, rate * delta) every tutorial reaches for. That one is frame-rate dependent: the same rate lands somewhere else at 144 fps than at 60, so a camera tuned on the developer's machine is wrong on the player's.

The camera nodes are the camera rather than driving one, so exactly one thing writes the transform per frame. Follow and shake as separate scripts is the classic way to get a camera that jitters because both assign to Position and whichever runs last wins.

Unchanged exists so that ticking sixty idle cooldowns a frame raises no events and logs nothing. Every reason string on that path is a constant, because an interpolated one would allocate on every tick of every component — measured at 128 B per tick before it was fixed.

Three words, no overlap

Word What it is Saved?
Definition Authored configuration as a plain record. Validate() returns problems; Create() builds a component. No
Resource The Godot inspector's editable wrapper around a Definition. [Export]s and a ToDefinition(). No
Snapshot Runtime state. Yes, and only this

Configuration is never written to a save file. That is what lets a designer rebalance a curve or widen a chest and have it take effect on saves that already exist, instead of being overwritten by them.

Persistence

var session = new SaveSession(new FileSystemSaveStore("saves"), gameVersion: "1.0.0");

session.Register(SaveParticipants.ForDamageable("player", damageable));
session.Register(SaveParticipants.ForInventory("player.bag", bag));

session.Save("slot1");
session.Load("slot1");

Save merges over what is already in the slot rather than replacing it, so saving while only one scene is loaded does not wipe every other scene's state. Restoring writes models directly and fires no domain events: loading a dead boss raises no OnDied, loading level 12 raises no eleven level-ups.

The full contract — the JSON shape, the type-id table, the version-mismatch rules and the config-drift table — is in docs/save-format.md.

Godot

Add addons/noodloft.components/ to your project and enable the plugin. That registers the SaveManager autoload; the nodes and resources appear in Create New Node and Create New Resource as soon as the project builds.

Drop a node in, point it at a .tres, give it a Save Id, and it is saved:

GetNode<SaveManager>("/root/SaveManager").Save("slot1");

Nodes are gated hard on processing. SetProcess(false) is the normal state — a ready cooldown, a damageable out of invulnerability frames, an idle interactable — so a level full of components costs nothing. At 64 actors an idle frame measures 4.8 µs and 0 B allocated.

Why the addon ships as source

Godot registers C# types as scripts keyed by a res:// path, stamped at compile time by Godot.SourceGenerators. A [GlobalClass] compiled into a referenced DLL has no such path in the consuming project, so it cannot be attached to a node in the editor and a .tres cannot name it. The node and resource types therefore ship as source; the engine-independent logic they call stays in the compiled libraries.

Shipping source also removes GodotSharp version skew: the consumer compiles against their own engine's bindings.

Build

dotnet build Noodloft.Components.slnx -c Release   # must stay at zero warnings
dotnet test  Noodloft.Components.slnx
dotnet run -c Release --project benchmarks/Noodloft.Components.Benchmarks -- --filter '*FrameLoop*' --job short

Analyzers run at latest-recommended with EnforceCodeStyleInBuild, so the IDE and the command line agree on what counts as a warning. Nothing is suppressed in src/; the few suppressions that exist are scoped to a test or benchmark csproj with a written reason.

Releases

Tagging is what publishes. A vX.Y.Z tag is the version — the workflow refuses a tag that is not a semantic version, and refuses one with no matching section in CHANGELOG.md. That section becomes both the package's release notes and the body of the Gitea release, so the three can never disagree.

Below 0.1.0 every tag carries -alpha and the API is explicitly unstable.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.
  • net10.0

    • No dependencies.

NuGet packages (4)

Showing the top 4 NuGet packages that depend on Noodloft.Components:

Package Downloads
Noodloft.Components.Games

Engine-agnostic gameplay components: health, damage with typed resistances, modifiable attributes, experience and levelling, authoritative socketed item assemblies, source-aware gameplay abilities, cooldowns, slot-based inventory, interaction, input buffering with rebindable controls and movement intent, and camera shake, orbit and follow damping. The rules live in pure evaluators that unit-test without an engine running. No dependencies.

Noodloft.Components.Persistence

Save and load for Noodloft components. Source-generated JSON, pluggable stores, per-entry versioning, and a merging save that does not wipe the state of scenes that are not loaded. Configuration is never written to disk, so rebalancing takes effect on existing saves.

Noodloft.Components.Games.Godot

Godot 4 glue for Noodloft components: logging, user:// save and encrypted token storage, and the WebSocket relay MultiplayerPeer used by server-authoritative games. The nodes and resources are NOT in this package. Godot keys C# script types to a res:// path, which a type inside a DLL does not have, so they ship as addon source instead.

Noodloft.Components.Games.Godot.Arch

Runs the Arch entity component system inside Godot 4: a composable runtime driven from _Process and _PhysicsProcess, a two-way map between entities and nodes, and sync systems that write simulation results back onto the scene tree. Arch is a real archetype ECS — components are flat structs packed into contiguous chunks and walked linearly — so it is worth reaching for exactly when a scene has thousands of similar things and per-node scripts have stopped being affordable. It is not a replacement for nodes, and this package does not try to make it one.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
0.2.0-beta.9 91 8/14/2026
0.2.0-beta.8 88 8/13/2026
0.2.0-beta.7 87 8/13/2026
0.2.0-beta.6 80 8/13/2026
0.2.0-beta.5 76 8/13/2026
0.2.0-beta.4 92 8/13/2026
0.2.0-beta.3 83 8/13/2026
0.2.0-beta.2 96 8/13/2026
0.2.0-beta.1 78 8/10/2026
0.1.0 158 8/8/2026
0.0.1-alpha9 140 8/5/2026
0.0.1-alpha8 132 8/5/2026
0.0.1-alpha7 144 8/5/2026
0.0.1-alpha6 134 8/5/2026
0.0.1-alpha5 132 8/5/2026
0.0.1-alpha4 115 8/4/2026
0.0.1-alpha3 118 8/4/2026
0.0.1-alpha2 128 8/3/2026
0.0.1-alpha11 144 8/6/2026
0.0.1-alpha10 134 8/6/2026
Loading failed

Cameras, and the movement half of input. Both split the usual way: the arithmetic is engine-agnostic
and unit-tested, and the Godot nodes only turn it into a transform.

### Added

- **A camera family**, in a new `Noodloft.Components.Games.Cameras` namespace.
 - `CameraShakeReactiveComponent` — trauma-based shake. Trauma adds rather than replacing, so ten
   small hits build to a big shake instead of each one restarting a small one; a duration-based shake
   turns rapid fire into one permanent small shake. Displacement is trauma raised to a configurable
   power, 2 by default, so the tail of a shake fades to nothing rather than leaving the camera
   buzzing at low amplitude — which reads as a rendering fault rather than an impact.
 - `OrbitReactiveComponent` — yaw, pitch and distance, with clamps, zoom limits and easing. It holds
   angles and never a position, so pitch clamping and wrap-safe smoothing are testable without an
   engine. `TargetYaw` leads the camera's own angle, which is what a character should turn to face:
   inheriting the camera's easing makes a character run at an angle to the view on every flick.
 - `CameraDamping` — a critically damped spring, plus a dead zone and wrap-safe angle helpers.
   Deliberately pure statics rather than a component: there is no state beyond a velocity the caller
   already owns, and no operation that can be refused.
 - The noise behind the shake is hand-rolled value noise rather than the engine's. It is a dozen
   lines, it makes a shake identical on every platform and in every test run, and it is what keeps
   the assembly free of an engine reference.
- **`MovementIntentReactiveComponent`**, in `Input`. A circular dead zone across the movement plane,
 rescaled so the first movement past the threshold is a nudge rather than an instant fifth of full
 speed; optional snapping that keeps its magnitude; and a ramp that steps along the difference vector
 so it does not bend the direction while catching up. `RawIntent` is available unramped, for a dodge
 that has to fire where the player is pointing rather than where the character was already going.
- **Godot nodes** — `CameraFollow2D`, `CameraFollow3D`, `OrbitCamera3D`, `MovementInput2D` and
 `MovementInput3D`, with `CameraShakeResource`, `OrbitResource` and `MovementIntentResource` for
 `.tres` presets. Everything is configured through exported variables.
 - The camera nodes **are** the camera rather than driving one, so exactly one thing writes the
   transform each frame. Follow and shake written as separate scripts is the classic way to get a
   camera that jitters because both assign to the position and whichever runs last wins.
 - Shake is added to a separate anchor rather than to the camera's own position, so it never feeds
   back into the follow. Adding it to the position makes the dead zone measure against a shaking
   camera, and a hard hit walks the camera away from its target.
 - `MovementInput3D` uses only the yaw of the node it is relative to. Taking the whole orientation
   walks the character into the floor the moment the player looks down.
 - `OrbitCamera3D` can pull in when geometry comes between it and the pivot. That casts a ray, which
   is only legal on a physics frame, so the node warns in the editor if its tick mode is anything
   else.
 - `CameraFollow2D` warns when Godot's own Position Smoothing or Drag margins are on, because both do
   overlapping jobs and will fight it.
- **128 tests** covering all of the above, including that the follow spring lands in the same place at
 30, 60 and 144 fps, that turning across the wrap point takes the short way round rather than swinging
 almost the whole way about, and that a diagonal push past the dead-zone radius is not swallowed the
 way a square dead zone swallows it.

### Changed

- `Noodloft.Components.Games`' package description and tags now mention cameras and movement.
- **None of this is saveable, and that is structural rather than documented.** A camera angle is
 derived from where the player is, and a movement direction is which way somebody is pushing a stick;
 both restore into a world that disagrees with them. The input nodes report `CanPersist` false so
 they never register with the `SaveManager`, and the camera nodes are plain `Camera2D` and `Camera3D`
 with no save machinery to opt out of. [docs/save-format.md](docs/save-format.md) has the table.

### Fixed

- `CameraDamping.Damp` approaches its target without ever reaching it — past a point the step
 underflows against the float precision available next to the target, and the value stalls a hair
 short with a small velocity still on it. Left alone, an orbit camera would never report itself
 settled, so the node driving it would ask for frames for the rest of the session and the per-frame
 gating that makes a scene full of components free would quietly stop working. The orbit evaluator
 now settles on an explicit threshold, where the units are known to be radians; `Damp` stays a pure
 spring, with the limitation documented and covered by a test.