44r0n7
0265afa054
Import the runnable game code, content, docs, scripts, and repo guidance while leaving local agent state, dependency installs, build output, and backup copies out of the published tree.
162 lines
4.0 KiB
Markdown
162 lines
4.0 KiB
Markdown
# Sysadmin Chronicles — Spec Lock
|
|
|
|
This file preserves the user's intended new system design. Treat it as binding.
|
|
|
|
## 1. Narrative spine
|
|
|
|
The story progression is:
|
|
|
|
```text
|
|
Normal Work → Unease → Suspicion → Investigation → Conflict → Resolution
|
|
```
|
|
|
|
Every quest must map to one of these phases.
|
|
|
|
## 2. Required quest structure
|
|
|
|
Every proposed quest must include:
|
|
|
|
- Title
|
|
- Narrative Phase
|
|
- Objective
|
|
- Linux Concepts
|
|
- Systems Used
|
|
- Hidden Hook (optional)
|
|
- Failure Conditions
|
|
- Behavior Impact
|
|
|
|
For implementation, these may be expanded into JSON fields, but these concepts must remain present.
|
|
|
|
## 3. Core systems
|
|
|
|
### 3.1 Player behavior tracking
|
|
|
|
Track:
|
|
|
|
- `curiosity` — exploration, anomaly investigation, reading beyond ticket scope
|
|
- `obedience` — completing assigned work, following stated priorities, ignoring suspicious extras
|
|
- `risk` — reckless changes, broad permissions, deleting evidence, unsafe shortcuts
|
|
|
|
These influence:
|
|
|
|
- Access levels
|
|
- Narrative progression
|
|
- Endings
|
|
|
|
### 3.2 Trust and suspicion compatibility
|
|
|
|
The existing system already uses `trust_delta`, world flags, and branch quality. Preserve that.
|
|
|
|
Map old and new systems like this:
|
|
|
|
- `trust` = professional standing produced mostly by solution quality and branch outcomes
|
|
- `suspicion` = management/security attention caused by investigative, risky, or unusual behavior
|
|
- `curiosity`, `obedience`, `risk` = the new behavior profile controlling narrative route
|
|
|
|
Do not replace trust. Extend it.
|
|
|
|
### 3.3 Access system
|
|
|
|
Player permissions evolve:
|
|
|
|
```text
|
|
basic_user → sudo → root
|
|
```
|
|
|
|
Access is affected by:
|
|
|
|
- Trust from competent task completion
|
|
- Suspicion from investigation behavior
|
|
- Risk from careless or destructive changes
|
|
- Narrative phase
|
|
|
|
### 3.4 Boss system / management pressure
|
|
|
|
The boss system acts as a dynamic constraint, not a cutscene machine.
|
|
|
|
Phase scaling:
|
|
|
|
- Phase 1: Annoying
|
|
- Phase 2: Dismissive
|
|
- Phase 3: Suspicious
|
|
- Phase 4: Monitoring
|
|
- Phase 5: Interfering
|
|
- Phase 6: Outcome-dependent
|
|
|
|
Functions:
|
|
|
|
- Interrupt tasks
|
|
- Reassign priorities
|
|
- Restrict access
|
|
- Add pressure through tickets, emails, delayed approvals, audits, or access review
|
|
|
|
In the current company context, this can be represented by Marcus, Kowalski, Priya, or policy pressure depending on the situation. Do not turn one character into a cartoon villain.
|
|
|
|
### 3.5 Hidden narrative system
|
|
|
|
Hidden hooks are embedded in normal quests.
|
|
|
|
Examples:
|
|
|
|
- Unknown services
|
|
- Suspicious cron jobs
|
|
- Hidden users
|
|
- Network anomalies
|
|
- Unexpected SSH keys
|
|
- Odd timestamps
|
|
- Config history that does not match the official story
|
|
|
|
Rules:
|
|
|
|
- Never explicitly flagged
|
|
- Optional discovery only
|
|
- Not required to complete the assigned ticket
|
|
- Must be discoverable through real sysadmin behavior
|
|
- Should accumulate into a coherent hidden story over time
|
|
|
|
## 4. Quest generation constraints
|
|
|
|
- Reuse existing game systems
|
|
- Do not introduce unnecessary mechanics
|
|
- Scale difficulty with player progression
|
|
- Preserve the observed-VM-state design from existing quest authoring
|
|
- Prefer real Linux behavior over puzzle logic
|
|
|
|
## 5. Difficulty scaling
|
|
|
|
- Phase 1: Explicit instructions
|
|
- Phase 2: Partial hints
|
|
- Phase 3: Minimal guidance
|
|
- Phase 4+: Problem-solving only
|
|
|
|
This applies to ticket wording, hints, clue obviousness, and branch tolerance.
|
|
|
|
## 6. Endings
|
|
|
|
Endings are determined by behavior over the playthrough:
|
|
|
|
- `corporate_loop` — obedient path / bad ending
|
|
- `burnout` — passive path / neutral ending
|
|
- `exposure` — investigative path / good ending
|
|
- `chaos` — destructive/high-risk path
|
|
|
|
No ending should be selected by a single obvious final button. The route should emerge from world flags, behavior variables, access state, and discovered/acted-on hidden hooks.
|
|
|
|
## 7. Design principles
|
|
|
|
- Discovery over exposition
|
|
- Systems over scripts
|
|
- Freedom over forced narrative
|
|
- Realism with subtle distortion
|
|
|
|
## 8. Non-goals
|
|
|
|
Do not:
|
|
|
|
- Build a linear-only story
|
|
- Rely on cutscenes
|
|
- Over-explain mechanics
|
|
- Remove player agency
|
|
- Turn the mystery into explicit quest markers
|
|
- Rewrite established characters to fit a new plot
|