coilyco-gaming/factory-game-v3

Watch

Add minimal topology and route-based movement to the Rust sim #19

New issue

Closed

opened 2026-07-09 21:54:05 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 21:54:05 +00:00

Owner

Build the next core simulation step after factory-game-v3#15. This is core Rust logic, not Bevy/viewer/deploy work.

Current state on main:

factory_sim is split into focused modules: resources, production, dispatch, and world.
The starter iron-bars scenario has one source, one hauler, one factory, typed dispatch intents, and explicit hauler assignment state.
The current movement model is still a hardcoded two-location toggle: Location::Source / Location::Factory, with Location::other().

Goal:

Introduce a small, deterministic world topology and route-based movement abstraction so dispatch is no longer coupled to a two-location toggle. Keep this deliberately smaller than full pathfinding.

C# reference material to read first:

Assets/Scripts/Components/MovementComponent.cs
Assets/Scripts/GameController.cs / GameControllerCore movement queue behavior if present
Assets/Scripts/WorldObject.cs for grid position/state shape
Assets/Scripts/Components/DispatchReceiverComponent.cs for how target locations drive movement

Implementation guidance:

Replace or wrap the current Location enum with a small typed position/node model. Possible shape: stable NodeId plus GridPosition { x, y }, or another simple representation that fits the existing Rust code.
Add a topology/route abstraction that can represent a path from source to factory as more than one step, for example source -> road/intermediate -> factory.
Give the hauler movement state enough detail to know its current position and target/destination from the dispatch assignment.
On each tick, move at most one route step toward the assignment destination. Collect/deliver should occur only when the hauler is at the required source/destination node.
Preserve deterministic snapshots and JSONL output. Snapshot shape may change, but it should remain stable and useful for debugging.
Keep the existing iron-bars scenario producing iron bars after route movement is introduced.
Keep code structure close to the prior C# concepts where useful, but do not copy Unity coupling or stringly target locations.

Acceptance criteria:

cargo test --workspace passes.
The iron-bars scenario still produces iron bars deterministically.
At least one test proves a hauler takes multiple ticks to traverse a multi-step route before delivery.
At least one test proves collect/deliver does not happen unless the hauler is at the correct node/position.
The snapshot includes enough topology/movement state to understand where the hauler is and where it is headed.
factory_cli still emits stable JSON lines for the starter scenario.
docs/factory-sim.md and docs/FEATURES.md are updated if terminology or feature inventory changes.

Out of scope:

Full A*/grid pathfinding.
Obstacles, terrain costs, dynamic rerouting, or map editing.
More recipes/content breadth.
Bevy, Wasm, viewer work, or deployment.
Galaxy generation.
Power/battery/deployment verbs.

Close this when movement is a minimal route/topology-driven sim system rather than a two-location toggle.

Build the next core simulation step after `factory-game-v3#15`. This is core Rust logic, not Bevy/viewer/deploy work. Current state on `main`: * `factory_sim` is split into focused modules: `resources`, `production`, `dispatch`, and `world`. * The starter `iron-bars` scenario has one source, one hauler, one factory, typed dispatch intents, and explicit hauler assignment state. * The current movement model is still a hardcoded two-location toggle: `Location::Source` / `Location::Factory`, with `Location::other()`. Goal: Introduce a small, deterministic world topology and route-based movement abstraction so dispatch is no longer coupled to a two-location toggle. Keep this deliberately smaller than full pathfinding. C# reference material to read first: * `Assets/Scripts/Components/MovementComponent.cs` * `Assets/Scripts/GameController.cs` / `GameControllerCore` movement queue behavior if present * `Assets/Scripts/WorldObject.cs` for grid position/state shape * `Assets/Scripts/Components/DispatchReceiverComponent.cs` for how target locations drive movement Implementation guidance: * Replace or wrap the current `Location` enum with a small typed position/node model. Possible shape: stable `NodeId` plus `GridPosition { x, y }`, or another simple representation that fits the existing Rust code. * Add a topology/route abstraction that can represent a path from source to factory as more than one step, for example source -> road/intermediate -> factory. * Give the hauler movement state enough detail to know its current position and target/destination from the dispatch assignment. * On each tick, move at most one route step toward the assignment destination. Collect/deliver should occur only when the hauler is at the required source/destination node. * Preserve deterministic snapshots and JSONL output. Snapshot shape may change, but it should remain stable and useful for debugging. * Keep the existing iron-bars scenario producing iron bars after route movement is introduced. * Keep code structure close to the prior C# concepts where useful, but do not copy Unity coupling or stringly target locations. Acceptance criteria: * `cargo test --workspace` passes. * The iron-bars scenario still produces iron bars deterministically. * At least one test proves a hauler takes multiple ticks to traverse a multi-step route before delivery. * At least one test proves collect/deliver does not happen unless the hauler is at the correct node/position. * The snapshot includes enough topology/movement state to understand where the hauler is and where it is headed. * `factory_cli` still emits stable JSON lines for the starter scenario. * `docs/factory-sim.md` and `docs/FEATURES.md` are updated if terminology or feature inventory changes. Out of scope: * Full A*/grid pathfinding. * Obstacles, terrain costs, dynamic rerouting, or map editing. * More recipes/content breadth. * Bevy, Wasm, viewer work, or deployment. * Galaxy generation. * Power/battery/deployment verbs. Close this when movement is a minimal route/topology-driven sim system rather than a two-location toggle.

coilyco-ops commented

2026-07-09 21:54:14 +00:00

Author

Owner

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-factory-game-v3-19 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T21:54:12Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-gaming/factory-game-v3#19 · branch issue-19 · harness codex · workflow direct-to-main
Run: engineer-codex-factory-game-v3-19 · ward v0.493.0 · dispatched 2026-07-09T21:54:12Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-factory-game-v3-19` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:54:12Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-gaming/factory-game-v3#19` · branch `issue-19` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-factory-game-v3-19` · ward `v0.493.0` · dispatched `2026-07-09T21:54:12Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 22:11:55 +00:00

feat: add route-based hauler movement

coilyco-ops closed this issue

2026-07-09 22:11:55 +00:00

coilyco-ops commented

2026-07-09 22:12:37 +00:00

Author

Owner

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: review gate skipped by ~/.ward/config.yaml default
felt: the topology swap was straightforward once the route and movement state were split out.
confidence: high.
surprises: the Rust code passed quickly; the blockers were toolchain and cache space for the repo gate.
follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: review gate skipped by ~/.ward/config.yaml default felt: the topology swap was straightforward once the route and movement state were split out. confidence: high. surprises: the Rust code passed quickly; the blockers were toolchain and cache space for the repo gate. follow-ups: none. </details>

coilyco-ops referenced this issue

2026-07-21 02:41:48 +00:00

Port mining extraction semantics into the source node #20

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/factory-game-v3#19

No description provided.

Rows
Columns