No description
- Rust 96.9%
- Lua 1.2%
- Shell 0.8%
- Nix 0.6%
- Python 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
13e372ef28
backend-kindle drives the same ui::App as backend-desktop, over: - Output: render into the same u32 buffer, write it as a raw PGM, and shell out to a vendored FBInk binary to push it to /dev/fb0 -- matches ARCHITECTURE.md's stated preference for FBInk's partial-refresh/dithering over reimplementing this MTK panel's refresh ioctls. First push after launch flashes a full GC16 refresh to clear whatever was on screen before (avoids ghosting); every turn-to-turn update after that uses the faster GC16_FAST. - Input: evdev on the touchscreen's /dev/input/eventN. This digitizer's KEY capability bitmap is empty -- it signals touch contact only via ABS_MT_TRACKING_ID (-1 = lifted), not BTN_TOUCH, so that's what's watched for down/up state. - Loop: blocks on input rather than polling at a fixed framerate (this is turn-based; nothing to redraw between actions), with a short poll timeout only while a frame-counted transition is actually in flight (wake-up delay, spectate stepping) so those don't crawl at the idle interval. Skips re-rendering entirely when idle (finger up, nothing animating) since nothing could have changed -- the bigger board/text needed for real-device legibility made unconditional per-tick rendering a real CPU cost. Cross-compiles to a fully static armv7-unknown-linux-musleabihf binary via rustc's bundled rust-lld, so no external ARM cross toolchain is needed and the device's old glibc 2.20 is a non-issue. The vendored FBInk binary is a copy of one already confirmed working on this exact device (a fuller build with image support the KOReader-bundled one lacks); the CJK font is subsetted from Noto Sans CJK's ~16MB collection down to ~90KB covering only the characters the game actually draws (scripts/collect_chars.py + subset_font.sh regenerate it as the drawn character set grows). Launch is a KOReader plugin (`deploy/kindle/maoji.koplugin`) rather than a KUAL/appmgrd registration: appmgrd runs registered apps as a restricted "framework" user with no access to /dev/fb0 or the touch device, while a plugin's os.execute inherits KOReader's own root privileges and blocks its single-threaded event loop for the whole run. The one thing os.execute blocking doesn't do is release KOReader's own exclusive grab on the touch device, so the plugin explicitly tears down and reopens KOReader's input around the game's run -- without that, the game process is alive and rendering but never receives a single touch event. |
||
| .cargo | ||
| .opencode | ||
| crates | ||
| deploy/kindle/maoji.koplugin | ||
| docs | ||
| scripts | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| flake.lock | ||
| flake.nix | ||
| README.md | ||
漢字狩り (kanji-gari) — working title
A very small, very short roguelike inspired by Brogue, built for reading on an e-ink screen instead of a terminal.
The pitch
- No terminal glyphs. Every tile, monster, and item is drawn as a square kanji — never hiragana or katakana, since a single kana character has no real standalone meaning and would undercut the point — rendered from a real CJK font, not a fixed-width terminal cell. Glyphs are chosen with real meanings and, where reasonable, real JLPT levels (favoring N5/N4 for anything seen constantly, like terrain), so picking up genuine kanji recognition along the way is part of the fun.
- Monochrome, e-ink first. White background, black glyphs, grayscale/dithering only where it earns its keep (fog of war, damage state, etc). Built and tuned for a jailbroken Kindle, developed on a Linux desktop (NixOS) first.
- Touch/mouse only. No keyboard. Swipe (or click-drag) to move, click to interact or inspect depending on how close you are to the thing you clicked.
- Much shorter than Brogue. A run is: 3 jungle levels → a cave entrance → a random mix of underground dungeon and library levels (at most 5 of them) → one final level with a portal. Reaching the portal wins.
- A hidden score, revealed once. Unlike Brogue's visible gold count, this game never shows you a score during play. It's quietly tallying how many monsters you kill, how many you talk your way past by fleeing successfully, and how many items you find or use — and only shows you the total on the win/death screen.
Status
Planning stage. This repository currently contains design and architecture documents only — no game code yet. The plan below is written to be handed off to another LLM (referred to during planning as "Qwen") to implement, phase by phase, with a manual testing gate at the end of every phase.
Where to look
| Doc | What's in it |
|---|---|
docs/GAME_DESIGN.md |
The game loop, controls, level flow, scoring, and the all-kanji glyph legend system (with a JLPT-level guideline). Read this first — it's the part that must not drift during implementation. |
docs/ARCHITECTURE.md |
Tech stack, crate layout, the shared tile-grid engine, the two renderer/input backends (desktop + Kindle), and the NixOS dev environment. |
docs/ROADMAP.md |
Phase-by-phase build plan from empty repo to a playable desktop MVP, then on to the Kindle port. Every phase ends with an explicit, human-run test gate. |
Target platforms
- Development / MVP: Linux desktop (NixOS), square window, mouse input standing in for touch.
- Shipping target: jailbroken Kindle (e-ink), touchscreen input, screen scaled to 1264×1680
(the plan starts square and grows into this rectangle deliberately — see
ARCHITECTURE.md).
Non-goals (for this MVP)
- No keyboard support, ever — this is a touch-first game.
- No color — grayscale/dithering only.
- No procedurally-infinite dungeon; runs are intentionally short (roughly a dozen levels, bounded).
- No real-money or persistent meta-progression systems.