283 lines
12 KiB
Markdown
283 lines
12 KiB
Markdown
# MVP QA Gates
|
|
|
|
Version `0.1.Q` turns the current survival MVP into a repeatable test target.
|
|
Each gate must have either automation, a documented manual test, or build
|
|
evidence before it is marked complete.
|
|
|
|
## Packaged Client Launch
|
|
|
|
The packaged client launch gate proves the Windows investor/demo package can be
|
|
created, opened through a known launcher, and checked through the real-GPU
|
|
visual QA path.
|
|
|
|
Required evidence:
|
|
|
|
- `Scripts/PackageWindowsDevelopment.bat` completes successfully.
|
|
- `Builds/WindowsDevelopment/AgrarianGame.exe` exists.
|
|
- `Scripts/InstallWindowsDemoLaunchers.bat` installs:
|
|
- `Start Agrarian Demo.cmd`
|
|
- `Start Agrarian Demo - DX12.cmd`
|
|
- `Start Agrarian Demo - Compatibility DX11.cmd`
|
|
- `Scripts/RunWindowsInvestorVisualQACheck.bat --check-tools` reports the
|
|
packaged demo exists and `SunshineService` is running.
|
|
- Any full visual pass stores notes under `Saved\VisualQA\InvestorDemo`.
|
|
|
|
This gate is client-only. It does not require multiplayer server deployment.
|
|
|
|
## Server Launch
|
|
|
|
The server launch gate proves the MVP gameplay host can start the current
|
|
server-compatible package and expose the Unreal gameplay port.
|
|
|
|
Current MVP launch path:
|
|
|
|
- Prefer the true Linux dedicated-server target when a server-capable Unreal
|
|
engine is available:
|
|
`Scripts/BuildLinuxDedicatedServer-Windows.bat`
|
|
- Until then, use the binary-engine fallback:
|
|
`Scripts/PackageLinuxGameServerFallback-Windows.bat`
|
|
- Deploy the produced package to `/opt/agrarian/server`.
|
|
- Launch through `/opt/agrarian/server/AgrarianGameServer.sh`.
|
|
- Manage the host with `agrarian-game-server.service`.
|
|
|
|
Required evidence:
|
|
|
|
- `systemctl is-active agrarian-game-server.service` reports `active`.
|
|
- `ss -lunp` shows `AgrarianGame` listening on `0.0.0.0:7777/udp`.
|
|
- The journal shows the Ground Zero map browse started.
|
|
- The runbook explains the true dedicated target and fallback path.
|
|
|
|
This gate is server-relevant and requires multiplayer server verification when
|
|
server launch tooling or deployed package contents change.
|
|
|
|
## Two-Client Connection
|
|
|
|
The two-client connection gate proves the MVP can be tested as a multiplayer
|
|
session with two packaged Windows clients connected to the same Ground Zero
|
|
server.
|
|
|
|
Required evidence:
|
|
|
|
- The server launch gate is passing.
|
|
- `Scripts/RunTwoClientConnectionSmoke-Windows.bat --check-tools` confirms the
|
|
packaged client exists.
|
|
- The helper launches two clients against the same endpoint:
|
|
`play.agrariangame.com:7777` by default, or a supplied LAN endpoint such as
|
|
`192.168.5.15:7777`.
|
|
- Both clients reach the same Ground Zero session.
|
|
- Testers confirm both clients see the same time/weather and can remain
|
|
connected long enough to begin the smoke test.
|
|
|
|
The manual observation steps continue in
|
|
`Docs/Ops/MultiplayerLatencyTestPlan.md` until gameplay automation can drive
|
|
two clients directly.
|
|
|
|
## Resource Gathering
|
|
|
|
The resource gathering gate proves a player can interact with placed Ground
|
|
Zero resource nodes and receive authoritative resource inventory changes.
|
|
|
|
Required evidence:
|
|
|
|
- Ground Zero includes placed wood and fiber resource nodes.
|
|
- `AAgrarianResourceNode` exposes `Gather` or `Gather by hand` prompts.
|
|
- Gathering runs only with server authority.
|
|
- Successful gathering decrements replicated `RemainingHarvests`.
|
|
- The gathered item stack is granted through the character inventory path.
|
|
- Resource depletion persistence is covered by the save/load gate.
|
|
- `Scripts/verify_playable_loop_smoke.py` includes wood and fiber gathering in
|
|
the natural shelter loop smoke test.
|
|
|
|
This gate is gameplay/server-relevant and should be covered by the next server
|
|
package deployment.
|
|
|
|
## Craft Shelter
|
|
|
|
The craft-shelter gate proves the MVP can build a primitive shelter path from
|
|
resources through recipes and world placement.
|
|
|
|
Required evidence:
|
|
|
|
- Primitive frame, wall panel, roof panel, and shelter recipes exist.
|
|
- `BP_PrimitiveShelter` derives from the native shelter actor.
|
|
- Building placement consumes active buildable cost on the server.
|
|
- Shelter actors persist through the world-actor persistence path.
|
|
- `Scripts/verify_playable_loop_smoke.py` runs the natural shelter loop using
|
|
wood, fiber, wildlife, shelter-piece recipes, and the primitive shelter class.
|
|
|
|
This gate is gameplay/server-relevant and should be covered by the next server
|
|
package deployment.
|
|
|
|
## Craft Fire
|
|
|
|
The craft-fire gate proves the MVP can produce or use a campfire through the
|
|
crafting/building loop, then interact with that fire in the world.
|
|
|
|
Required evidence:
|
|
|
|
- `DA_Recipe_Campfire` exists with the `campfire` recipe ID.
|
|
- The campfire item/buildable path is available to the player blueprint setup.
|
|
- `BP_Campfire` derives from `AAgrarianCampfire`.
|
|
- `AAgrarianCampfire` supports `Light fire` and `Maintain fire` interaction
|
|
prompts.
|
|
- Campfire lit/fuel state is replicated.
|
|
- Campfire persistence and fire-risk QA verifiers pass.
|
|
|
|
This gate is gameplay/server-relevant and should be covered by the next server
|
|
package deployment.
|
|
|
|
## Full Day/Night Survival
|
|
|
|
The full day/night survival gate proves one player can remain alive through one
|
|
complete compressed Agrarian day while the server advances time, weather, and
|
|
survival pressure.
|
|
|
|
MVP timing:
|
|
|
|
- The gameplay calendar target is `4 real hours = 1 in-game day`.
|
|
- `AAgrarianGameState` advances and replicates `WorldHours`, day/year state,
|
|
solar bounds, `IsNight`, weather, and ambient temperature.
|
|
- The pass starts at a known hour, preferably dawn or morning, and ends after
|
|
`WorldHours` reaches the same solar phase on the next in-game day.
|
|
|
|
Required evidence:
|
|
|
|
- Hunger, thirst, stamina, body temperature, and health update over time on
|
|
server authority.
|
|
- A player can gather resources, craft or use a fire, craft or use shelter,
|
|
and recover enough food/water/warmth to avoid death for the full cycle.
|
|
- Day/night state changes at least once and returns to the original phase.
|
|
- The critical survival HUD can show alive/dead state and core stat pressure.
|
|
- World time and player survival state are covered by save/load persistence.
|
|
- The result is recorded as either a completed manual run or a captured test
|
|
log before external MVP demos treat the gate as fully play-proven.
|
|
|
|
This gate is gameplay/server-relevant and should be covered by the next server
|
|
package deployment.
|
|
|
|
## Survival Pressure Death
|
|
|
|
The survival-pressure death gate proves the MVP does not merely display hunger,
|
|
thirst, exposure, illness, or injury as cosmetic stats. Sustained pressure must
|
|
be able to reduce health, mark the character dead, replicate the death state,
|
|
and expose a clear respawn path.
|
|
|
|
Required evidence:
|
|
|
|
- Starvation, dehydration, cold exposure, sickness, and bleeding can reduce
|
|
`Survival.Health` on server authority.
|
|
- `ClampSurvival` calls `UpdateDeathState`, clamps health to zero, clears
|
|
stamina, sets `bIsDead`, and records `LastDeathReason`.
|
|
- The replicated survival snapshot includes the death state and last death
|
|
reason.
|
|
- The critical survival HUD and death/respawn panel display the dead state and
|
|
cause.
|
|
- The player controller exposes the MVP respawn path and revives the survival
|
|
component on the server.
|
|
- Death/respawn behavior remains persistence-safe through the player stat
|
|
save/load path.
|
|
|
|
This gate is gameplay/server-relevant and should be covered by the next server
|
|
package deployment.
|
|
|
|
## Reconnect State Retention
|
|
|
|
The reconnect state retention gate proves a player can disconnect, reconnect,
|
|
and recover the MVP state that matters for a continuing survival session instead
|
|
of starting over from a blank pawn.
|
|
|
|
Required evidence:
|
|
|
|
- `AAgrarianGameGameMode::Logout` captures a player snapshot before the pawn is
|
|
released.
|
|
- `AAgrarianGameGameMode::RestartPlayer` restores a matching snapshot after the
|
|
normal MVP spawn path.
|
|
- `UAgrarianPersistenceSubsystem::SavePlayerSnapshot` and
|
|
`RestorePlayerSnapshot` preserve transform, safe player identity, survival,
|
|
care history, and inventory.
|
|
- Inventory restore uses `RestoreSavedItems` so derived carry weight and
|
|
inventory listeners refresh after reconnect.
|
|
- If no matching snapshot exists, the player falls back to the normal MVP spawn
|
|
point instead of failing the join.
|
|
- The manual two-client test records reconnect evidence alongside world
|
|
time/weather consistency.
|
|
|
|
This gate is server-relevant and must be rechecked after multiplayer package
|
|
deployment.
|
|
|
|
## Server Restart Shelter Persistence
|
|
|
|
The server restart shelter persistence gate proves a placed primitive shelter is
|
|
not merely a runtime actor. It must be captured into the world save, restored by
|
|
the server on startup, and remain available for weather protection after a
|
|
restart.
|
|
|
|
Required evidence:
|
|
|
|
- `AAgrarianShelterActor` owns a persistent actor component with
|
|
`ActorTypeId = primitive_shelter`.
|
|
- The game mode registers `primitive_shelter` with the persistence subsystem
|
|
before loading current world state.
|
|
- `SaveCurrentWorld` captures world actors and `LoadCurrentWorld` restores
|
|
registered world actors.
|
|
- Server startup uses `bLoadWorldOnServerStart`, checks `DoesSaveExist`, and
|
|
calls `LoadCurrentWorld` without clearing existing map actors.
|
|
- Shelter weather-protection verification remains tied to the restored shelter
|
|
actor.
|
|
- A release smoke run should place a shelter, save, restart the server, and
|
|
confirm the shelter remains at the same transform.
|
|
|
|
This gate is server-relevant and must be rechecked after the final 0.1.Q server
|
|
package/deploy if server code or package contents changed.
|
|
|
|
## Thirty-Minute Critical Log Soak
|
|
|
|
The 30-minute critical log soak gate proves the MVP can run through a short
|
|
investor/tester session without noisy fatal, crash, assertion, ensure, or
|
|
critical error spam hiding real problems.
|
|
|
|
Required evidence:
|
|
|
|
- Run a packaged client and the target server for at least 30 minutes.
|
|
- Exercise the normal MVP loop during the soak: join, gather, craft/use fire,
|
|
craft/place shelter, wait through time/weather pressure, disconnect, and
|
|
reconnect if possible.
|
|
- Preserve client logs, server logs, and any visual QA summary under `Saved`
|
|
or the release evidence folder.
|
|
- Run `Scripts/scan_critical_log_spam.py` against those logs.
|
|
- A passing scan reports zero fatal/crash/assert/ensure/critical-error matches.
|
|
- Any known noisy-but-harmless line must be added to the scanner allowlist with
|
|
a short comment in the commit that introduced the allowlist entry.
|
|
|
|
This gate is both client and server relevant. It must be re-run for final
|
|
milestone packages before sending an investor demo as stable.
|
|
|
|
## Target Player Count Server Stability
|
|
|
|
The target player count server stability gate proves the MVP server can hold
|
|
the defined early test population long enough to exercise the core survival loop
|
|
without a crash, disconnect cascade, or critical log spam.
|
|
|
|
MVP target:
|
|
|
|
- minimum proof: 2 players connected to the same server;
|
|
- target closed-test smoke group: 4 players on one server;
|
|
- stretch test: 8 players only after the dedicated/listen server path is
|
|
stable.
|
|
|
|
Required evidence:
|
|
|
|
- The server launch gate passes on the target host.
|
|
- The two-client connection gate passes at minimum.
|
|
- For closed-test readiness, repeat the same smoke with 4 connected clients.
|
|
- During the run, connected clients exercise join, gather, craft/use fire,
|
|
craft/place shelter, survival pressure, disconnect, and reconnect where
|
|
possible.
|
|
- Run the critical log scanner on the captured client and server logs.
|
|
- Server-side UDP `7777` remains listening and the service remains active after
|
|
the smoke.
|
|
|
|
This gate is server-relevant and should be re-run after every server package
|
|
deployment that changes gameplay, persistence, networking, map content, or
|
|
server startup behavior.
|