1 OTTER - ONLINE TABLE TOP ENVIRONMENT RENDERER
2 =============================================
4 Otter is an online "table simulator" intended to be suitable for board
7 It is accessed from a web browser running JavaScript. The server runs
8 on a convenationl Unix host. Currently, joining a game requires a
9 unix shell account on the server.
11 I expect it to be used with a concurrent voice chat.
13 The game server does not currently have a built-in text chat system.
14 The game organiser can use the game server to distribute (and update)
15 voice chat and info links.
17 Right now Otter is in an alpha state.
25 otter join-game unix:<user>::<game-name>
29 otter join-game unix:ijackson::test
32 See `otter --help` for further options, including setting your nick.
34 Currently when a new player joins a game (with the `otter` command),
35 all the other players must reload the page.
42 otter reset --reset-table local-users :test demo
43 /^^^^^^^^^^^ ^^^\ ^^^^'~ game spec
47 Here `local-users` refers to the file `local-users.table.spec` in the
48 Otter specs directory (`/volatile/Otter/specs` on chiark). The table
49 spec file handles access control (and some other global properties)
50 This particular file says that all local shell account users may join
53 `:test` is the game name. It starts with a colon, which means
54 implicitly `unix:<whoami>::test`. Other people have to name the game
55 with the full name, with all three colons in it.
57 `demo` refers to the file `demo.game.spec`. The "game spec" says what
58 shape table is and what pieces there are. This is a simple demo game.
59 There is also `penultima` which is a work-in-progress set of pieces
60 suitable for fairy chess etc.
62 See `otter --help` for some more options.
64 Currently, resetting a game (or otherwise adding or removing pieces)
65 will mean all the players will get errors until they reload the page.
71 If you want to use existing piece shapes that Otter already knows
72 about, you can do this by providing a `<something>.game.toml` file.
73 The format of these files is a TOML document representing a GameSpec
74 as found in `src/spec.rs` in the Otter source code.
76 todo: use rustdoc to provide this somewhere.
82 Otter uses SVGs. The sources for the SVGs are all in the otter source
83 tree, in the `library/` directory.
85 Each shape is listed in one of the `library/*.toml` files, in a
86 `files` entry. (Most of) the syntax and semantics of this file are
87 documented in the Rustdoc documentation for the module
88 `otter::shapelib_toml`. If you run `make -j8 shapelib` it will print
89 out a `file://` url for these docs.
91 You can preview the shapes, including any changes you make, without a
92 whole game server, by running `make -j8 shapelib`, and looking at
93 `templates/shapelib.html`. As above, this make rune will print the
94 `file://` url for you. (See BUILDING AND TESTING for information
95 about how to install the tools you will need.)
97 Some of these SVGs were scraped from Wikimedia. The scraper machinery
98 can perhaps be adapted to scrape SVGs from elsewhere.
100 You can also add your own SVGs in the library/edited/ directory.
101 If you do that, please make sure to include the actual source code.
102 If you copied or adapted an SVG from somewhere, provide details.
104 Contributions should be via git branch, eg a merge request on Salsa:
105 [https://salsa.debian.org/iwj/otter](https://salsa.debian.org/iwj/otter)
107 NB that shapes must come with a licence compatible with CC-BY-SA 4.0
108 or GNU AGPLv3+. See `LICENCE` for more information about copyright status.
114 You will need at least 6000 megabytes of disk space, or more, and a
115 good internet connection. Your computer will be compiling a lot of
118 These instructions have been tested on Debian buster.
126 sudo apt install build-essential cpio git curl \
127 pkg-config libssl-dev \
128 node-typescript inkscape bubblewrap
131 2. Install Rust. This is most easily done with [rustup](https://rustup.rs)):
134 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
137 and then follow the instructions about your `PATH`. If this rune
138 alarms you, see below about Rust privsep.
140 3. Switch your Rust install to use Rust Nightly and add the WASM
144 rustup default nightly
145 rustup target add wasm32-unknown-unknown
148 Unfortunately, it is possible that the Rust nightly you find when
149 you run this is missing some pieces. The following is known to
150 work (with otter from the time of writing):
152 rustup default nightly-2021-01-26
155 4. Install the `usvg` SVG launderer, which we need for shape libraries
161 This will put it in `~/.cargo/bin`, which you presumably have on
162 your `PATH` (or the above `rustup` and `cargo` runes wouldn't work).
165 ** If you just want to edit and preview the shape libraries
166 (ie the piece shapes) you can stop here **
169 5. Install some more build tools:
172 cargo install bundle-sources
180 git clone https://salsa.debian.org/iwj/otter
182 make -j8 all bundled-sources
185 Or if you just want to edit the piece libraries:
190 And then open `./templates/shapelib.html` in your browser
199 target/debug/daemon-otter server-test.toml
202 The server does not daemonise, and the default config there makes it
203 quite verbose. So, in another shell:
207 --account server: --config server-test.toml --spec-dir=specs \
208 reset --reset-table test server::test demo
211 --account server: --config server-test.toml --spec-dir=specs \
212 join-game server::test
215 The URL printed can then be visited in a local browser.
218 Resetting/restoring things after tests, updating server, etc.
219 -------------------------------------------------------------
221 After the server is updated, you can just `^C` and restart it. Games
222 are constantly saved (although there is an up-to-1s lag on the most
223 frequently udpated game state).
225 If you want to clear out the server state, delete the files `[ag]-*`
226 and `accounts`. NB that you should do this with the server not
227 running, because the server has most of that information in memory and
228 will like to write it out again.
230 If you update Typescript (JS code) you will need to rerun `make` to
231 rebuild the JS output.
233 Apart from that, if you update JS or WASM code or Tera templates, you
234 do not need to restart the server - it will pick up changes
237 When testing, you do not need to `make bundled-sources` more than
238 once, at the beginning. So don't, because it's slow. But you
239 definitely should run it for every update if you make a deployment for
240 other people to use. Otherwise you might be running a privately
241 modified server without offering your users its source code. See
244 If you Do Something to the output from cargo, you should `rm stamp/*`,
245 since the `Makefile` won't notice, otherwise, that, the relevant cargo
246 rune(s) need to be re-run. Needlessly deleting all the stamp files
247 wastes only a handful of seconds (on my stupidly fast laptop).
250 Navigating the otter source code
251 --------------------------------
255 The main Rust source code. This is mixture of code used only or
256 mainly by the server and code used by the `otter` command line
257 utility; these aren't split up in a wholly principled way. In Rust
258 terms this is a "library crate".
262 Support executables, including in particular the command line
263 utility `otter` which is used to set up and join games.
267 The Otter server. This is a simple binary crare. Much
268 functionality belonging primarily, or only, to the server, is in
269 `src/`, simply because it was easier not to disentangle it.
270 Anything that needs Rocket (the web framework) is in `daemon/`.
274 Code shared by the host and the WebAssembly. Notably, the Z
275 coordinate handling, but also a a few other minor functions needed
276 by both client and server. To avoid duplicating them are written
277 once in Rust and compiled twice - once for the host and once for
278 WebAssembly for use in the client. This crate is kept minimal to
279 keeep the WebAssembly binary small.
283 WebAssembly/Rust bindings for the items in `zcoord/`. Produces the
284 single wasm file for use by the JavaScript, and corresponding
285 Typescript annotations etc.
287 * `templates/script.ts`
289 The main Typescript (typed Javascript) code. Otter's web
290 compatibility target is the earliest browser versions that properly
293 * `templates/session.tera`, `macros.tera`, etc.
295 Tera templates generating the main HTML screen. These templates are
296 filled in from structs in the Rust source code. The main files are
297 `session.tera` (portrait), `landscape.tera`, and `macros.tera`
298 (common), and their rendering uses an instance of
299 `SessionRenderContext` from `src/session.rs`.
303 "Non-web templataes". Tera templates for things other than web
304 pages. Currently this includes the server's outgoing emails. These
305 have to be in a separate directory because Rocket likes to load
306 everything applicable it finds in its own `templates/` directory.
307 These are used via `src/nwtemplates.rs`.
309 * `wdriver.rs`, `wdriver/`
311 WebDriver-based end-to-end tests. Each `wdt-*.rs` is one test
312 utility. `wdriver.rs` (in the top level to evade Cargo's
313 dur-brained search rules) is the library for these, and contains
314 most of the heavy lifting.
316 These are not standard Rust `#[test]` tests because they need to
317 reinvoke themselves via `bwrap` for test isolation reasons, and
318 because their dependencies are extensive and not properly capturable
319 in Cargo. They are run by `make check`.
321 * `library/`: The shape libraries.
323 The program `./media-scraper` (which is not run by the `Makefile`)
324 reads `library/*.toml` for instructions and generates `files.make`
325 fragments. These fragments arrange to run `./usvg-processor` which
326 launders SVGs through `usvg`. `usvg-processor`.
328 The shape libraries have a different, more relaxed, copyright
332 Automatic in-browser tests
333 --------------------------
335 * `apt install firefox`
337 * `https://github.com/mozilla/geckodriver/releases/tag/v0.28.0`
338 download appropriate tarball, put "geckodriver" on PATH
340 `make check` runs all the tests; `make wdt` runs only those tests. You can run
341 an individual test with a rune like this:
344 OTTER_TEST_LOG=otter_webdriver_tests=trace CARGO_MANIFEST_DIR=~ian/Rustup/Game/server time target/debug/wdt-simple --geckodriver-args=
347 (This rune has some example logging options in it, for you to change
348 if you like. You can omit the `CARGO_MANIFEST_DIR` for an in-tree
349 non-privsep build.) After a test has run, you can find screenshots,
350 etc. in `tmp/wdt-simple` or whatever. You can restart the same game
351 server setup as the test used, with the state left by the test, with a
355 target/debug/daemon-otter tmp/wdt-simple/server-config.toml
357 and then play with it at this url:
359 http://localhost:8000/?kmqAKPwK4TfReFjMor8MJhdRPBcwIBpe
363 Rust, cargo, curl|bash-ware; privsep
364 ------------------------------------
366 If you follow the above instructions you will have downloaded and
367 executed - and, therefore, trusted:
369 * Various Debian packages - safe
370 * Rustup (the Rust downloader/installer) - this is pretty safe
371 * Rust itself - again, pretty safe
372 * Otter itself - well, I wrote this; up to you.
373 * 450 transitive dependencies of otter (from crates.io)
374 * 50 transitive dependencies of bundle-sources
375 * the transitive dependencies of resvg
376 * a geckodriver binary directly from mozilla
378 You will have trusted the integrity of the following:
380 * The Debian archive (via its apt keyring) (very good)
381 * Rustup's and Rust's TLS keyholders (good, I think)
382 * The HTTP TLS cabal (sigh)
383 * github (pretty good in practice)
384 * whatever mozilla do to make binaries, in particular geckodriver
385 * crates.io (extremely poor traceability)
386 * the project management of hundreds of random crates.io libraries
388 If this makes you uncomfortable, as it should, you may wish to
389 consider running everything in a separate shell account, or a VM or
390 container of some kind.
392 (I have a not-properly-released tool called "nailing-cargo" which
393 makes it possible to do most things in my main account but run the
394 Rust stuff in a separate less-privileged account. There is support
395 for this in the Makefile. But if you want to run *everything* in the
396 lesser account, you don't need to bother with that.)
399 Dependencies - apologia
400 -----------------------
404 This is needed almost solely because Rocket needs it. Rocket is
405 the web framework I am using. The next version of Rocket (0.5.x),
406 which is in development, will not need Nightly, but it will also be
407 a serious compatibility break. The existing Rocket (0.4.x) will
408 almost certainly never be ported to Stable Rust. When Rocket 0.5.x
409 is out, porting Otter to it will go on my list - but it won't be
412 * The many dependencies of Otter
414 These are partly because Rocket is a large piece of software with
415 much functionality. But also because I favoured my own programming
416 convenience and in some cases was experimenting with different
417 approaches. In practice, it seems to me that once I'm using Rocket
418 and WASM and resvg and so on, there is not that much to be gained
419 by trying to prune the dependencies of the otter package itself.
421 * bundle-rust-sources
423 This is mine, but it needs to be properly released.
425 * geckodriver (for the automated in-browser tests)
427 This is done with a protocol called "WebDriver" which is a
428 cross-browser way to puppet a browser. There is a thing called
429 "geckodriver" which converts that to a firefox-specific protocol
430 for the same purpose, called "Marionette". (In practice all this
431 seems to have lots of bugs and misfeatures.)
433 AFAICT the usual approach for using geckodriver to have it *bind to
434 a fixed TCP port accessible to all local programs*. My wrapper
435 tooling arranges to run this in an ephemeral $HOME and a private
438 AFAICT the only practical way to get geckodriver is to download the
439 binary. I got mine here:
440 https://github.com/mozilla/geckodriver/releases/tag/v0.28.0 You
441 You just dump the binary on your PATH.
447 * For running on chiark I build with the Rust target
448 `x86_64-unknown-linux-musl` which on my system is configured to
449 produce a completely statically linked bionary. I have this in my
450 `~/.cargo/config` (in the lesser privsep account):
453 [target.x86_64-unknown-linux-musl]
454 rustflags = ["-C", "target-feature=+crt-static"]
455 # ^ from https://stackoverflow.com/questions/31770604/how-to-generate-statically-linked-executables