Let's Write A Video Game - Introduction

Posted on May 30, 2016 in javascript, web development, game development, development

Video games are complex whirlwinds of sound, art, music, storytelling and structure that somehow come together to create something you want to touch and interact with. Styles of games range from the high-budget AAA titles such as Overwatch to beautifully simple masterpieces such as Thomas Was Alone.

Why write a video game?

I've always been interested in writing video games. When I was little I was obsessed with drawing the scenes of video games I wanted to one day create using marker or crayon. I'd write dialogue, draw characters, enemies, HUDs, everything a proper video game needed.

After all these years, I finally feel like I have the time and energy needed to carry out a project such as this and so I want to share the journey and progress of creating a network-capable 2-player puzzle game I sketched out years ago in a notebook.

I'm not experienced in creating games; however, my goal of this series is to walk through some of the lessons and learning curves I encountered when writing a game. This series will assume some basic knowledge of coding although I'll do my best to not make this ultra technical.

So what will we be making?


I loved playing Rush Hour as a kid. The game was simple; you picked a puzzle card from the deck, assorted plastic cars and trucks on a grooved grid corresponding to that puzzle, and then attempted to slide the pieces around to get your red car out of the parking lot. The cards were ranked in levels which ranged from the easy to the seriously complex. In addition the range of skill the cards provided, there were also expansion sets which came with new plastic pieces and challenges. There are a few things I particularly liked about this game:

  • Replayability - There were hundreds of puzzles to play and the expansion packs provided fresh twists to the game that kept it interesting.
  • Low Learning Curve - The game was simple to pick up and understand but grew increasingly harder as your skills adapted to the patterns of previous puzzles.
  • Challenging - The game was quite difficult and I often remember spending a few hours on some of the puzzles.
  • Simple Game Elements - Cars and trucks are used over-and-over again in new and interesting patterns to increase difficulty and keep the game interesting.

We're going to be building a game similar to Rush Hour with a 2-player twist. The goal will still be the same, get your car to the exit - but the twist is that there are two exits and you must work with and against your opponent to each reach your goal before the other. My goal is to have the game feel like a game of chess with no turn-based actions but instead real-time fast-paced moves to overcome your opponent.

Game Design

A big part of video game design is trying to get the most bang for your buck. For example, in Super Meat Boy, the player is introduced to buzzsaws which evolve into spinning and moving buzzsaws later in the game. The buzzsaw is used in new and innovative ways to increase the challenge while not adding any additional art or conceptual work. Why is this important?

As I've already come to learn, programming video games is extremely hard. Coming from a web application development background, video game programming is in a league of its own in terms of complexity and calculations per microsecond. There are so many moving pieces and parts that make up a game, saving ourselves work anywhere seems like the appropriate thing to do. If you reflect on video games you particularly enjoy, I guarantee you'll find repeating elements everywhere that not only keep things interesting, but also save us time to develop the game.

A major example of this in action are the boxes scattered around the world of Crash Bandicoot. Boxes were easy to draw (low render time) and also could be modified to be wood, metal, extra lives, TNT, Nitro, etc. which all took on unique properties of their own. As another example, rolling boulders (not THE rolling boulder) were used as a timing obstacle in the game. The game developers could stack 2 or 3 of these rolling boulders in back of each other to further increase the difficulty.

I want to follow a lot of these principles and since we're building a game that's based on cars and trucks, simplify this down to the lowest level and say we're only going to design a block. A regular ol' rectangle. That rectangle could take on different properties however, which we'll touch on soon.

Designing Rules

We want structure to our game and know how certain things are going to behave. With no plan, there can be no code as you won't know what you're making just yet. Let's define some immediate rules that we want our game to follow.

  • Each level will be based on a grid
  • A grid can be variable length/height
  • Each block can be placed on the grid to move vertically or horizontally, but not both
  • No block should exceed 3 grid units long
  • Blocks are movable by either player
  • Blocks cannot pass through other blocks
  • Blocks cannot be placed on the same x or y axis as an exit (impossible for a player car to exit)
  • Each player will have exactly one special player car
  • Player cars can only be moved by their associated player
  • Exits will be played on the same x or y axis as the associated player car
  • First player car to reach an exit is declared the winner
  • Scoring will be based on time spent and moves used
  • Players will battle in a series of 5 increasingly difficult puzzles

