One of the six goals I established in my next ten years is making my own game. I’ve made games before as part of a team, but never one “just for me”. This is the first in a series of detailed articles detailing the development of Project 1401. It’s a fairly technical overview, but I welcome questions from anyone who might have a question about what I’m doing and why; one of my subgoal is to make the approach to this project accessible to anyone who is interested in writing a web app or architecting a simple video game.

Project 1401 Background

Project 1401 is my HTML5/Javascript game project. It’s called 1401 because in 2014, I decided that finally making some kind of game for myself (as opposed for someone else) would be the first of six long-term creative goals. There are six such goals in total, named 1402, 1403, and so forth.

Getting started with game development is daunting, even though I have a background in assembly language programming and studied digital computer design in school so I could be a professional game developer. I also studied computer graphics and graphic arts, getting an MFA in the process before working for a few years in game development in the mid-90s primarily as a designer and manager. However, I have never really gotten into the programming side of things, finding the activity tedious despite an avid interest in game mechanics and system design. And, I’ve also been away from full-time professional game dev for 20 years. I’ve been feeling a bit antsy about that these days. I’m getting OLD!

It occurred to me recently that I’ve been forced to do enough programming with enough platforms that I might as well embrace programming and jump in, even if I don’t know EXACTLY what I’m doing. It so happens that I’m working on a work project that has given me the chance to look closely at current web-based technologies, and I’m astounded at how good it’s getting. The idea of creating my own game systems is also exciting because I can make this an explore-learn-build-share opportunity. During my review of material for the work project, I didn’t find a lot of intermediate tutorials on how to design and architect a game engine from raw bits of digital fluff, so I think this might be fun to document I’m not promising a GREAT game engine, but at the end of this project I’m hoping I will have created something that’s capable of EXPRESSING game ideas in carefully-defined code concepts. It might help someone, someday!

Choosing an Approach

Anyway, one of the first hurdles is to just establish some parameters for the technology. These are the criteria that matters to me:

• It’s got to be powerful, robust, and easy to use!
• It’s got to deploy everywhere so people can try it out!
• It’s got to support good development practices for medium-sized projects!
• It’s got to be “vanilla” and non-proprietary. No licensed commercial libraries! No special authoring software!

For the first two criteria, I’m picking HTML5 + Javascript (ECMA 5). If you’d asked me even two years ago, I never would have thought that this would be a viable platform, but today it totally is because HTML5 provides built-in advanced media types like accelerated 3D graphics, and there are some really great Javascript libraries available for it. Of course, the Internet makes it possible to deliver games instantly to everyone.

For the third criteria, it gets a bit trickier., because writing web applications with Javascript sucks compared with other languages. My favorite environment so far has been C# and XNA running under Visual Studio. The idea of going back to a crappy text editor loading .js files with script tag is like the DARK AGES, and Javascript as a language is comparable to Flash Actionscript 1.0 back in 2001. It’s AWFUL.

My main issue with Javascript is its lack of type checking, its lack of data protection in class design, and very broken variable scoping…it’s really kind of a terrible language. However, I’ve learned to get over it thanks to Douglas Crockford’s book Javascript: The Good Parts and David Bashford’s DurandalJS web application framework, which I liked better than popular choices like EmberJS and AngularJS. While Durandal isn’t as well known, it’s clearly made by someone who value conceptual clarity and readable documentation, and it’s designed from the ground-up to work with modular Javascript unlike other frameworks. That makes all the difference. While there are many more tutorials and examples for using Angular and Ember than for Durandal, they’re mostly of the “follow these steps and make your first web app” variety, with no real explanation of the architectural concepts. In fact, most tutorials on the web are like this, parroting the same example template in endless empty variation. I get that programmers smarter than I find this works for them, as they just need to get a running start on some working code to start tinkering, but I hate following recipes blindly. The nice thing about Durandal is that I could figure out what it was trying to do based on certain principles it establishes up front.

For the fourth criteria, I’m deliberately avoiding the use of proprietary extensions because I want this project to help me develop universal, general purpose skills. So that’s why I’m specifying Javascript as the language, not Typescript, despite my desire for more robust compilation and type checking. I’m not using a game authoring system like Unity, which can create web apps, because that means I’m learning how to use a software system rather than write my own software from scratch. However, I’m not crazy and will leverage open source libraries for graphics (ThreeJS, for example), sound (HowlerJS looks good), physics (MatterJS is my current pick), jQuery, KnockoutJS, and whatever else. It is the availability of these packages, in fact, that makes Javascript really exciting today, and this web-based game project feasible.

Development Environment Choices

With the platform, language, and supporting framework and libraries chosen, I still need some way of managing all the source code in such a way that it’s automatically compiled into a deployable executable. In the case of a web application, that means copying all the files from your source directory to your public directory, making the necessary transformations to convert templates into html while checking for errors.

The current hotness for web application development is to use the NodeJS Javascript-based web server to run a host of cool command-line tools. Conceptually, the great thing about NodeJs is that you can write your server code in the same language as your client code. Pragmatically, NodeJS is great because this power has been used to create tools that:

• Manage dependencies between code libraries to make it really easy to load and try something new (npm for server Javascript, bower for browser Javascript).
• Check Javascript source code for errors before it runs (jslint and jshint).
• Minify and combine multiple Javascript and CSS source files for faster loading.
• Enable use of templating languages that simplify web page creation.
• Enabling convenient “compile and reload” in the browser window everytime you update a file.
• Automating workflow, testing, packaging, and deployment with a single command.

There are a few all-in-one solutions available such as Yeoman, but I’ve gone with a build tool called Mimosa because it’s also from David Bashford (the Durandal guy). I like the way he thinks, and the documentation is more detailed.

Development Software

Other than the build tool, the following are essential:

• For running the build tool and running other commands: a multi-window terminal app. I’m using iTerm.
• For editing and managing source code: a multi-window text editor with syntax highlighting and project folder management. Sublime Text 3 is my current choice.
• For managing source code changes and versions: the Git source control package. This is also required by the build tool package managers.
• To run my game web app: a modern web browser with a good Javascript debugger. I’m using Chrome, which has comprehensive debug, profiling, and inspection tools. It also has a very fast Javascript engine.
• To collaborate: a central Git repository to store source files for community sharing. I tend to prefer Bitbucket for its private repos, but I have deployed Project 1401 to GitHub since this is a public project.

Development Machine

I recently converted to Mac OS X, after many years of resisting it, and have discovered that the underlying Unix + GUI is incredibly productive with modern web development tools. There are three big reasons why this is:

• Your web server (the delivery platform) runs on the same machine/organization as your development tools, which makes iteration much faster.
• The development command line tools are exactly the same, and operate predictably.
• I have all my digital media production tools, such as Adobe Creative Cloud, available on the same machine.

The alternative is to use Windows for digital media and authoring, and either VirtualBox running Linux under Windows with bridged networking OR using an external development webserver with SFTP. Even then, the Windows command line tools are going to be completely different or half-broken ports of the standard Unix/Linux tools.