docs(obsidian): process inbox notes
This commit is contained in:
@@ -1,68 +0,0 @@
|
||||
# Ariadne project goals
|
||||
|
||||
Ariadne analyzes a local Ren'Py game install.
|
||||
It extracts source, builds a source graph, and plans routes through target nodes.
|
||||
|
||||
## Privacy constraint
|
||||
|
||||
Do not write the target game's title in the monorepo.
|
||||
Use `target game` or `Ren'Py game` in committed notes, code, and pull requests.
|
||||
Keep title-specific paths and names in ignored local data only.
|
||||
|
||||
## Goal order
|
||||
|
||||
1. Unlock all Steam achievements.
|
||||
2. Maximize Season 3 dialogue coverage.
|
||||
3. Extend the same coverage work to Seasons 1 and 2.
|
||||
|
||||
## Steam achievements
|
||||
|
||||
Achievement unlocks appear in source as reachable calls.
|
||||
The first planning target is every achievement grant node.
|
||||
|
||||
Ariadne needs to find each grant call and compute route conditions that reach it.
|
||||
This is source-graph coverage over sparse semantic targets.
|
||||
|
||||
## Season 3 dialogue coverage
|
||||
|
||||
Season 3 exposes an in-game percentage for seen dialogue.
|
||||
The stat computes Ren'Py dialogue-block coverage from persistent seen data.
|
||||
|
||||
For this game, dialogue blocks map mainly to unique `Say` statements.
|
||||
Ariadne should target Season 3 `Say` nodes as coverage targets.
|
||||
|
||||
The in-game percentage gives a validation signal for Ariadne's coverage model.
|
||||
Season 3 also rewards high coverage inside the game.
|
||||
|
||||
## Seasons 1 and 2 coverage
|
||||
|
||||
Seasons 1 and 2 lack the same in-game percentage display.
|
||||
Ariadne can still compute source coverage for their dialogue nodes.
|
||||
|
||||
Validation for these seasons will depend on Ariadne's own model.
|
||||
Persistent seen data can still help later.
|
||||
|
||||
## State model phases
|
||||
|
||||
The first phase ignores player state.
|
||||
It asks which routes cover all targets from source alone.
|
||||
|
||||
A later phase reads existing player state.
|
||||
It uses save files or persistent data to remove completed targets.
|
||||
|
||||
That phase produces a personalized plan for remaining achievements and dialogue coverage.
|
||||
|
||||
## Graph model
|
||||
|
||||
The source graph needs typed nodes for labels, jumps, conditions, menus, visual statements, dialogue, and achievement grants.
|
||||
Menus and conditions require branch edges and merge edges.
|
||||
|
||||
Dialogue and visual nodes support route explanation.
|
||||
Achievement and dialogue nodes become coverage targets.
|
||||
|
||||
## Near-term implementation direction
|
||||
|
||||
Keep extraction and decompilation generic.
|
||||
Parse source into typed graph artifacts.
|
||||
Add achievement grant nodes before broad route planning.
|
||||
Add Season 3 dialogue nodes as the next coverage target set.
|
||||
@@ -1,71 +0,0 @@
|
||||
# SteamCMD servers
|
||||
|
||||
Use `modules.services.steamcmd` as the low-level runner for one SteamCMD server.
|
||||
Create a game module under `configs/nixos/modules/services/games/` for each game.
|
||||
|
||||
The game module owns game-specific defaults and command-line flags.
|
||||
The host owns deployment-specific paths, names, secrets, and network placement.
|
||||
|
||||
## Create a game module
|
||||
|
||||
1. Create `configs/nixos/modules/services/games/<game>.nix`.
|
||||
2. Define options under `modules.services.games.<game>`.
|
||||
3. Expose only values the host must choose.
|
||||
4. Map those values to `modules.services.steamcmd`.
|
||||
5. Set the Steam dedicated-server app ID in the game module.
|
||||
6. Set the server executable in the game module.
|
||||
7. Generate game-specific arguments in the game module.
|
||||
8. Open the game's documented UDP ports in the game module.
|
||||
|
||||
Keep `modules.services.steamcmd` focused on shared SteamCMD behavior.
|
||||
Do not put game-specific flags or port rules there.
|
||||
|
||||
## Configure a host
|
||||
|
||||
During validation, enable the game module directly on a host.
|
||||
|
||||
```nix
|
||||
modules.services.games.valheim = {
|
||||
enable = true;
|
||||
steamDir = "/pikachu/data/steamcmd";
|
||||
installDir = "/pikachu/data/servers/valheim/main";
|
||||
stateDir = "/pikachu/media/games/servers/valheim/main";
|
||||
serverName = "main";
|
||||
password = "foobarbaz";
|
||||
};
|
||||
```
|
||||
|
||||
Use host paths for direct host deployment.
|
||||
Use guest paths after the server moves into a guest.
|
||||
|
||||
## Deploy and test
|
||||
|
||||
1. Evaluate the host configuration.
|
||||
|
||||
```sh
|
||||
nix eval .#nixosConfigurations.<host>.config.system.build.toplevel.drvPath --raw
|
||||
```
|
||||
|
||||
2. Deploy the host.
|
||||
|
||||
```sh
|
||||
deploy-to <host>
|
||||
```
|
||||
|
||||
3. Check the game service.
|
||||
|
||||
```sh
|
||||
sudo systemctl status <game>.service
|
||||
sudo journalctl -u <game>.service -n 200 --no-pager
|
||||
```
|
||||
|
||||
4. Check UDP listeners.
|
||||
|
||||
```sh
|
||||
sudo ss -lunp | grep -E '<port>|<port-plus-one>|<game>'
|
||||
```
|
||||
|
||||
5. Connect from the game client.
|
||||
|
||||
The Valheim server is ready after the log contains `Game server connected`.
|
||||
It can spend time generating a new world before it accepts connections.
|
||||
Reference in New Issue
Block a user