Echo DailyMission

Package: com.echo.dailymission v1.0.6
Unity: 2022.3+
Namespace: Echo.DailyMission
Dependencies: com.echo.orchestra 0.3.0, com.echo.foundation 1.1.1, visual-state-2 0.9.3

Daily-recurring quest engine for Echo games. One config-driven module expresses two feature shapes purely by which config fields are populated — no code fork:

| Shape | selectionMode / rewardMode | Behaviour | |---|---|---| | Daily Mission (config v1) | Fixed / Immediate | A fixed daily checklist; each mission owns its reward and is claimed with a per-mission Claim tap. | | Daily Task (config v2) | TieredRandom / Milestone | N missions drawn per tier each day; completing them fills a shared token bar and milestone thresholds auto-claim. |

The daily reset boundary (resetHour:resetMinute) is measured against server time (GameMasterTime UTC).

Setup

1. Add the package: it's already embedded under Packages/ in this repo, or install it into another project via a scoped registry. In that project's Packages/manifest.json:

   {
     "scopedRegistries": [
       {
         "name": "Echo",
         "url": "https://registry.npmjs.org/",
         "scopes": ["com.echo"]
       }
     ],
     "dependencies": {
       "com.echo.dailymission": "1.0.6"
     }
   }

   com.echo.foundation / com.echo.orchestra resolve as transitive dependencies.
   • visual-state-2 has no registry of its own — it isn't published anywhere (npmjs.org, OpenUPM, or otherwise). Installing this package via a scoped registry only works if your project already has visual-state-2 present (e.g. embedded under its own Packages/visual-state-2/), otherwise Unity's Package Manager fails to resolve it. If you don't already have it, install via the exported .unitypackage instead (Echo → DailyMission → Export Package) — its ExportPackageOptions.Recurse bundles the module's visual-state-2 asset dependencies into the .unitypackage automatically. (Same caveat applies to every other Echo module depending on visual-state-2.)
2. Run Echo → DailyMission → Setup Wizard to generate the host-integration layer (DailyMissionBridge, DailyMissionConfigBridge, SRCheat.DailyMission) into your game's Assets/_Echo/, and to add the bridge to the GameSystem prefab.
3. Wire the bridge // TODO: markers to your host systems (PlayerData for level gating, wallet for reward grants). Reward ids in the config (coin, energy, booster, …) are resolved here.
4. Pick the config version in DailyMissionConfigBridge (daily_mission_config_v1 = Daily Mission, daily_mission_config_v2 = Daily Task). The selector + reward strategy are bound at Initialize(), so choose the version before init — see DailyMission.md §4.
5. To try the module standalone with zero host code, import the DailyMission Entry Point sample (Package Manager → DailyMission → Samples) and open Samples/Scenes/DailyMissionSample.unity — see "Debug tooling" below.

Debug tooling

Two interchangeable options — both call the same DailyMissionManager public API, so their cheats never drift out of sync:

• With SRDebugger: SRCheat.DailyMission.cs, generated by the Setup Wizard, adds a DailyMission panel to the SRDebugger overlay (Complete Next Mission / Complete All Missions / Force Daily Reset / Log State, plus read-only Is Active / Cycle Index / Total Stars / Time Until Reset).
• Without SRDebugger: drop DailyMissionDebugGUI (Scripts/Debug/DailyMissionDebugGUI.cs, ships with the module, zero third-party dependencies) onto any scene GameObject for an OnGUI() panel — per-mission Complete/Claim buttons, per-milestone Claim, Complete All, and Force Daily Reset. Already included in the sample scene.

Architecture

DailyMissionManager (logic) + DailyMissionConfig (tunables) + DailyMissionFileStorage (persistence) + DailyMissionState (read model) + DailyMissionService (facade), with pluggable IMissionSelector (Fixed/TieredRandom), IRewardStrategy (Immediate/Milestone), and IMissionEvaluator (gameplay-signal → progress) strategies. The module emits KEventBus events (DailyMissionStateChangedEvent, MissionCompletedEvent, MissionRewardGrantedEvent, MilestoneClaimedEvent) and never references host systems directly — all host coupling lives in the generated DailyMissionBridge.

See DailyMission.md for the full design doc, including the complete v1 + v2 config schema.