It has been awhile since I did game development. A few months ago, I got into playing mahjong, specifically Japanese “Riichi” mahjong. It’s different from what you might know as mahjong, which is likely mahjong solitaire. Riichi mahjong is like Chinese mahjong, except it has different and extra rules, which I think makes it more fun!
Intro aside, about a month ago I thought I should try and make a software version of the game. I didn’t realize it at first, but what I discovered is that translating a physical game to software can actually be very enjoyable. This is because of three reasons:
- The gameplay is already “done”, you just need to “translate” it. So, no thinking about what your game needs to be!
- If the physical game is popular enough, it’s likely that there is some free art out there for it. If there isn’t, you already know what the art looks like, so you can just try to copy it.
- You can heavily focus on programming because of the first two!
After looking through various game server implementations, I landed on nano, a game server framework in Golang. I have used Go some before for small projects, so it sounded fun.
nano is actually very nice to use and I quickly adapted to how it works. I also learned a ton about Go and how best to write Go programs. Go might be my favorite programming language right now!
I made the decision to write the client in JavaScript. I am not a big fan of JavaScript, but the nano project has a JavaScript library, so that made it easy to experiment. I then found a small game library called pixi.js, which I used for rendering the game.
Eventually, the game started growing and I was getting tired of all the JavaScript code. I looked into React and even three.js (a 3D game engine), tried out some stuff, couldn’t really get it working…and ended up just installing TypeScript and changing all my OOP stuff to functional definitions. This worked really well, and still seems to work well. There are some cyclic dependencies, but it’s not awful (and could probably be fixed).
The server itself doesn’t use complex algorithms, but rather array and slice manipulation to figure out winning tiles and conditions. It’s not perfect, it’s not the fastest, but it’s what I know and I did it! There are still some bugs and some hands aren’t accurately calculated. But, for the most part, you can get into a game and play with friends and have fun.
I will be updating this game, but for now I’m taking a break from it. I’m proud of the code I have written here; it feels clean and maintainable.