Before I get to the code-y parts, I want to discuss a bit about the limitations of web browsers, how React works, and what Colyseus and Nodejs bring to the table. Note that I am not a “deep diver” and will not be talking about exacts; I don’t want to create a college-level course on how web browsers work. I just want to explain how the combo of React and Colyseus addresses shortcomings of the modern web browser when designing a web-based game (even one as pedestrian as mine).
I remember the first time I learned about “HyperText Markup”. I was in college at the time, and I found myself in my dorm room reading a “magazine” (which is a ‘zine, but printed on glossy paper) interview with pre-OBE Tim Berners-Lee. Berners-Lee was explaining how the “world wide web” was going to work (yes, future tense), allowing authors to post documents that anyone could access, embedded with “hyper-links” that could take a reader to a completely different document. As I was studying biology at the time and had experience writing lab reports rife with citations and references, the idea that the humble footnote could now be embedded inside a document was something that spoke to me. As dry as the vision was, I remember that the hairs on the back of my neck stood up as I thought of the potential for what we now know as “falling down the rabbit hole” of any subject imaginable.
At college, we started out with UNIX-based terminal browsers that used the Gopher protocol, a precursor to what we know as today’s Web. With a bit of hacking through our own server accounts, we could mount a file that would give us access to the wider…world web through a graphical browser called Slipknot, and then eventually Netscape Navigator.
I mention all of this because even modern browsers can access simple, original websites like these because at their core, web browsers don’t do anything fancy. They send out requests and receive responses. Those responses are just strings, which is why you can view the source of any web page and see it pretty much exactly as it was written by the developer. The browser parses these strings and formats the content using “HyperText Markup Language” — better known as HTML.
Early browsers didn’t have a lot to work with as HTML was still in its infancy, so web pages tended to look like shit by today’s standards:
Once the web started reaching more people — and more companies jumped on the bandwagon of getting themselves out there with their own web presence — folks realized that these cheap-ass web pages wouldn’t cut it. In order to engage better, web technology needed a makeover.
Flash. Depending on your age, that either means a second-string DC hero, an early way to watch videos online that never worked correctly 100% of the time, your first introduction to web-based gaming, or you have absolutely no idea what the hell I’m talking about.
Flash was a product from a company called Macromedia that blew the doors off the Internet. Rather than leaving a website to static text, forms, images, and maybe a “chimp-attract” animated GIF (or 30), websites could incorporate complex animation, video, and live user interaction. From the back-end, it used a NLE (non-linear editor) to provide keyframed animation, and even came with it’s own programing language that allowed developers to respond to user input in real time. When I worked at a web development company in the late 90’s, we had a dedicated Flash animator who made a kick-ass application that — wait for it — allowed users to interactively build a custom shed that they could order. I know, right? In all honesty, I was jealous of those who knew how to use Flash, and I tried it myself on several occasions but could never get the hang of it.
The problem with Flash was that it required a plug-in. Plug-ins were small applications that ran within the context of the web browser, but which didn’t really interact with the browser. They’re like in-window air conditioners. Every time we encountered a site which used Flash, we might be asked to download the latest version of the plugin. If we refused then part of the site — or the whole site, because entire sites were created as a single Flash project sometimes — would be inaccessible.
To make matters worse, as time and tech moved on and Flash began to fall out of favor, it became a bonafide security risk as Adobe, who bought Macromedia, lagged behind on updating a plugin that was quickly becoming obsolete anyway. Flash continued to be supported by many browsers until somewhat recently but no one was building new content and almost everyone wanted it dead.
What Flash left us with, though, was the legacy of high-concept user experiences. Non-Flash websites were just static forms, text, and image, while Flash gave people a taste for what a full-on interactive website could be, and a direction for the future of what people expected from the web browsing experience.
Back when the Web was created by academics, primarily for academics, the need for systems which could do anything other than display text and images was not very high on anyone’s priority list. When the public Internet moved out from under the iron fists of AOL and CompuServe and into the realm of mom-and-pop internet service providers (ISPs), Big Business moved in. Advances in supporting technology brought greater security, Flash made the user experience more exciting, and companies quickly started opening online storefronts which put us on the road to the Internet we know and loathe in 2021.
As an old school Internaut I often times resent the Web being made over in mold of naked commerce, but one resource we looked towards when I worked at the web dev company was — honest to gawd — porn sites. Say what you want about adult content, but the modern web would not exist today if not for the heroic efforts put forth by smut-peddlers who went all out (literally and figuratively) to protect their content. Credit card processing, security, locking down content, you name it and it was probably spearheaded (these innuendos write themselves, folks) by porn sites.
Despite the evolution of the Internet and expansion of our experiences with the World Wide Web, the browser remains it’s same, humble self. It’s mission has never changed; make a request, receive a response, and display the result.
That more or less brings us to the problem that I’m hoping React and Colyseus will solve: how to keep the “conversation” going when using a tool that knows absolutely nothing about how to maintain a connection to a remote server in order to facilitate rapid communication that allows us to present the kind of “always on” experience a game needs to have.
I realize this post is already hella long, so I’ll try and get through the main points of React and Colyseus, but if you’ve made it this far and intend to continue, give yourself a gold star. I love you.
React is a “framework” developed by Facebook. It solves part of the problem of the stateless web by allowing parts of a web page to be “re-rendered” in response to updates of “state”. Let me unpack that quickly.
The Web is “stateless”. Once your basic web page is done loading, that’s it. It doesn’t know anything about what’s going on back at the place that served it, meaning that if an admin changed a headline in the database, fixing a typo, you won’t know it unless you refreshed the page to request a new copy from the web server.
If updates are found, then React has the ability to update your web page through “targeted re-rendering”. React is smart enough to be able to update only the parts of the page that contain content that has changed. Designed properly, that headline typo fix would only re-render the headline display, and not the body content of the article you’re reading. For developers and designers, this is a massive benefit that allows for designs that are dynamic and responsive.
The only problem with React is that there’s no way for the server to tell React that there are updates to be had. React still needs to check in with the server to make sure everything is good, or if there’s been a change. There’s another framework called Angular which does perform this “two way binding” but it’s almost too over-engineered for its own good, and we won’t ever speak of it again.
In the end (finally), the combination of React and Colyseus with Node look to be the kind of “in-my-wheelhouse” technology that I have been angling towards piecemeal with other technologies. First there was Unity, which is battle-tested and somewhat familiar (via C#) but relies heavily on game language I could never fully wrap my head around. Then there was my attempt to use other web-centric stateless communication tech like SignalR which, while effective, ended up a spaghetti mess that frustrated me the longer I tried to untangle it.
In the following posts, I’m going to explain — quicker, I hope — with examples, the initial tests I’ve come up with using React with Colyseus and Node.
Now go binge watch something I’m done for the night.