Game Development Reference
In-Depth Information
Once I established the technology, I set up a list of deliverables and deadlines. Planning out a timeline for
this is useful for project organization and motivation. Having certain deliverables due at a certain time not
only made me stay on schedule, but prevented me from getting sidetracked. My initial goal was to finish
the entire project in four weeks and be able to submit it to a few different game festivals. By planning out
due dates, I was able to realize these goals.
Production
The development of A to B followed a pretty standard loop, which looked like Figure 2-3.
Figure 2-3.
Stages of development of the game
While it is generally good practice to plan the entire system before one begins development, I followed a
looser approach. Since I knew the game wasn't going be a large scale software project, I knew I could get
away with a more unscripted design. Essentially, this resulted in less efficient and less modular code.
There are many people (like me), however, that believe that as long as you get the job done effectively, it
doesn't matter how you get there. As you can see in Figure 2-3, I always started by coding something.
Usually, I would break down my code sessions to set up and accomplish small achievements. For
example, one session revolved around getting a ball to adhere to “real” physics.
Instead of building the system with breadth and no depth, I approached a specific topic and went all the
way down. Although this was less modular in terms of focus and learning, it proved to be a more effective
approach. I would immerse myself in a single issue and not stop until it was resolved. This allowed me to
not have a bunch of loose ends to tie up at the end.
The next layer of production after coding, debugging, and testing, was play testing. Play testing is one of
the most helpful areas of the development process. During play testing two major things occur: bugs and
what-ifs. When coding, you often lose sight of the bigger picture. You know exactly how you want things to
function, but you don't see it from a different perspective. Having other people who aren't familiar with the
operations of the code play test for you is like stepping back from the painting. In doing so, they may
approach the same problem from a different angle. This can reveal inconsistencies or bugs in your code. It
is much like pouring water in a bucket. If there are tiny holes, it will be obvious where they are.
Additionally, and possibly more importantly, you will begin pondering the what-ifs. What-ifs are an
extension of the brainstorming phase. As you're watching the tester play, you immediately see something
that could be changed, enhanced, or removed that will make the game better. To help manifest this
