https://github.com/halimath/fate-core-remote-table
Remote table for Fate Core roleplaying games
https://github.com/halimath/fate-core-remote-table
fate fate-core remote-play rpg
Last synced: 11 months ago
JSON representation
Remote table for Fate Core roleplaying games
- Host: GitHub
- URL: https://github.com/halimath/fate-core-remote-table
- Owner: halimath
- License: apache-2.0
- Created: 2021-10-09T07:14:09.000Z (over 4 years ago)
- Default Branch: main
- Last Pushed: 2024-05-11T10:55:27.000Z (about 2 years ago)
- Last Synced: 2024-06-21T17:05:07.169Z (almost 2 years ago)
- Topics: fate, fate-core, remote-play, rpg
- Language: Go
- Homepage:
- Size: 8.44 MB
- Stars: 3
- Watchers: 3
- Forks: 1
- Open Issues: 4
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# fate-core-remote-table
[](https://github.com/halimath/fate-core-remote-table/actions/workflows/ci.yml)
[](https://github.com/halimath/fate-core-remote-table/actions/workflows/cd.yml)
A virtual remote table for playing [Fate Core](https://www.evilhat.com/home/fate-core/) role playing
games.
## About
This repo contains a web application that supports people playing any kind of _Fate Core_ based role playing
game remotely using whatever video conferencing tool they like. This app adds support for
* rolling fate dice - in case you don't have physical ones
* manage fate points
* share _aspects_ with all players
# Architecture
This application is build from two parts:
1. a backend service managing data and distributing data update among players
1. a web frontend consiting of a single page application that can be used with different devices
The parts communicate using a REST API and communication utilizes the [CQRS](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation#Command_query_responsibility_segregation)
paradigm. The communication protocol is documented in
[`docs/api.yaml`](./docs/api.yaml) which is an [OpenAPI](https://www.openapis.org/) spec.
The frontend application uses an internal architecture modeled after the well known _model, view, control_
pattern. A _controller_ receives _messages_ that describe updates to the _model_ and executes them, returning
a new _model_ value to be rendered by the _view_ functions. The weccoframework provides excellent support for
implementing this kind of architectures.
The backend applies an onion architecture style with domain entities in the center, surrounded by use case
functions and persistence and RESTful API placed around that. Currently, persistence is only implemented
_in-memory_.
# Development
The backend is implemented using Golang 1.22. The frontend is implemented using
TypeScript and the [wecco framework](https://weccoframework.github.io). Almost all CSS is coming from
[Tailwind](https://tailwindcss.com/) with minimal CSS being written to embed the Fate Core font for displaying
dice results.
## Local Environment
For being able to develop the app, you should have a local install of
* Golang >= 1.22
* Node v20
* NPM (>=10.5)
You should also have an IDE which supports Golang and TypeScript. VSCode works perfectly, IntelliJ IDEA works,
too. I haven't tried other IDEs, but the should work the same.
To get working locally, you should open two terminal windows (or tabs or whatever you use). In the first,
run
```
backend$ go run .
```
This will start the backend on `localhost:8080`.
In the second terminal, run
```
$ cd app
app$ npm i
app$ npm start
```
(You need to install dependencies with `npm i` only once or when the `package.json` file changes). This will
start the webpack dev server to bring up the frontend on `localhost:9999`.
Now point your browser to [http://localhost:3000](http://localhost:3000) and you can use the app.
## Running Tests
Currently, we use three different test stages:
* unit tests (currently only implemented for the backend) test components in isolation
* API tests test the backend API
* end-to-end-tests test the full application with multiple browser sessions to simulate multiple session
participants
The first two stages are implemented as plain Golang tests.
The last stage is implemented as Python [Playwright](https://playwright.dev/python/) tests.
## CI/CD
Both parts of the application are wrapped in a single OCI container build with `podman` (but you can use
Docker as well). The container build uses multiple stages and builds the whole app as part of the container
build. The final container will only contain the compiled application, though.
We use [Github Actions](https://github.com/features/actions) to build the application, run the tests, build
the container image and publish it to [https://ghcr.io](https://github.com/features/packages).
# License
Copyright 2021 - 2024 Alexander Metzner.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
[http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0)
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.