Private game server manager through Discord
These instructions will get you a copy of Snout up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.
Install the following services:
Create a new Discord Application and convert it to a bot. Then, copy its token and save it somewhere, it will be required later.
Clone the repository and run npm install to install dependencies. Then, rename .env.example to .env and save it with your own details, such as Redis installation and the forementioned Discord bot token. If you want to change the bot's prefix, change it here.
ATTENTION: It is very important to include a server token and an API url, otherwise the bot will not work as expected, as it relies heavily on the API.
npm start
Starts the bot.
npm run dev
Starts the bot with nodemon, and restarts the process on every file change. For this, please run npm install nodemon -g.
Each file has an @author tag which denotes which member of the team wrote which piece of code. The main purpose of this technique is to provide support for other developers down the line when they need support. Instead of hunting around trying to figure out who wrote what, it's at the top of the file! Alsom be proud of the code you wrote!
We use Prettier. If you want to use our config somewhere else, install @walrusnetwork/prettier-config as a developer dependency and include it in your package.json:
{
"name": "snout",
"version": "0.1.0",
"prettier": "@walrusnetwork/prettier-config",
...
}
We use SemVer for versioning.
- We use Git, with a typical feature branch workflow
- Trivial changes and emergency fixes can be merged straight to the master branch
- Any significant change requires a PR, and code review by at least one other developer. This applies indiscriminately to all developers. Everyone should have their code reviewed, and anyone can review anyone else's code.
- Once a change has been merged to master, it should be deployed ASAP so that problems can be found. Deploying several old changes at once just makes it harder to trace bugs to their source.
- Without automated tests, we rely heavily on user reports and Sentry alerts to discover regressions. Developers should be around for at least a few hours after their change is deployed, in case something breaks.