I am not a software developer, but I like to code.
tl;dr – I have a new Slack game available that you can try right now. Click here to learn more and, if you like, invite it to your workspace! The rest of this blog is all about how, and why, I built it.
(At some point, it would be cool to write up something about BBSes and how awesome they were back in the day. But I’ll have to save that for another time.)
I first wrote a very basic, web-native version of the game that lived online using Meteor. I’ve been kinda surprised how little attention Meteor seems to get, since it’s a pretty versatile and super useful framework that packages together lots of stuff you need an application like this to do (maintain user accounts, for example). But I soon realized that there was another platform even better suited to a text-based game like this: Slack.
The advantage of making this game into a Slack app was that it usefully limited a player’s interaction with the game to the text console and I didn’t need to worry too much about the UI at all. Slack provided an easier distribution path and was already beautifully rendered on mobile. On the web, a properly motivated player could also pretty easily go in and screw around with the JS vars that control the game (yes, yes, I could’ve hidden these somehow, but that would’ve been a pain). Not so, on Slack. Plus, Slack was already pretty hot, and I figured it would be a cool next step.
So I discovered Botkit by the folks at Howdy and went to work. Botkit is really an outstanding piece of work, and it’s only gotten better since then. It took me a lot of googling and reading documentation to figure out how to get it to work, but eventually, it did. I renamed the game Legend of the Plaid Dragon as an homage to its new Slack home.
Developing an extremely simple Slack app starts out pretty easy, but then making it do anything interesting gets much more complicated, very quickly. I wrestled a lot with OAuth, event subscriptions and permissions scopes, and still don’t frankly understand them nearly as well as I’d like to. Getting small details just right was a big pain the ass – setting up the MongoDB storage, for example. Scouring the Botkit/Slack developers’ hangouts was a huge help.
When I last made this game public, a bit more than two years ago, “LotPD” was pretty popular. It hit the list of the 15 fastest-growing Slack apps about a week or two in, and I suddenly had a few hundred players playing (and crashing) my game. There were bugs everywhere, and I was manually restarting the application each night for a while just to make sure it was rebooting players’ turns correctly. Eventually, I just took it offline, because I had other shit to do. (Hey, I’ve got a day job!)
This time around, I’ve cleaned things up and written/re-written a few levels. Perhaps most interestingly, I’ve been playing around with editing and hosting the game on Glitch, the new platform from Fog Creek Software. It’s both cheaper than Heroku and lets me really easily edit code in the browser and immediately compile it, which is cool. No more git push origin master – I just watch for bugs in the log and smash on sight. I’ve now done pretty much all the revamping/editing of this project on Glitch, and I love it.
Some outstanding issues:
- As I said, I still do not really understand how OAuth works, or really how Slack’s API either. I couldn’t really explain to you what a websocket is. I just know I post things to the API and stuff comes out. I feel like this really limits my effectiveness in using it.
- There’s this issue that my RPG game nerd friends have explained to me is called “game balancing.” Basically, I’ve had to make sure that all the different numerical values – player hitpoints, strength/defense, magical effects, experience points, gold prizes, and so on, and the math that determines them on each turn, are all “balanced” so that the game doesn’t go completely out of wack and result in crazy outcomes. It gets really tricky!
- To try addressing this, I built a google spreadsheet that simulates 1,000 turns for any combination of attack/defense/etc metrics I input into a formula. Then it shows the average/high/low/standard deviation of those simulations to give me a good idea of what that combination of parameters would look like in the game. With these insta-simulations, I’ve made tweaks at each level to make sure that the game gets harder as a player gets stronger.
- Getting “utility” functions right. I tried to build reusable functions at every level, just to make things faster and more efficient, but it’s been tricky to do so without losing too many fun contextual game details.
I know that there are a ton of ways that I could optimize my code for this game which I just haven’t gotten around to.
I’ve always been a believer in “shipping” my projects before they’re perfect, and Legend of the Plaid Dragon will be no different. It’s got a lot of bugs, so consider this game in beta pretty much indefinitely. But I hope you like it. Give it a whirl, and let me know what you think. Happy slashing!