- Play in your browser. Works on touch devices too.
Near the end of 2018 I saw a meme based on a large bunny called “Big Chungus”. Some of the content created depicted Big Chungus starring in various video games. I found it pretty funny, and thought it would be nice if there were actual video games about Big Chungus. What if I made one? Already, ideas about game mechanics were forming in my mind. It would be good practice too.
I thought of a bunch of goals and requirements. I wanted the game to be playable in a web browser because nearly everyone has one these days. I wanted it to work on GitHub Pages because free hosting. I wanted to develop the game at a higher level of abstraction than canvas maze (which was written in plain JavaScript with no libraries). And I wanted to implement the various game mechanics I had in mind. Later, after noting that I mostly showed the game to people on mobile, I added the goal of making it support touchscreen devices.
To get that higher level of abstraction, I looked for libraries that could help. I found PixiJS, a 2D rendering library, which I tried out by following a community tutorial linked on their website. I decided that this library had suitable features and abstraction, but I had a few issues with the tutorial.
Issues
- All the code was in one big
jsfile - Lack of type safety
- Minor: inconsistencies in code style (of the tutorial’s code)
- Minor: not minified
At work I was using Webpack, TypeScript and TSLint. If I could use those here, then the problems would be solved. It took a while to set up the config files, but I did it. Then I implemented the tutorial project again using this setup. Now the code was more modular and encapsulated.
I implemented the Big Chungus game in a fairly object-oriented way, with inheritance, interfaces, etc. It reminded me of a subject I did at university called Object Oriented Software Development, where one of the projects was to build a video game in Java.
Along the way, there were challenges such as getting things to work and conveying the controls to users.
There was a lot of state in the game (but at least a lot of it was encapsulated in the modules/classes as local variables). It got particularly hairy in situations where I had events/animations happening over time and one after another (or asynchronously). I used some timer variables in those situations. This stateful imperative programming contrasted with work, where we develop in a more functional and reactive way (using MobX). Later I had the idea of making an event module — something that could allow events to be defined with method chaining. I didn’t build it yet, but it’s a possible extension.
Another challenge was getting users to understand how to play the game properly. Because I implemented everything, I knew exactly how the controls worked, but other people did not. I added a demo on the title screen to show the controls, which helped a little. (This was one of the areas with lots of sequential events.) Additionally, some people had trouble with the twin-stick shooter controls on mobile. But maybe that was due to unfamiliarity with gaming. Next time I’ll try making a game with simpler controls.
Perhaps I could have avoided some issues if I had used a library/framework designed for game development (like Phaser). PixiJS is a graphics library not specifically for games, so I kind of had to build my own game engine. But it was a good challenge. I could always try something different next time.
Overall, I think using TypeScript was a good choice. I will likely use it again next time I make a game for the browser. And it was good to work at that higher level of abstraction.