Plot Points
--
That’s a wrap on DigitalCrafts! And with it comes my final project, Plot Points. This article describes this D&D-adjacent project and features quotes from the preface to the Player’s Handbook, written by Mike Mearls. This article makes a lot more sense if you’re already familiar with the project — you can get yourself up to speed with a quick video walkthrough or a more casual demo and Q&A.
Plot Points is a minimalistic web-based virtual tabletop (VTT). It’s the first VTT to be built mobile-first, allowing you to play your favorite tabletop roleplaying games from any device with ease and minimal setup. Without permissions separating players from a Game Master (GM), Plot Points is the perfect platform for games with high player participation or without a permanent Game Master — such as Fiasco, Wanderhome, or D&D using the optional Plot Points rule (the origin of our namesake).
The Team.
Play the game with someone enough, and the two of you are likely to end up friends.
I was the project manager for Plot Points, which means I came up with the idea for the project, managed (bossed around) the other members, and worked on any issues that affected both the front- and backend. Still, I focused mostly on the backend. My teammates were, and worked on, the following.
We made this project from scratch in two weeks.
Design and development.
You just need to aspire to create, to have the courage of someone who is willing to build something and share it with others.
Want to jump right into the code? Check out the GitHub repositories here: backend, frontend.
Our first challenge as a team was to get the basic framework for a VTT up and running. This means we needed basic backend routes to track users and everything related to their games in a database. We landed on the following design:
This simple scheme was enough to get started with; it tracked users, their rooms, and the resources and scenes within those rooms. Unlike other VTTs where resources are linked to users, we linked everything to the room as part of our permission-less philosophy. We migrated our PostgreSQL database via Sequelize and hosted it on ElephantSQL. Our backend successfully allows users, rooms, resources, and scenes to be created, read, updated, deleted, and linked (or unlinked) to one another from the frontend user interface.
For example, one of the nicest features of our backend is adding a player to another room by email, which simply creates an entry in the ‘UsersRooms’ table referencing the room and player of interest. The newly added player can then see the room and make any edits they wish to the room. Additionally, when a room is deleted, all resources, scenes, and join table entries associated with that room are properly deleted while the users who were previously in that room remain untouched.
—
Our fronted tech stack centered around React. We used Redux to track dynamic changes across multiple pages, TailwindCSS to help with styling, and Node.js and Express on the backend.
Our frontend layout consisted of five principle pages: a login and sign up page, a home page, a profile page (where users can, in addition to managing their profile, edit and see which rooms they’re in), and the room page (which holds the proverbial tabletop where gameplay happens). These pages were supported by a litany of React components — mostly conditional pop-ups.
This project is also supported by some other libraries and resources. The movement of tokens (and some nice animations) was achieved with Framer Motion. While inside a room, actions like changing the currently active scene (background image) or dropping, moving, or removing a token (what we call a resource after it’s been clicked) are tracked across multiple users with Socket.IO. We deployed both the frontend and backend of this project on Render.
Potential improvements.
The first [things] you create will probably be a collection of clichés. That’s true of everyone[...]. Accept this reality and move on to create the second[…], which will be better, and then the third, which will be better still. Repeat that over the course of time, and soon you’ll be able to create anything.
- Socket.IO was, I think, more trouble than it was worth. We should have had another database table for a room’s current state, where the current background and tokens (including their positions), are stored. This would have prevented an issue where users only see dynamic changes inside a room if they’re in the room when the change happens.
- Allowing the user to upload images, rather than input links to images, was next on our to-do list. We would have used Cloudinary for this.
- Tutorial pop-ups are a helpful part of most other VTTs, and they would have certainly been a nice feature for Plot Points, especially considering its minimalistic and low-barrier-to-entry nature.
There’s never enough time to meet all your stretch goals in a fast-paced bootcamp, and there are plenty of other small changes we would’ve implemented in a real production environment. For example, we would have liked to have token positions tracked (and updated on all screens) based on their relative position on the map instead of their absolute position on the user’s screen (the default for Framer Motion and what’s currently used in our project). We also floated the ideas of using more CSS media queries to better use screen real estate on larger devices in the room page, allowing the user to resize and name tokens, and a whole lot more.
Final thoughts.
Once you have that skill, it’s yours forever.
I mean, it’s alright.
Everything works well enough for a two-week project from scratch, especially considering that no one on our team had any formal computer science degrees or industry experience. I think it’s fair to say that we all learned a lot, and I’m confident that our team would put together something even more impressive if we had another project to complete.
I personally think I improved my leadership and management skills quite a bit (my instructor noted something along the lines of “this is the best cohort at agile/scrum development I’ve seen in a long time”). I think this was the most useful lesson in this project to me — to understand how to set realistic and productive expectations and goals for yourself and others in a team environment.
Further, this was the first time one of my projects began to use libraries and technologies which our instructors weren’t familiar with (such as Framer Motion and Socket.IO), and we really had to learn how to read documentation for ourselves, then understand those limited examples and modify them for our own purposes.
Lastly, this is the first time I’ve experienced this significant level of open-ended problem-solving in a large group project. Learning how to plan at a high conceptual level, then break those tasks down, assign them to others (in an efficient, non-micromanage-y way), and improvise or change course as needed was a very valuable skill that I’m glad I got to learn in a relatively controlled environment like a bootcamp (where my mistakes during the first week couldn’t get me fired).
—
At the end of the day, this project met my expectations in almost every way. We achieved exactly our goals that we laid out at the beginning of the project — nothing was cut and no stretch goals were implemented. Even though I think we did something fairly unique as far as bootcamp projects go, I really do mean that it’s alright. As our instructor told us many times, in so many words: “It’s not going to blow anyone away. It’s not going to be the most groundbreaking thing ever. It’s going to be the hardest and biggest project of the bootcamp, but in the grand scheme of your career, it’s going to just be a tiny project; a small slice of a fraction of what you’ve done.”
I really do hope he’s right. I hope this is the start, rather than the end, of a line of growth and development in web development and software engineering for myself, my team, and my fellow DigitalCrafts students.
That’s Plot Points.
D&D is a game that teaches you to look for the clever solution, share the sudden idea that can overcome a problem, and push yourself to imagine what could be, rather than simply accept what is.
