KTANE Solver - 4006CEM Project
Coming up with an Idea
For our chatbot, we started with a few ideas. It had to be something plausible, that we could code in the limited weeks we had. With a general, all-in-one chatbot like Alexa off the table, we then had to look into projects that did something specific but also something someone might use. After a discussion with the team, we came up with two ideas: A Casino Chatbot - A chatbot that let you play casino games against the bot A solver for the game Keep Talking and Nobody Explodes - A bot that would help solve puzzles to help defuse a virtual bomb. Eventually, after thinking about both complexity and viability of each program, we settled for the solver for Keep Talking and Nobody Explodes (referred to as KTANE from now on).
The Premise of the Chatbot
KTANE is a multiplayer game where one person can see a virtual bomb, consisting of puzzles which must be solved. Another person has a manual, which they must use to solve the puzzles and defuse the bomb. However, the person with the manual can't see the bomb and vice versa, so the success of the team relies on the communication and teamwork of both members.
Our idea was to replace this second person with our chatbot, so instead of asking a friend in solving a module, you tell the chatbot what you can see and it tells you how to solve the bomb.
Each bomb consists of a random selection of a set number of "modules". These modules consist of puzzles, each of which is different every time, but always stays in the same format to its module. Therefore, while a player may memorise the modules, they won't be able to memorise all the data for each module needed to solve every bomb in the game.
A Technical Overview
The way we decided to do this was with a cloud-based server, namely Heroku. This is a combination of a Git system and a hosting server. With this, we can write code, push it to the Git and have our code running instantly on the server.
This server works in parallel with Dialogflow, Google's solution for making Google Assistant chatbots. While Dialogflow can work to a basic level independently, we set up a webhook server that would be queried every time the user spoke to out bot, to enable more complex processing of user inputs.
For each module in the game, we first programmed their solutions as independent code. These were then imported into the main program, that would handle both the chatbot requests and the processing of the module solutions.
An In-Depth Look - The Webhook Server
For the webhook server, I built a micro web server using Flask that would receive JSON inputs from Dialogflow with whatever the user said, along with some useful metadata. The Flask server would then pass this to another program, which processed the data and sent it to the correct module to calculate the solution.
Once a solution had been calculated, that data would be passed back to the Flask server, which would then reformat the data into a response and send it back to Dialogflow. From there, the response would be read out to the user by Google Assistant.
The upside of using this method, instead of mapping every possible input for every module to an "intent", as Dialogflow is designed for, I could just take all of the data into the Python server. This gave me full control over all the data and meant I didn't have to rely on universal Dialogflow features that were not fit for our use.
However, this also came with a downside. For some of the modules, multiple steps are needed to solve them. This, therefore, would require a back-and-forth type of conversation between the bot. Usually, this is done in Dialogflow but by trying to keep as much of our project in Python as possible, we made these features unusable. If known from the start, a state system that tracked the expected context of the next user input would have been a workaround for this.
Additionally to the webhook side of the Flask server, I also added a webpage response-ability, so that if a user visited the URL of the bot, they would be sent to a website with a guide on how to use the bot
An In-Depth Look - The Modules
As a reminder, each module can be considered as a puzzle, with each module being solved in a drastically different way to the next. While I coded the webhook server singlehandedly, we all took a few of the modules to code. A few modules I coded include adapting a pathfinding algorithm for the 'Maze' module and a Morse code translator. I was also tasked with converting and implementing their code into the webhook server, as I had learnt how best to approach this through my work coding it.
Some of the puzzles in the game require some metadata about the bomb to solve them. Due to how the webhook is called upon, these values would not be able to hold in variables while they are used. Therefore, I coded an efficient database that stored their session ID - as decided by Dialogflow - as well as the details of the bomb for later use.
The Final Outcome
Our final product was if anything a good start on the way to completion. The majority of the modules are coded, implemented and work with Google Assistant. The manual scanning was working with one module and a plan was devised to circumvent the issue without context inputs. After the deadline for this project, I plan to continue to work on this to get all aspects of it working.