This app is still being actively developed. Find the latest production deployment at: https://play-werewolf.app/

• Overview
• Features
• Tech Stack
• Contributing and Developers' Guide
• Testing
• Code Formatting

Overview

A free, anonymous application to run games of Werewolf (Mafia) smoothly when you don't have a deck, or when you and your friends are together virtually. Basically, a host builds a game and deals a role to everyone's device, and then the app keeps track of the game state (timer, who is killed/revealed, etc). Since people tend to have their own preferences when it comes to what roles they use or how they run the game, the app tries to take a generalized, flexible, hands-off approach - it won't run day and night for you and won't implement any role abilities. Hosts can use any roles they want, in any configuration, and can create their own roles if the provided ones don't meet their needs.

A good overview of usage can be found on the app's "How to Use" page: https://play-werewolf.app/how-to-use

The app prioritizes responsiveness. A key scenario would be when a group is hanging out with only their phones.

Inspired by my time playing Ultimate Werewolf and by 2020's quarantine. After a long hiatus I've rewritten a lot of the code. This was (and still is) fundamentally a learning project, so feedback or assistance is appreciated.

Features

You can:

• build your desired game with default or custom roles.
• join a game via a shareable link, a 4-character code entered on the homepage, or a QR code.
• automatically deal cards to everyone's device.
• create a game as a "dedicated moderator", who is not dealt in, or as a "temporary moderator", who is dealt in and then has their powers automatically delegated.
• transfer your mod powers to someone else that is out of the game if you can no longer mod.
• run a shared timer that can be paused by the moderator.
• reference helpful info during the game including what roles are in the game and who has been killed or revealed.
• choose to reveal a player without killing them, or kill them without revealing them.
• restart the same game setup any number of times.

Tech Stack

This is a Node.js application. It is written purely using JavaScript/HTML/CSS, with no front-end framework. The main dependencies are Express.js, Socket.io, and Node-Redis. It runs as a containerized application via Google Cloud Run.

No data is stored persistently. The app is almost entirely stateless, with instances kept in sync via Redis, specifically with the pub/sub model. The exceptions are a browser cookie and the Node.js child processes that are spawned to keep track of games with a timer, which are stored in an instance's memory and communicated to other instances if needed. In the end, it should not matter which instance a given client connects to.

Contributing and Developers' Guide

Running Locally

The entrypoint for the application is index.js at the root.

Before starting the Node.js server, you'll need a Redis server running locally on the default port. This is what's used to store active games and keep any number of Node.js servers in sync. I followed this tutorial, specifically using the installation method that uses Windows Subsystem for Linux (WSL), since I am on a windows machine. Once I got WSL and Redis installed and was in a linux environment running in the powershell, I tested out the Redis server by using the Redis CLI (see their getting started page).

Once that's done, if you haven't already, install Node.js. This should include the node package manager, npm.

Run npm install from the root directory to install the necessary dependencies.

These instructions assume you are somewhat familiar with Node.js and npm. At this point, we will use some of the run commands defined in package.json.

If you simply want to run the app on the default port of 5000:

npm run start:dev (if developing on a linux machine)
npm run start:dev:windows (if developing on a windows machine)

If everything is okay, you should see logs indicating a connection to Redis and a starting of the web server.

This command uses nodemon to listen for changes to server-side code (Node.js modules) and automatically restart the server. If you do not want this, run instead npm run start:dev:no-hot-reload or npm run start:dev:windows:no-hot-reload.

If you are making changes to client-side javascript, in a separate terminal, execute npm run build:dev. This uses Webpack to bundle javascript from the client/src directory and place it in the client/dist directory, which is ignored by Git. This command uses the --watch flag, which means the process will continue to run in this terminal, watching for changes within the client/src directory and re-bundling automatically. You definitely want this if making frequent JavaScript changes to client-side source code. Any other changes, such as to HTML or CSS files, are not bundled, and thus your changes will be picked up simply by refreshing the browser.

Note: in the development environment, cookies are stored using sessionStorage (vs. localStorage in production). This makes it a lot easier to create/run test games, as you can join as different people in different tabs.

CLI Options

These options will be at the end of your run command following two dashes: npm run start:dev -- [options]. Options are whitespace-delimited key-value pairs with the syntax [key]=[value] e.g. port=4242. Options include:

• port. Specify an integer port for the application.
• loglevel the log level for the application. Can be info, error, warn, debug, or trace.
• protocol either http or https. If you specify HTTPS, the server will look in client/certs for localhost certificates before serving the application over HTTPS - otherwise it will revert to HTTP. Using HTTPS is particularly useful if you want to make the application public on your home network, which would allow you to test it on your mobile device. Careful - I had to disable my computer's firewall for this to work, which would of course make browsing the internet much riskier.

example run command:

npm run start:dev:windows -- port=4242 loglevel=trace protocol=https

Admin API

The app exposes an admin API at /api/admin, e.g. localhost:5000/api/admin.

The admin api doesn't require any authentication in the development environment (but does in prod).

Currently, the available operations are:

• GET /games/state - returns a JSON array of the currently existing games.

• POST /sockets/broadcast - broadcasts a message to all connected sockets. This is not currently handled on the front-end, so it will not display anywhere.

Example cURL

curl --location --request GET "http://localhost:5000/api/admin/games/state"

Have a question that isn't covered here? Email me at play.werewolf.contact@gmail.com

Testing

Tests are written using Jasmine. End-to-end tests are run using Karma.

Execute all tests by running npm run test. Execute unit tests by running npm run test:unit. Execute end-to-end tests by running npm run test:e2e.

Unit tests map 1:1 to the application directory structure - i.e. unit tests for server/modules/GameManager are found in spec/unit/server/modules/GameManager_Spec.js

Code Formatting

This application uses ESLint to enforce code formatting standards. This configuration is found at the root in .eslintrc.json. To audit the codebase, run npx eslint [directory], and to fix them along with that, run npx eslint [directory] --fix.