This last summer, I spent my free time learning how to use Node.js for a variety of small projects with friends: A Node.js website on Heroku, a javascript Twitch bot, and a combination Twitch streamer overlay and webpage in Unity3D.

The Heroku website was a utility for Twitch users to find games based on a streamer to viewer ratio so streamers could find games that they could stream to possibly get more viewers. It was an idea by a friend of mine (the same one I made Hecklebot for). It was also my introduction to Heroku as a platform, since we needed to find a way to host it. In my experience, it was a really strong tool for development. It allowed seamless git integration, free hosting for a max 18 hours a day, and quick-setup for a lot of 3rd-party tools like MongoDB. The website itself started strong, I managed to get a lot of the core functionality done using Twitch’s API. I designed the core in an API sort of structure itself for a couple of reasons. First of all, I didn’t know how the website itself should access the data. I was thinking of having the webpages that need info grabbing data from the server after loading rather than having the server contruct webpages for each request. That way the page could refresh its data without being refreshed. Secondly, I sort of wanted it to be open if for whatever reason I or anyone else wanted to access the sorted data remotely. I doubted it would ever get that big, but it was a fun structure to design. However, as the summer progressed, my friend had less and less time to spend on it between his job, so without him the project faded. I couldn’t pick up the slack because he had all the ideas and the strength in designing actual webpages. Plus, it wasn’t as fun without a partner.

The twitch bot was a remake of Hecklebot written in javascript for two purposes for a different friend of mine who decided to try to become a streamer. 1) I was fed up with python’s whitespace sensitivity 2) I wanted to run it on a Heroku server I enjoyed writing hecklebot, but some of the original appeal to writing it was learning both python and the Twitch API. As I got more and more annoyed with python, that appeal drained away until another friend of mine wanted a Twitch bot. He actually asked if I could just route hecklebot to help on his stream, and for a while that’s what he got, but as he began wanting more things from heckebot and I came up with more ideas, I decided to rewrite it in Node, which I was excited to learn. Node.js really appealed to me because it was simple tool with a language that I already knew and understood pretty well wich allowed me to prototype quickly. Node just basically opened up the door of using javascript as a standalone, full-body application rather than having to setup a whole webpage with file hosting to use it. However, Python wouldn’t have been so difficult to work with if I wasn’t on a windows computer, but Node didn’t have that problem. Setup was a breeze and there were already a ton of APIs to start from. The rewrite instantly felt more organized than its Python counterpart. By the end of the summer, I had learned a lot about Node and javascript in general, I knew I had a lot to learn still because javascript has a ton of neat tricks beneath its surface, but I could call myself proficient.

Lastly, something I tinkered with while my friend was streaming was an interactive Twitch overlay in Unity3D. Using a technique I learned from PsydraGames and Bendry?, I could make what almost amounted to a game as an overlay for his stream. It was as simple as setting the Unity application’s background to green and setting up chroma keying in the screencasting software, in our case OBS. My friend had this idea of turning his stream’s chat into a sort of game, where there would be characters on-screen represented by the current viewers, and the viewers could take actions via chat commands. Occasionally, events would occur, like a monster showing up in the overlay and viewers could attack it to gain some currency, then use it to buy weapons or enter raffles. We had a boatload of ideas, but not a lot of time, since the idea was conceived close to the end of the summer. My goal was to get it both reading chat and communicating with ROWBot (his version of Hecklebot) behind the scenes to sync up user and currency information, since ROWBot would still handle the raffles. The chat was accomplished using some code that PsydraGames wrote and linked me to, while the communication was handled simply by putting all user info on a Mongo database. One of the coolest features, however, was that I wanted to setup an external controller for the overlay that would be in the form of a webpage. This webpage would be hosted by the overlay process itself which would be running a websocket server listening on the localhost:80 and would serve up a pre-made HTML file inlaid with javascript interactivity which would send messages to that same websocket server to control the overlay. I did this because I couldn’t put buttons on the overlay itself, all screen-space had to be dedicated to the overlay because anything there would be seen by viewers. I had heard about a cool debugging tool a company had designed for one of their applications which was a small webserver running within debug builds of their application which the programmer could connect to and view any output or relevant data. I thought it would be a cool tool for this project since it would basically allow for two screens on this Unity application. The biggest trouble I had with it though, was writing a websocket server. Through my research, I found many websocket tools for Unity3D, but none that actually hosted a websocket server as far as I could tell. This meant I had to do a lot of learning about websockets to write my own. In the end I was successful, but I have to say that websocket security is weird. So much effort is put into preventing eavesdroppers, and before looking into it I believed the designers behind websockets had security down, but it seemed to me that anyone listening on the data had just as much access to it as the person its intended for, since the encryption keys have to be sent the same way. However, it wasn’t like I had any ideas to improve it (nor did I need to, since it would all be local anyway), but it was an interesting thing to think about. Much like the Heroku website, all the functionality got implemented, but when it came to designing the actual aesthetic and graphics of the overlay, the project slowed dramatically. UI design in general has plagued me in many projects, and this one was no different seeing how neither my friend nor I had any skill in such designs. The prototype was still an interesting thing to work on though, and my biggest takeaway from it is the websocket server, since now I can use it as an external debugging tool in the future should I need it. The project in its unfinished state is available to browse through here,