GM Tools

GM Tools

GM Tools (short for Game Master Tools) is a suite of services designed to simplify and automate common tasks for GMs while running role playing games. I created it with Dungeons & Dragons 5th Edition in mind, but it could be adapted to other games. The services provided include:

  • A dice roller
  • A treasure haul generator
  • A repository of world building resources

This is a work in process. Additional applications are on the way. All of the services are accessible as a set of APIs that respond to standard HTTP requests.

Project Background

I created this project to showcase a number of technologies and software methodologies in a real-world use case. It’s been a fun project to work on, and has presented a number of interesting design challenges that aren’t found in a lot of contrived demo applications, such as the age-old “To Do List”.

Because this is meant to be a showcase application some of the implementation details are overkill for the problem being solved. Do we really need robust logging and dozens of automated tests around a randomized dice-rolling app? Maybe not, but these details provide a good example of how these methodologies can be applied in other applications.

Deploying and Using GM Tools

Instructions for interacting with the APIs can be found on their respective Github pages. Steps for setting up the entire suite can be found in the GM Tools: Docker Configuration page. This project contains the docker-compose file which is used to orchestrate all of the individual services.

Technical Architecture

GM Tools utilizes a microservice architecture in which each individual service exists as a standalone Ruby on Rails application. Where necessary these services communicate via HTTP. The whole suite is containerized using Docker, so setting up and deploying the entire suite can be done in just a few steps in the terminal.

The microservice approach offers a number of benefits, including:

  • Separation of Concerns: The responsibilities of each are service are clearly delineated. Keeping the applications small and focused prevents spaghetti code and makes it easy for developers to dive in and find what they are looking for without the need to wade through a lot of unrelated functionality.
  • Fast CI/CD: Modern CI/CD pipelines contain a lot of steps. Static code analysis, unit testing, integration testing, UI testing, code coverage analysis, image building/publishing… the list goes on. In a traditional monolithic application this process can become very cumbersome as an application grows. In a world where developers are expected to run an entire suite of tests regularly this can become burden. By keeping our services small we limit the number of tests and the number of files in the project and ensure that CI/CD pipelines will always be snappy.
  • An “Eat Your Own Dogfood” Approach: By forcing the services to communicate with one another via HTTP the developer(s) have to think about the services and work with them in the same way the end users will. Designing a robust, intuitive API becomes easier when you yourself are a user and can think about it in terms of what you need it to do.
  • Multiple Points of Failure: In a traditional monolithic design a single bug in a minor subsystem can bring down the entire application. Likewise, a single node failure can mean the entire application is inaccessible. By breaking the application up and deploying it across multiple nodes we get the comfort of knowing that if one service goes down the others will still be accessible. Why should a bug in the Treasure Generator service prevent users from making requests to the Dice Roller service?

The microservice approach does present a lot of technical overhead. We’re dealing with multiple applications, all with their own dependencies, databases, configurations, and DNS requirements. Thankfully the containerization strategies provided by Docker manage all this overhead for us in a nearly seamless way. Developers don’t have to worry about setting up multiple versions of frameworks or database engines. The service authors define what they need and Docker takes care of the rest. If we need to make an update we simply bring down the containers and rebuild.

Future Enhancements

  • Updates to the Treasure API to handle treasure hauls that include weapons, gem stones, tomes, and other non-currency items
  • Additional services for generating random encounters, generating monster stats, managing PC and NPC stats, and retrieving details about items, spells, & creatures
  • Authentication & authorization
  • Interactive online API documentation
  • Logging and error alerting
  • Container orchestration support (e.g. Kubernetes)

I hope this has been informative. If you have any questions or comments don’t hesitate to reach out via Twitter or email!


Legal Note: GM Tools is unofficial Fan Content permitted under the Fan Content Policy. Not approved/endorsed by Wizards. Portions of the materials used are property of Wizards of the Coast. ©Wizards of the Coast LLC.

© 2020 Seth Puckett