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
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!
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.
- Manage dependencies between code libraries to make it really easy to load and try something new (
- 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.
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 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.
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.