Several months back I updated on my progress on moving a number of my personal projects from botsin.space mastodon server to my own https://mastodon.kevinhooke.com instance.
Over the weekend I made some minor updates to reconfigure a series of AWS Lambdas that allow you to play Zork via Mastodon. It’s up again: if you @ the bot at https://mastodon.kevinhooke.com/@zorkbot with the single word ‘play’ you can start a new game. The Lambda runs every 10 minutes., so at worst case You game state should be saved and reloaded on each interaction with the bot, so you can play over a period of time.
Now my ZorkBot is working over at @zorkbot@botsin.space I’ve restructured the 3 Lambdas so it’s easier to follow what calls what.
In it’s current/initial working state, I built it with 3 AWS Lambdas:
mastodon-zorkbot
This Lambda runs every 5 minutes, checking for players messaging the bot
checks for last replied to messages so it only replies to a message once, using a DynamoDB table
if a new reply is needed, sends the game move command from the player to the next Lamdba, mastodonbot-aws-sdk2
replies to the player using the Mastodon APIs
The Lambda is deployed as: mastodonbot-zorkbot-dev-mastodon-reply
mastodonbot-aws-sdk2
This Lambda is called by mastodon-zorkbot, and provides parsing of the text responses from the frotz Custom Runtime Lambda, which is calls next
custom-lambda-zork
This is a Docker image for a Custom Lambda Runtime that invokes the frotz binary. This is the zmachine game runtime that runs the Zork game. It could be updated to run any game supported by frotz. The Custom Runtime has a shell script that pipes echo commands into frotz, captures the response and retuns to mastodonbot-aws-sdk2
The Refactoring
For first steps I’m just going to rename the folders of each of the Lamdbas and the serverless.yml service names so it’s easier to track what calls what in sequence:
