5.3 KiB
5.3 KiB
date, type, tags, permalink
| date | type | tags | permalink | ||||
|---|---|---|---|---|---|---|---|
| 2026-05-30 | session |
|
gamevault/07-sessions/2026/2026-05-30-m1-player-slice |
Session 2026-05-30 — M1 Player Slice + foundation direction
Goal
Kick off real dev via /dots-dev: lock the genre/foundation direction for a V Rising × factory-automation co-op ARPG (small team), plan the initial phases, and build M1 — a server-spawned, owner-predicted player ghost that moves via twin-stick WASD + directional aim.
Done
Direction locked — see Pillars
- Genre: V Rising mechanics + action-ARPG combat (LoL / Diablo 4 / PoE2) + factory automation; small-team scope.
- Control: WASD movement, controller-first, directional / twin-stick aim (soft auto-target in-arc).
- Multiplayer: small co-op 2–4, client-hosted listen-server (BinaryWorlds + in-proc IPC), PvE.
- World: persistent buildable home base + instanced/procedural expeditions.
- Automation: progression accelerator — self-running production chains; data model designed to grow toward full logistics.
- 6-phase roadmap M1–M6 — see Milestones.
M1 built — code-complete, EditMode-verified
All four asmdefs compile clean (source-gen OK); EditMode tests 3/3 green.
- Simulation:
PlayerTag,PlayerInput(IInputComponentData,float2Move/Aim[GhostField],ToFixedString),PlayerMoveStats,PlayerFacing([GhostField]Direction),GoInGameRequest(IRpcCommand),PlayerSpawner;PlayerMoveSystem+PlayerAimSystem(PredictedSimulationSystemGroup,.WithAll<Simulate>(),SystemAPI.Time.DeltaTimeonly — deterministic). - Client:
GoInGameClientSystem;PlayerInputGatherSystem(GhostInputSystemGroup, non-Burst ISystem reading the Input System). - Server:
GoInGameServerSystem(instantiate player +GhostOwnerfromNetworkId+LinkedEntityGroupauto-despawn). - Authoring/asset:
PlayerAuthoring/PlayerSpawnerAuthoringbakers;Player.prefab(GhostAuthoringComponent OwnerPredicted, HasOwner, AutoCommandTarget);PlayerSpawnerwired intoGameplay.unity;GameBootstrap.AutoConnectPort = 7979. - Tests:
PlayerMoveSystemTests— deterministic advance + idempotence across tick batches. - Live Netcode 6.6 API shapes verified via
unity_reflectbefore coding (GhostOwner.NetworkId,NetworkId.Value,Receive/SendRpcCommandRequest,GhostOwnerIsLocal,IInputComponentData.ToFixedString→FixedString512Bytes).
Build gotchas learned — now in repo CLAUDE.md
- Source-gen'd systems need
Unity.Transformsas a direct asmdef reference (LocalTransform); transitive visibility doesn't satisfy the generator. - Authoring asmdefs need
Unity.Entities.Hybrid(forBaker<T>) andUnity.Collections. - A component named
PlayerInputcollides withUnityEngine.InputSystem.PlayerInput; withusing UnityEngine.InputSystem;the Entities generator bindsRefRW<PlayerInput>to the managed class → misleading CS8377 "must be unmanaged". Fix: fully-qualify Input System types, don't import the namespace. - A nested baker class must not be named
Baker(shadowsUnity.Entities.Baker<T>→ CS0308/CS0246).
Decisions
- DR-002_Unity66_Alpha_Netcode_Transport — runtime netcode is blocked on the 6.6 alpha.
- Host mode = BinaryWorlds + IPC (stable), not the experimental
HostWorldMode.SingleWorld(internal unlessNETCODE_EXPERIMENTAL_SINGLE_WORLD_HOST). - Correction to DR-001_Netcode_Test_Harness assumption: on the 6.6 upgrade, Netcode (→6.6.0) and Physics (→6.5.0) DID renumber into the editor line — they did not stay independent 1.x.
CLAUDE.mdupdated.
Open / deferred
- BLOCKER — env-specific, NOT an engine bug (corrected 2026-05-31): the in-editor connection never formed on Project M @
6000.6.0a6("invalid wrapped network interface"). Initially mis-attributed to a Unity engine bug, but a clean fresh6000.6.0a6project (../Local Reference, a full Netcode-for-Entities framework) connects fine. The bare-scene repro still ran inside Project M's contaminated environment (embedded Entities-1.xrukhanka+ in-place-upgradeLibrary/manifest residue + default driver/AutoConnect), so it isolated gameplay code but not the environment. Bug report withdrawn. See DR-002_Unity66_Alpha_Netcode_Transport → Correction. - RESOLVED 2026-05-31: M1 runtime fully validated on Unity 6.4.7 / Netcode 1.13.2 — connect → GoInGame → server-spawn → owner-predicted ghost → client replication all confirmed (
players=1/netIds=1/inGame=1/ownerLocal=1in both worlds), no transport error. One-time fix: forced asset reimport to rebake the stale entity-subscene after the in-place downgrade. Minor follow-ups: enableApplication.runInBackground; re-save URP global settings (cosmetic missing-types from the 17.6→17.4 downgrade). - Deferred decisions (revisit at their phase): relay provider (default Unity Relay) before M3; home-base grid 2D vs 3D before M5; production predicted vs server-only before M6; character controller (custom kinematic vs vendor ECS-samples) at M4.
Next
Re-run the M1 play-tick on a stable Unity 6.x (or reproduce with the networked-cube sample to file a bug). When green, proceed to M2 — twin-stick combat / abilities.