kobayashi-stfc: KOBAYASHI: The Rust Engine That Turns Star Trek Fleet Command Into a Search Problem

A brute-force combat optimizer that simulates thousands of fights, loads game logic from declarative data, and uses parallel Rust to replace guesswork with math.

8 to 10 min read • View on GitHub • More from pggpgg

By Repo Explainer • AI-assisted • Published by Ron Kurti

Published Apr 15, 2026 • Rust AI Tools

A wide editorial scene shows a strategy tabletop covered in crew cards, ship stats, and branching hostile paths on one side, while a compact scoring machine on the other side sorts the combinations into a single winning answer. The image explains that the repo treats combat as a search space, not a sequence of hand-written tips. — KOBAYASHI’s core idea is simple: stop guessing, start searching.

Key Takeaways

KOBAYASHI wins by turning Star Trek Fleet Command combat into a brute-force search problem, where simulation replaces intuition.
Its real advantage is not just speed, but search depth, because fast parallel fights let the engine test many crew combinations before the meta changes.
The repo’s LCARS layer separates game logic from execution, which makes officer abilities editable data instead of hardcoded Rust branches.
The surrounding importer and CI machinery show a tool built for repeatability, not a one-off script.

Star Trek Fleet Command looks like a game of instincts, but KOBAYASHI treats it like a search space. That shift matters because the game is full of probabilities, hidden bonuses, research modifiers, and officer procs that make gut feel unreliable. Once the inputs multiply, the only serious answer is to simulate until the noise drops out.

The Game Is the Trap

STFC’s combat math is messy enough that a human can make a convincing case for almost any crew. Officers have distinct abilities, ships carry different stat profiles, hostile classes behave differently, and side systems like research or forbidden tech can tilt outcomes in subtle ways. KOBAYASHI exists because the game punishes hand-waving.

The repo’s thesis is blunt: when the problem is combinatorial, the answer is not more opinion. It is more runs. A model that can brute-force hostiles, crew permutations, and proc-heavy encounters changes the unit of work from advice to evidence.

KOBAYASHI’s Real Product Is Certainty

The clever part is not that the project automates a game. It is that it turns a fuzzy optimization problem into a repeatable loop: define the target, load the data, simulate the fight, rank the results. That is the Kobayashi Maru joke at the center of the project. The test is no longer fixed once the engine can search for better conditions.

Approach	Input source	Randomness handling	Repeatability	Best use case
Human intuition	Memory, forum lore, personal experience	Usually ignored or simplified	Low	Fast guesses and casual play
Spreadsheet theorycrafting	Manual sheets and copied formulas	Partially modeled	Medium	Static comparisons and rough planning
KOBAYASHI	Declarative data plus simulation	Monte Carlo runs across many trials	High	Crew search, hostile tuning, and optimization

A close-up scene shows messy handwritten officer notes, spreadsheet fragments, and loose data cards entering a validation gate, then emerging as clean labeled data feeding a combat engine. The image explains how declarative LCARS data and validation turn community knowledge into machine-readable game logic. — The project’s strength comes from separating game data from the combat engine.

How the Combat Engine Gets to Microseconds

The speed story is what makes the whole project credible. The repository leans on Rust, Rayon, Serde, and benchmark-driven development so it can run many fight trials in parallel without turning every search into a waiting game. In a system like this, speed is not an optimization vanity metric. It is the difference between testing a few candidates and testing enough of them to matter.

A crew choice enters as data, expands into many simulations, then collapses into a ranked recommendation.

That architecture is easy to miss if you only look at the repo as a game tool. But it is really a performance pipeline. A single simulated fight can be cheap enough to run in bulk, and bulk is what turns an uncertain game into a usable optimizer.

// Conceptual shape of the hot path, not exact repo code.
fn rank_crews(target: &Hostile, crews: &[Crew]) -> Vec<ResultRow> {
    crews
        .par_iter()
        .map(|crew| {
            let trials = monte_carlo(target, crew, 10_000);
            ResultRow::from_trials(crew, trials)
        })
        .sorted_by(|a, b| b.score.total_cmp(&a.score))
        .collect()
}

The real takeaway is search depth. If the simulator is fast enough, the project can explore more combinations, more hostile profiles, and more edge cases. That is where the math becomes useful instead of merely impressive.

LCARS: Game Logic as Data

The smartest design choice in the repo is the LCARS layer. Officer abilities live in YAML and JSON instead of being buried in hardcoded Rust branches, which means the data can evolve without forcing the engine to be rewritten every time the game shifts. The naming is playful, but the pattern is serious.

This separation gives the project three advantages. It makes the data easier to validate, it makes community contributions less risky, and it keeps the simulation core focused on execution rather than content management. The scripts that generate and validate LCARS files act like a compiler and linter for game logic.

Design choice	Hardcoded logic	Declarative LCARS
Changing an officer ability	Requires code edits and engine review	Update the data file and validate it
Community contribution	Developer-only in practice	Editable by non-engineers with guardrails
Regression risk	Higher when logic and data are fused	Lower because schema checks catch drift
Scaling to new content	Repeated branch growth	New records, same engine

The Importer Chain Feeds the Brain

The least glamorous part of the repo may be the most important. Importers and normalization scripts take messy community spreadsheets and third-party source material, then reshape them into a strict schema the engine can trust. Without that layer, the simulator would be fast but brittle.

This is where the project looks mature rather than merely clever. Data work is treated as first-class engineering. The repo is not just asking, “Can we simulate the game?” It is also asking, “Can we keep the simulation honest as the data changes?”

Stage	Raw community workflow	KOBAYASHI workflow
Source material	Spreadsheet fragments and forum notes	Normalized importer pipeline
Data quality	Inconsistent and hand-maintained	Validated against schema and generator rules
Maintenance cost	High manual cleanup	Lower once the pipeline is established
Outcome	Useful but fragile notes	Reusable model input

Why This Repo Feels More Like a Product Than a Project

There are plenty of signals that the repository is built to last. It has an Axum web server, a health endpoint, Git SHA injection, benchmarking, audits, Playwright coverage, and workflow discipline around CI. That does not guarantee quality, but it does show intent. The codebase is organized like something people expect to run repeatedly, not something they expect to clone once and forget.

That attitude is visible in the repo structure too. The presence of AI-oriented project rules suggests the maintainers are not just using automation as a novelty. They are trying to encode the architecture so both humans and agents can work in the same system without drifting into chaos.

The AI-Native Twist

The `.cursor` and `.claude` files matter because they point to a newer kind of open-source workflow. The codebase is being shaped with explicit rules for assistants, which means the repository is not only documentation for humans. It is also a playbook for tools that need the same constraints humans do.

That is a small detail with a big implication. As more projects get built with AI help, the winning repos will be the ones that preserve structure, checks, and clear boundaries. KOBAYASHI feels like an early example of that discipline in practice.

Workflow	Conventional repo	Rule-guided AI-assisted repo
Knowledge transfer	Readme plus tribal memory	Codified rules and project conventions
Change safety	Depends on reviewer discipline	Bounded by linting, validation, and agent rules
Iteration speed	Human limited	Faster, but only if the constraints are strong
Long-term maintainability	Variable	Higher when the rules stay honest

What KOBAYASHI Changes About Strategy Games

The broader lesson is bigger than Star Trek Fleet Command. Once a game becomes data-rich and probability-heavy, the advantage moves from memorizing advice to running models. KOBAYASHI is a reminder that community wisdom is most powerful when it becomes executable.

That is why the repo feels distinctive. It does not just help players play better. It changes the shape of the problem. In that sense, the project is less like a guide and more like an engine for collapsing uncertainty.