Programming - Building JavaScript Games for Phones, Tablets, and Desktop - page 9

Small Scale: Edit-Interpret-Run
When you want to build a game in JavaScript, you need to write a program that contains many lines
of instructions. With a text editor, you can edit the script(s) you're working on. Once you're done
writing down these instructions, you start the browser (preferably a recent version of a commonly
used browser program) and try to run the program. When all is well, the browser interprets the script
and executes it.
However, most of the time, things aren't that easy. For one thing, the source code you give to the
browser/interpreter should contain valid JavaScript code, because you can't expect the browser
to execute a script containing random blabbering. The browser checks whether the source code
adheres to the language specifications of the JavaScript language. If not, it produces an error, and
the script stops. Of course, programmers make an effort to write correct JavaScript programs, but
it's easy to make a typo, and the rules for writing correct programs are very strict. So, you'll most
certainly encounter errors during the interpretation phase.
After a few iterations during which you resolve minor errors, the browser interprets the entire script
without encountering any problems. As the next step, the browser executes or runs the script. In
many cases, you then discover that the script doesn't exactly do what you want it to do. Of course,
you made an effort to correctly express what you wanted the script to do, but conceptual mistakes
are easy to make.
So you go back to the editor, and you change the script. Then you open the browser again and try to
interpret/run the script and hope you didn't make new typing mistakes. You may find that the earlier
problem is solved, only to realize that although the script is doing something different, it still doesn't
do exactly what you want. And it's back to the editor again. Welcome to life as a programmer!
Large Scale: Design-Specify-Implement
As soon as your game becomes more complicated, it's no longer a good idea to just start typing
away until you're done. Before you start implementing (writing and testing the game), there are two
other phases.
First, you have to design the game. What type of game are you building? Who is the intended
audience of your game? Is it a 2D game or a 3D game? What kind of gameplay would you like
to model? What kinds of characters are in the game, and what are their capabilities? Especially
when you're developing a game together with other people, you have to write some kind of design
document that contains all this information, so that everybody agrees on what game they're
developing! Even when you're developing a game on your own, it's a good idea to write down
the design of the game. The design phase is actually one of the most difficult tasks of game
development.
Once it's clear what the game should do, the next step is to provide a global structure for the
program. This is called the specification phase. Do you remember that the object-oriented
programming paradigm organizes instructions in methods, and methods in classes? In the
specification phase, you make an overview of the classes needed for the game and the methods
in those classes. At this stage, you only need to describe what a method will do, not how it's done.
However, keep in mind that you can't expect impossible things from methods: they have to be
implemented later.