A real-time game from scratch - Initial Setup [1]
October 04, 2020
Previous Entries
Introduction
So I finally got started on Cabin Fever.
Given that I have chosen to not proceed from an academic route where I learn all the theory then I proceed with the practice, the easiest way to make initial progress is to setup the repository and a Hello World for both the back-end (BE) and front-end (FE) part of the project.
I will not be detailing progress in a step-by-step reproducible fashion, instead I will gloss over details which I feel are not relevant, instead I will focus on the high level concepts. Despite this, the resultant code will be tagged with the number of the article in the title (in this case, the tag will be article-001).
The Repository
The repository is hosted on GitHub under my personal account. I chose the GPLv3 licence since, at the time of writing, the aim of the project is more education focused over commercial.
The folder structure is a very simple monorepo - cross cutting concerns (readme, licence, eventually CI and relevant config files) are stored in the root, whilst BE and FE have their own folders: cabinserver and cabinclient respectively.
The Server
Inside the cabinserver folder I placed a main.go file to allow me to simply run go run main.go.
When it comes to Go & web servers, there is not a decent built-in option to allow for hot-reload development (not in the way one can come to expect in the Frontend world). To achieve this, I use an open source tool called modd (also written in Go) which according to my provided config will watch the filesystem for changes to *.go files and rerun the provided command.
The Client
On the client-side, I chose Parcel as my bundler. I could have used alternaatives such as Webpack, Fuse, or sticking with the plain TS compiler, but I have found parcel to be one of the best bundlers which requires the least/zero config. Within two yarn add commands, I had functioning typescript compilation along with hot-reload and source-map generation.
To ensure that the above works, I simply added an index.html file which runs a TS file, which simply logs Hello, World to console. The “Hello, World” is stored in a strongly typed string, to ensure that the TS features are working as expected. I have currently even gotten away without having to define a tsconfig.json file, however in my experience at some point I will need to definitely provide it.
Linking them together
The simplest and most standard way to send data back and forth would be to use HTTP in the form of REST API using JSON for serialisation and de-serialisation. Whilst I Would definitely not build a real-time game using this option (a turn-based game would most probably work just fine), I will use it to verify that my client and server can at minimum talk to each other on my machine.
The basic setup for now is that on GET to route localhost:8080/, the server returns a string containing the current time. The client is hitting endpoint / once a second, then updating the DOM with the string returned by the server, which contains the timestamp. One can also confirm it is working by looking at the network tab and by seeing no errors in the console.
Conclusion
The next step would be to explore a more event-driven approach through the use of a technology such as Web Sockets. I have experience using SocketIO in Node to simplify development, however since I am now using a non-isomorphic JavaScript stack, it will require going back to basic WebSockets.
You can find the code for this article at the article-001 tag.
Next Entry