bnanz0/ok-duet-night-abyss

1. Overall purpose

- This repository is a Windows-based Python automation tool for the game *Duet Night Abyss*.

- It does not inject into the game; the automation loop works by reading screen/UI state and sending simulated input, including support for background operation.

2. Core architecture style

- The code is organized around a task-driven automation engine.

- High-level tasks decide what to do next, while lower-level modules provide scene recognition, combat checks, character interaction, and input-triggered behaviors.

- The design is modular enough to support built-in automation and externally packaged “Mod” logic.

3. Entry points and runtime

- main.py is the normal launcher; main_debug.py is the verbose/debug launcher.

- The project targets Python 3.12 on Windows, and the README indicates the game should run at 1600×900 or higher for reliable image matching.

- Packaging and distribution are supported through GitHub releases and PyAppify-related configuration.

4. Task orchestration layer

- src/tasks is the main orchestration boundary.

- It contains specialized automation flows such as:

- general automation and exploration

- escort, fishing, excavation, expulsion, defense, hedge, skill use

- commission handling and one-time DNA tasks

- Subpackages split execution styles:

- fullauto for end-to-end autonomous loops

- trigger for reactive, condition-driven behaviors

- This is the primary place where the bot decides “what mode am I in?” and “what sequence should run now?”

5. Base task abstractions

- Shared task behavior appears to live in:

- BaseCombatTask

- BaseDNATask

- BaseListenerTask

- These likely define lifecycle, polling, state transitions, and the integration points between detection, combat, and input handling.

- CommissionsTask, DNAOneTimeTask, and similar classes are concrete flows built on those base abstractions.

6. Scene recognition and state detection

- src/scene/DNAScene.py is the most explicit scene module and likely encapsulates UI/state recognition for the game.

- assets/coco_annotations.json and the image assets indicate an image-recognition pipeline driven by reference screenshots or annotations.

- src/process_feature.py and src/globals.py suggest shared feature extraction / state context used across tasks.

7. Combat and character domain

- src/combat/CombatCheck.py handles combat-state detection or readiness checks.

- src/char/BaseChar.py suggests character-specific logic, likely abstracting skills, actions, or character capabilities.

- src/LabelEnum.py probably centralizes recognition labels used by detection and decision-making code.

8. Configuration and task parameters

- src/config.py is the global configuration boundary.

- Task-specific configuration is separated under src/tasks/config, including commission and skill-related settings.

- This separation implies the runtime behavior is shaped by user-facing configuration rather than hardcoded mode-specific values.

9. Mod/extensibility model

- The mod directory is a first-class extension mechanism.

- It includes built-in path definitions such as escort_paths.json and puzzle_paths.json, plus example community content with scripts and map assets.

- The README confirms users can drop external mods into mod/ and restart to load them, so the architecture explicitly supports pluggable automation logic and custom recognition materials.

10. Internationalization and assets

- The i18n directory contains compiled and source message catalogs for multiple locales: English, Chinese, Japanese, Korean, Spanish, and Traditional Chinese.

- This suggests the UI or logs are localized, while the automation logic remains language-aware through these catalogs.

- assets/images, icons, and annotation files are part of the recognition and packaging pipeline.

11. Testing and validation

- tests/TestMissonInterface.py and tests/images indicate automated validation around mission/UI recognition.

- The presence of GitHub workflows for build, test, stale cleanup, and release notes implies CI is used to verify packaging and basic behavior.

12. Important architectural boundary

- The main boundary in this repo is between:

- screen/state understanding via image recognition and scene checks

- decision logic in tasks and triggers

- action execution via simulated inputs and background-compatible interaction

- For an architecture diagram, the central flow is: game screen → recognition/state modules → task/trigger logic → input/output actions → back to game screen, with mod/ and configuration altering the behavior of that loop.