5 things I've learned from making a game

For a little bit more than a year now I've been working on and off on a simple, multiplayer, browser-based game called Archers!. I've deliberately set it out to make a simple multiplayer game as I was afraid anything more complex would be a timesink that I would eventually abandon. I've managed to meet the initial requirements and then even added few features but unfortunately the game I've made is, quite frankly, dull and boring.

Now that the core-mechanics is done, the game is just about playable and I’ve got some feedback based on running few multiplayer sessions. I've made a decision to open-source the project hoping that either game as a whole or at least some components of it will be of use to someone. It has never been a goal to release it as commercial product but I hoped I would be able to put more effort into polishing the game. However the 80/20 rule (see below) got me and I've decided to leave the game as is and chase other game-making opportunities. That being said, the time I've spent making this game is far from being wasted! In this post I'm going to share lessons learned from making "Archers!".

Games won't be written in raw JS

Sadly, that's the case. True enough there are plenty of good JavaScript frameworks and libraries for making games out there and you can surely make a good game with them. Problem is it's time-consuming: usually framework won't provide everything you need so you will end up spending loads of time researching engines and libraries or writing things from scratch. Next, you need discipline maintaining your code and assets, especially if you're working on the project with someone else. You'll also need a good build process and check compatibility against various browsers, oh and you might want to code for mobiles too! Now compare that with something like Unity where most of the problems are already sorted. You can then build the project for web using a special asm.js generator which coming to Unity soon.

Considering efficiency, performance gains and the extra perk of being able to target other platforms/devices it's a much more feasible way forward for building web games. Have your game built and tested on desktop then release for web using asm-js compiler.

Making games is hard

Making a non-trivial game is a time-consuming task, this might be obvious but making a game single-handed or in a very small team is an enormous task. I've a great deal of respect for lone developers who dedicate all their time and continue working on the same title for years. It's worth reading their devlogs to understand how much effort and time they had to pour into their successful games, here are some of my favourites:

Triple A titles are made by thousands of people for a reason: you need an enormous amount of skill and effort to release a game. Make models and animations, textures, code game engine (or buy one), record sounds, music, voice overs, design levels & story. Market your game, build a fanbase, support the game etc. Indie developers usually can't compete in most of these areas, their strengths are originality, story and uniqueness - not that these are easy to come with.

Making multiplayer games is even harder

Working on a multiplayer game adds an entire layer of complexity. You'll most likely end up writing two separate applications, server where all the game logic lives and client that provides input from the player and renders game state based on information received from the server. You'll also need to implement or adapt a protocol for communication between these two (I've designed a very simple schema-based binary protocol). On top of that you'll need a strategy for poor quality connections (interpolation, prediction etc.), dropped connections (can player reconnect to the game?). Moreover if your game is web-based, your options are limited to whatever networking browser can offer which as of today means Websockets. Websocekts are cool but have one major disadvantage when used for game networking: Websockets are built on top of TCP and you usually want UDP networking for your game.

There are other challenges related to multi-player networking: You can never really trust the client (cheaters gonna cheat), you need to pay for the servers for your players to play on, you need multiple testers to test the game at once, you need to keep your clients in sync whenever an update is coming out, debugging multiplayer game is harder due to the fact there are multiple components etc. Quite often on various gamedev community channels you'll see posts saying "I'm going to make an MMORPG, who's with me?" - most of the folks behind them have no idea of many levels of complexities is involved in making a game of that caliber.

Getting last 20% done takes 80% effort

When you got the core mechanics and show the game to someone outside of the development team (or in this case, just someone else), you feel like you're almost there, like 80% of the work is done. This couldn't be more misleading. Making the last enhancements, balancing things out, fixing bugs, implementing little things that you've previously forgot, cross device/browser testing, fixing more bugs, and even after that you're still not done! You need to go through some alpha/beta plays with real gamers to get feedback, and fix more bugs. You need to build a hype around your game and distribute it and then fix even more bugs. Afterwards you feel like the last few steps took the most effort. You had the game ready, mechanics, visuals and gameplay didn't change much yet the time spent on this last "20%" feels like the 80% of the effort. This is (roughly, I'm stretching it a little) what the Pareto principle is about and it can and often will apply to any other (i.e. not game-related) software engineering projects.

Making games is fun!

Making games is very different from playing them, it's hard work, it requires wide/multiple skillsets, it's very time-consuming and sometimes it might feel unrewarding for long periods of time. However it's a unique, wonderful feeling when things start to take shape and your game idea slowly becomes reality. I enjoy making things and it gets even more fun when you're making a game that you would actually want to play yourself. So if you have an idea for such a game and you enjoy making things, today is as good as any to start working on that prototype!

I've setup couple of servers hosting Archers! so you can see the game for yourself and for more development background see my devlog for Archers!. If you have any game-development tips to share please feel free to comment below or email me.