Day 1: Why this game will be a web app

Saman Bemel Benrud • Jan 03 2019

Today is day one of a two month sabbatical. I intend to use the time to work on a videogame, and I’ll document my progress here.

I built this blog in a couple hours this morning with Jekyll. The rest of was already a Jekyll site so it was pretty easy to set up.

Before deciding to implement the blog in Jekyll, I looked into newer static site generators. Lots of folks have been moving to Gatsby, I like that it’s React-based, and so I started porting my site from Jekyll to Gatsby. After about a half hour of moving things over, I got up to get a cup of coffee, sat back down at my desk, tossed out my uncommitted changes and switched back to the master branch and decided to stick with Jekyll.

Why? Because Jekyll solves my problem. I am able to write a markdown post, publish it to the web, and have total design control. I don’t need anything else.

I first dipped my toes into game development two years ago by sketching a little game board with React. Since the first sketch, I’ve pieced together a prototype that includes monster encounters, victory and loss conditions, and multiple game boards. Here’s a gif:

prototype gif

Everything in the gif was designed in the browser, before I had even started the game design sketchbook. I’m comfortable working with web technologies, since it’s what I do professionally, so it was a natural place to start exploring game development.

How does the game work? I’m rendering the isometric game board via a flexbox container and a few CSS transforms. I’m using Redux actions to move the character around, and I add a variable delay to action creators via redux-thunk that makes animation possible. The animations are all CSS, and are enabled by toggling classes on divs. It’s divs all the way down:

it's just divs

With two months to focus on game development, it’s hard not to re-consider the tools I’m using for developing my game. The above prototype works, but it doesn’t follow conventional wisdom about how to build a game. Should I invest the time in learning Unity properly? Should I at least use canvas? These are the tools most indie game developers use, and they would open up new possibilities for me.

After my experience this morning with Jekyll and Gatsby though, I’m ready to commit to web technologies. The most important question is: can I solve my problems with the tools I’m using? I’m sure of it. Switching to Unity now would be no different from porting my blog from Jekyll to Gatsby.

I need to embrace constraints: no 3D graphics, no physics, no traditional game loop, and no worrying about distribution (at least until I have something actually worth playing).

These constraints will let me build the game as a React & Redux app, just like that first game board sketch. Because I know the tools well, I’ll be able to focus on fundamentals like gameplay, art, and narrative.

I have a ton of work planned for the next two months. I need to take a proof of concept and turn it into a compelling game. I plan to stick with the DOM, but we’ll see if I need new patterns beyond React and Redux as I add animation, narrative depth, and complex mechanics. I’m excited to see what happens.