Game Development Reference
In-Depth Information
At its core, A to B is influenced by the Atari classics that I mentioned earlier. At the start, I recognized that
since I am new to gaming, I needed to keep it simple.
Asteroids
was in black and white and the player
controlled a triangle, yet somehow it was one of the most compelling games I ever played. I decided that
in order to enter into the world of gaming, I needed to understand fundamentally why games are fun.
Without going into the detail, I will strongly recommend reading a copy of Ralph Koster's
A Theory of Fun
for Game Design
(Paraglyph Press, 2004). This text was an extremely insightful look into what makes
games fun. Inspired by his discussion and my appreciation of some of the originals, I set out with a strong
vision for A to B.
Brainstorming phase
All the details and many alterations of A to B were conceived during brainstorming sessions. I find that a
very informal and unplanned brainstorming process works best. This produces the most natural flow of
ideas and information. For me, this amounted to a pretty simple loop. One day when thinking about the
game (usually on the train to school or while exercising), I would have an idea for how something should
function. I would then sketch out my vision and present it to a friend. The process of clearly explaining my
idea was not only good for the friend to see what I was seeing, but it also provided an indirect way to
stumble upon more issues and possibilities. In particular, I found that almost all the good “what-ifs” came
from conversations with my friends. Having active conversations was the best way to get the creative
juices flowing and to consider other viewpoints, eventually resulting in the best possible implementation.
Pre-production
Once the idea was officially cemented, it was time to plan out the development. The first thing I determined
was the technology. Having decided the game was going to be exclusively HTML5, I knew I was going to
be using the newly-implemented canvas and audio tags. I also realized that I wanted a high-score table,
both for the retro-arcade feel and as a secondary motivational factor in the game itself.
In order to make the high-score table, I needed to utilize an online database, so I went with MySQL and
PHP to make that happen. In terms of the actual scripting for the game, I decided to use the Processing.js
(PJS) library. PJS is a JavaScript port of Processing, a popular creative coding language geared towards
artists and beginner programmers. It has become a cornerstone in the programming world because it is
both accessible for new users and powerful to handle advanced ideas and implementation. PJS allows the
developer to write in the original Processing syntax, which is then automatically converted to the canvas
element. This was a major factor in the timeline for the A to B project because I am an avid Processing
user. PJS enabled me to handle the bulk of the coding and debugging within the familiar Processing
environment before making it internet-ready.
This brings me to another lesson that I learned; which is as long as the job gets finished, who cares what
you used to do it? People are often too concerned with keeping up with the latest and greatest technology.
If the end product is what matters, then it shouldn't matter how you get there, as long as you do.
In addition to learning a bit of PHP and MySQL, I had to touch up on my jQuery skills. jQuery proved to be
very helpful with the high-score table. Since JavaScript is a client-side language, I needed a way to read
and write to my database from the JavaScript, which is where jQuery came in handy.
