Over the past couple of years, there has been a surge in popularity of the Twitch streaming platform and due to this a few interesting phenomenon has happened. One of the largest and most well known ones was “Twitch Plays Pokemon”. The objective of Twitch Plays Pokemon was simple, beat one of the first Pokemon games via sending input commands through Twitch chat. It seems like a simple task, however, having thousands of people control a single character in a game turns into utter madness very quickly. It was a massive success and has even spawned it’s own category on Twitch. The most popular way to add Twitch Plays functionality to a game usually relied on a very roundabout way to grab input and manipulate the game. An external script to grab IRC input from Twitch and then send those inputs to the game. What I wanted to accomplish with this library is allow the developer to integrate the ability for their game to be played through Twitch without being too intrusive on the development of the game.
One of the first tasks that I had to implement for the library would be the ability to actually connect to Twitch Chat and read the IRC channel. Twitch chat is operated off of basic IRC principles except it uses OAuth authentication. Using a simple Unity Twitch IRC chat reader on GitHub I set up the library to open the IRC stream and read from it. The Library then will run two loops on different threads, reading input and sending pings back to Twitch’s server.The real part that allows for easy integration is the ability to bind commands to functions easily. A developer just needs to call the function that takes in a string and a raw function and will add it to a Dictionary. The thread that parses message input will now keep track of how many times that string command was said. All that needs to be done now is to ask the library for the most said command, tell the library to run that command, and then clear the previously said messages.
Things that I want to add in the future is an event system to the library. Currently, there is no way to know when you are connected/disconnected, when a message arrives or what it’s contents is, and when other seemingly nice to know things that happen. Allowing a developer to subscribe to message received events would allow for more diverse gameplay and could allow for using a different system than the default and only implemented, “Most Common is the most said” way of doing commands.
What I learned from this is how to interact with IRC Chat on a web socket, and how to think about library development from a perspective of, “The DLL is everything I can use, I can’t just go and make an edit to it.”