zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
2.3 KiB
Games
Tachi supports multiple games at the same time. It does this using Games and Playtypes.
What's a playtype?
A playtype is a 'sub game' for a given game. For example, DDR has two 'playtypes', one where the player plays on 4 panels, and one where the player plays on 8 panels.
For DDR, these are referred to as SP and DP - corresponding to Single Play and Double Play.
Games MUST have playtypes, even if the game only has one practical playtype!
For this scenario, the playtype Single is used, so for
something like SDVX, it would be SDVX Single.
Why?
Playtypes are for separating different scores on the same game, we don't want to get a user's DP scores mixed with their SP scores as, for all intents and purposes, they are completely separate games that need completely different skills!
As for why games MUST have playtypes, it's generally for futureproofing, and it works nicely with the codebase.
For games that don't really have multiple playtypes, this fact is hidden in the UI, but might still poke up in URLs.
What games and playtypes are supported?
Kamaitachi
The following games are supported on Kamaitachi.
| Name | Internal Name | Playtypes |
| :: | :: | :: |
| beatmania IIDX | iidx | SP, DP |
| CHUNITHM | chunithm | Single |
| MÚSECA | museca | Single |
| SOUND VOLTEX | sdvx | Single |
| WACCA | wacca | Single |
| pop'n music | popn | 9B1 |
| jubeat | jubeat | Single |
| GITADORA | gitadora | Gita, Dora |
| maimai DX | maimaidx | Single |
| maimai | maimai | Single |
| O.N.G.E.K.I. | ongeki | Single |
| Dance Dance Revolution | ddr | SP, DP |
Bokutachi
The following games are supported on Bokutachi.
| Name | Internal Name | Playtypes |
| :: | :: | :: |
| BMS | bms | 7K, 14K |
| unnamed_sdvx_clone | usc | Controller Keyboard2 |
| PMS | pms | Controller, Keyboard2 |
-
Pop'n had some other playtypes, namely a 5-Button mode, but it seems to be removed now. 9B is used instead of single here for futureproofing. ↩︎
-
This use of playtypes is a small hack to make separate leaderboards for keyboard and controller players. The split is necessary because the two input mechanisms are very different at high levels, but there are still a lot of keyboard players. It's a compromise! ↩︎