Chain Reaction is a game I recreated during my senior year of highschool. Despite its ugly appearance, it has been my hardest project yet. I worked on this game for about 11 hours a day for 5 weeks. I plan to hopefully remake the site with better UI with some help of friends and to hopefully have a simpler implementation. In this post, I’ll talk about what I discovered while building, and the reflections I had.

Go

At the time, the only programming language I knew was python. I decided to try Go for this project becuase I wanted to learn a new language, and the best way to learn a language is through usage so I decided to use Golang for my backened. (I initially heard about this simple language from this John Fish video). The simplicity of the language made it really easy to learn, and concurrent tasks were easy to implement using the go keyword.

Javascript

Javascript is necessary in almost every project involving the web. The language is pretty simple to move into like javascript given my python programming experience. Although the language will pretty run almost anything you program leading to strange errors like adding a number to a string. Debugging javascript leads to some annoying moments where I’m trying to figure out what caused a NaN to pop out of division and such. I wish I took more time to understand how to integrate javascript code into html code better since I would start writing massive html files with injected javascript code. Also, my javascript files were also coupled with my html files, meaning it was essentially one massive javascript/html file that I would have to parse through to understand a bug.

Starting the project

I began the project first by creating the completely in javascript. It would only work locally and I could only play against myself. I had a philosophy from learning go to use as little libraries as possible to code this game. Instead of utilizing a framework or library like React or Angular, I stuck with vanilla JS and its ES6 features. For rendering images onto the screen, I would utilize the new canvas html object where I could rerender hand drawn images into the screen. The math to create animations, circles, and a grid got ugly, and its a little hard to parse with all the magic numbers. I, for some reason, got stuck with how importing modules work in javascript, which would lead to a large monolithic frontend code structure. An issue of not using a framework is that one has to recreate their own minimal version to achieve the same tasks. I often used document.getElementById to grab html elements, and I globally many variables in other places. You may notice that I’m not much of a design person but I created my own css attributes to have some color on the screen, even if they were clashing with each other. All in all, this part of creating the front end and inital game took about two weeks of my time, from learning js, playing with imports, game logic, and other UI.

Migrating the project to Go

Definitelly, the hardest part was handling the backend and a multiplayer mode. At the time, I had a fully functionaning site if I wanted to play alone by myself. Now I needed a way for other people to play against each other over the internet. Before we can get into actually figuring out how to create multiplayer, I had to create an actual backend to hold the html files, and handle http requests from players (clients).

First, I would have to start actually learning go along the way to figure out how the syntax would work. I would also need to reimplement the logic of the game into the backend to make sure the server knows what is happening to prevent cheating. The first few days of this process would involve just rewriting the game logic I had in javascript into go code. At the time, I was thinking it might have been much simpler to have just learned React and keep the React, but I kept with what I had. I decided on doing server side rendering since I was more familiar with programming backends rather than a Single Page Application (SPA). An SPA will keep the same URL at all points rather than going to new url’s to see new data. Typically, this will be done with React or another modern framework. Since I was not going down that path, it would have been easiest to render everything on the server side. There were two main url routes the site would have. One is for the home screen that a person sees when they first enter the site. The second is the game screen. The game screen url was generated with a unique key generated and stored in memory. An example url would be https://chainreaction-9x6j.onrender.com/game/RgkrgpA1. The last part of the url, RgkrgpA1, would be the unique game room id to prevent any clashing with joining a room. There could be as many game rooms as the host of the site could handle theoretically.

The second thing to think about was how to send data to and from the frontend (javascript) to the backend (go). The most standard way is through json files. JSOn is simply just a struct in Go and an object in Javascript so they both languages know how to deal with them. So if a person wants to join a room, the person would type a name and the room pin, and send that information through JSON to the backend. The backend would parse the data and sen the person to the proper room if it exists. Note, handling json in go is quite a pain. The structs have to be strictly laid out, and if there are any slight difference in fields from one JSON to another JSON, I would have to create two different structs to handle those two JSONs being received. Note in python or javascript, I can index the fields however I like like a dictionary since these languages are dynamically typed.