These rules will be used as we implement logic into our game but might change based on the needs of the game. For example, if we say that 4-unit blocks are a good thing to do, that will be adjusted accordingly.

Designing Flow

Every video game interface can be simplified into a finite-state machine. Expressing an interface in terms of a FSM is extremely helpful as it shows exactly how a user might get from point A to point B, or in our case from "New Game" to "Winner".

Using a simple diagram interface, I've come up with the following for what Traffic's flow might look like.

There's not much to this diagram but I believe that's the point. I think this is simple enough and defines precisely how a user will use the interface. As the game is developed, this chart will be used as a reference on what a user should be doing and seeing.

Sound Design

This is an area I have zero experience in but will be investing some time into. I like games with simple pattern songs and simple interactive sounds. My plan for Traffic is to have smooth, patterned piano compositions and sounds. Taking cues from Thomas Was Alone, I'm going to record natural piano compositions with the possibility of layering on atmospheric sounds and noises. I'll be using my Alesis Coda Pro to record. I'm unsure of what program I will use to edit and master.

Game Architecture

After figuring out how our game is to be played we need to plan how it will be built. As mentioned before, video games are wildly complex pieces of software and it takes some discipline to stick to staying organized. I'm a huge believer of YAGNI and so with that, we're not going to develop anything that's crazy complex until we absolutely need it.


My background is web application development and so with that I'm most competent with languages such as JavaScript, HTML, CSS, etc. In order to learn more about game design (as opposed to learning a new language), I'm opting to write an HTML5 game using JavaScript to power the game logic and Go to power the API. The game will use WebSockets to communicate game state changes to our connected players.

A Note about Networking

Networking is hard and it becomes harder when you're trying to keep two games that are rendered separately in sync with each other. From my previous attempts at game programming, I've learned that there are two strategies to syncing game state.

The first strategy is to send updates about each blocks' position to the server during a set interval. This interval might be 10/sec. The upside to this strategy is that the games will be near pixel-perfect synced but the drawback is that this becomes extremely network intensive. A game that is dependent on the updates like this is also pre-programmed to fail during a packet loss as it will have no idea where the piece is for a split-second and then update the next loop around which will make the piece appear jagged. The other downside is since all x,y values are synced via the network all the time, animations will look less smooth.

The second strategy is to send periodic updates when certain events are fired. For example, we can send a network update that "Player 1" has pushed "Block 123" with a force of "1.5278". All this information will then be interpreted by Player 2's game which will update block physics for Player 2's game. The upside is that animations are smooth and all rendering is happening locally as opposed to relying on the server. The downside is that there is the potential for things to become out of sync if the physics calculations are off. This is the strategy we're going to use for now.


During development, levels are going to be defined as .json files. The structure of a level might look something like this.

  "name": "Passing By",
  "author": "Tom Lackemann",
  "difficulty": "easy",
  "grid": [8, 8],
  "exits": [
    { "size": [1,1], "xy": [0,4] },
    { "size": [1,1], "xy": [7,3] }
  "players": [
    { "size": [2,1], "xy": [6,4] },
    { "size": [2,1], "xy": [0,3] }
  "blocks": [
    { "size": [1,2], "xy": [2,2] },
    { "size": [1,2], "xy": [3,2] },

I like using JSON for a couple of reasons. For starters, it allows us a define a clear representation of our level that can be parsed by any programming language. If we wanted to write a level editor in the future (maybe), we can export or import any level with relative ease. JSON is also easy to read and understand. You might not know what the game looks like, but you can begin to piece together what it might look like.

Down the road it might make sense to store these levels in a database.

Wrapping Up

I've attempted to make video games before (several times in fact) but have always fell short of making progress for various reasons. I'm happy to undertake this as a serious side-project for now and can't wait to report on the learnings. In the coming series, I plan on diving into the API design, game structure, art assets, sound recording, and more. My goal is to ultimately learn from this experience but if someone else also learns something then I'll be ecstatic. Looking forward to getting started!

Cheers, Tom

Thomas Lackemann :)


Tom is the founder of Astral TableTop. He's a homebrewer, hiker, and has an about page. Follow @tlackemann on Twitter for more discussions like this.