Creating lilt — Part 4

As you may have seen in the addendum to Part 3, I had quite the wrench thrown into this project. One of the main tools I had become heavily invested in, Parse, announced that they’d be shutting down in early 2017. Luckily, this is a side project that hadn’t been launched yet, so I can’t complain too much — my sympathies to those who had far more riding on the service.

Robot M. Knepprath

Serendipitously, I was inspired to build a simple ebooks Twitterbot around that time: @robot_mk. This ended up being the springboard that launched me into building out the actual functioning game, instead of the prototype I had been working on previously. This bot was written in Python, deployed through Heroku, and utilizes python-twitter to work with Twitter’s API. I made some minor modifications to this bot to get a handle on how it was structured, then attempted to clone it and frankenstein the functionality I needed into it. This ended up being a bad idea — I would have needed to rip out all of the old logic anyway, so I decided to start fresh.

liltbot

The new lilt Twitterbot is written in Python (requiring me to rewrite all of what I’d written in JavaScript for the prototype), and deployed through Heroku like my ebooks bot. Instead of python-twitter, I’m using Tweepy to communicate with Twitter’s API. I was having a hard time figuring out how to get Twitter mentions with python-twitter, which was the main functionality I’d need for lilt. Tweepy has made that a very simple process.

What About Parse?

Since I was rewriting my game anyway (JS to Python), I’ve been working on building in some required features (ability to support more than one player at a time), and wish list features (a better item management system). I first had to select a replacement for Parse, so I chose one that was already well integrated into Heroku: Postgresql. It’s not as pretty or easy to work with (considering you work with it pretty much entirely through the command line), but it hasn’t been all that bad, either.

So far, I have three tables: Users, Items, and Moves. Moves serves the exact same purpose as the Moves table in Parse described in Part 3, so I won’t cover that again — but I’ll give an overview of the other two:

  1. Users: When someone tweets at lilt, liltbot will get that tweet and grab their username, id, the id of that tweet, the tweet text, and initiate the position and inventory for that person. I can take a deep dive later into how the inventory is currently working, but it’s basically a string of json that stores dynamic item traits, like quantity.
  2. Items: This table contains all static item traits, like limits for how many one can carry, or how much a particular item would heal you, and so on.
Postgresql table displaying users

Gameplay Example

So what’s possible so far? Here’s an example of an interaction I’ve had with liltbot after I’d already picked up a few items:

Me: @familiarlilt inventory

liltbot: @mknepprath apple •••, rock, banana •••

M: @familiarlilt pick up BANANA…… (sidenote: liltbot cleans up the tweet so it’s more readable, so this one would be read as ‘pick up banana’)

L: @mknepprath You acquired a banana.

M: @familiarlilt INVENTORY!!!!!!

L: @mknepprath banana ••••, apple •••, rock

M: @familiarlilt look around

L: @mknepprath It’s pretty neat in here.

Very excited about how far along this has come in the last couple months. I’m hoping to launch a playable version of lilt relatively soon — can’t wait for all of you to jump in and play.

If you have any questions or suggestions, tweet at me!