Theory of Console- and Computer-Game Design Principles

by Adam Trionfo

(January 1997)

This "article" was originally written for a special-problems class at Albuquerque Technical Vocational Institute. The class only contained three people, and we were to work together on the writing of a computer game. This paper was written as my part in the division of labor, but our original goal didn't work out. One person dropped out of the class right away. The two of us who were left used Turbo C++ 3.0 and DOS (running under Windows '95) to work on the game, but it was time-consuming, and we didn't make the progress that we had hoped for.

      In order to have something to show the instructor, a proof-of-concept game called Pig Blaster (its original name had been Pigs in Space) was written for the Amiga computer using the language AMOS, which is a graphic-oriented version of BASIC. Pig Blaster was shown using the school's only Amiga -- a souped-up Amiga 4000 in the graphics lab (quite a treat to use at the time). We each received an A, but the game was never finished.

      Though the game went nowhere, this "article" stands on its own. The ideals that I had gained from writing the OC&GS newsletter spilled over into the paper written for school. The latter was intended only for my fellow classmates, and it's sparse -- but it does get some of my values across.

Computer games. They have changed the way Americans use recreational time. The first computer game was introduced to the general public in 1972. The game industry grew in the late seventies into a hundred-million-dollar-a-year industry. The early eighties saw hundreds of new companies founded to produce video and computer games. Most of the released games were clones of popular games that had been around for a few years. By the mid-eighties, the market was saturated with too many games, and many companies went out of business. Those that survived had to change the way games were being made. It was realized that the consumer wanted something different. The companies that saw this survived, and those that didn't went under.

Computer-game design became a business all to itself. Before the mid-eighties, almost every game was created by a single person. This person was responsible for any sound, graphics and programming involved. This person was usually also responsible for play-testing the game (if any play-testing was done at all). This had to change, and it did. Someone called a "game producer" now exists. This person is in charge of quality. There is no set formula or rules for a game that will make it sell well. A game from a giant game company with lots of advertising money might be thought of as a sure winner, but it might only wind up selling fifty thousand copies (a small amount). Somewhere else, a game released by two people working in the living room of some house could very well release a game that goes on to sell millions of copies. This can never be predicted. Despite the the risks, people continue to try to make and sell games.

This is where the theory of game design comes into the picture. There are some aspects of a game that are sure signs of non-salability. These include, but are not limited to, bad player control, poor graphics and no depth to the game. There may be hundreds of others, but these seem like the most important aspects. You may look at that list and think to yourself that if none of those shortcomings exist, the game will be a top seller. It's not necessarily so. The game could have wonderful game-play, great graphics and an in-depth atmosphere, and perhaps be quite original, as well. But something about it might simply fail to appeal to the masses. There may be no apparent reason at all. The kiss of death for any game is the claim that it is "boring."

Okay; you may now be wondering how all of this affects what we are doing. The game we have spoken about creating, Pigs in Space, is of the type that would commonly be considered a loser. However, I am not saying that we should not create it anyway. We must tune our game-creation skills, and we must begin with something, however primitive. Our first attempt may look terrible, have horrible control and no sound at all, and be no fun. Will Pigs in Space have been a failure if that is the case? I think not. We will have taken the first steps toward creating a later game that improves upon our first efforts. We must remember that we cannot learn everything about game programming all at once. What we learn now will improve our game later.

Here are a few things that I would like to mention about the game we are creating. Allen and I ran an example that was in our C book. It displayed a simple bouncing ball. It had boundaries, it moved, and it flickered like mad! We must avoid that last item. If a simple bouncing ball flickers, then ten pigs, a ship, a planet and bullets will be far too difficult to see. The game will be a bust if we spend a week making graphics that look fantastic, but which are difficult to make out on the screen because they flicker too much. In my eyes, if we spend five minutes making the graphics, but more time figuring out how to make the graphics not flicker, then we will be in much better shape.

Now that it is finally being written to paper, how about a few words on the solid steps we can take to make the game? A simple list of what I feel is important follows. The list is not in order of importance, and we will not, unfortunately, be able to include everything on it:

  1. Good play control
  2. Graphics that don't leave the player wondering if he is shooting at pigs or pies or rocks or piles of dog crap
  3. Graphics that do not flicker
  4. Program structure that will make it easy to change the way the program functions
  5. A low screen resolution. This should help reduce the flicker and increase the speed
  6. We must each have separate tasks. We have already discussed this, and spread the game creation around. As a reminder:
    1. Me: graphics/misc
    2. Classmate 1: menu/misc
    3. Classmate 2: math/misc

I spoke with one of you about writing something like this paper on Saturday. I didn't expect this to turn out so long, but I am glad to have brought up everything I wanted to talk about. Whatever I have missed should be included in conversation or writing on Thursday, when we meet next.

I installed Turbo C++ 3 onto an old Windows 98 laptop computer so that I could compile and try Pig Blaster. It didn't take long to install it or get everything compiled. I was planning on taking a screenshot of the DOS "game" in progress, but that's not going to happen. I mean I can do it, but the game doesn't run correctly. All the graphics blink terribly. The old graphics don't get erased as they should. So, while the code still compiled and ran without errors, it no longer works as it should (or as I remember it).

      Pig Blaster was written under Windows 95, but I didn't think that it would make that big of a difference to run it under the "newer" Windows 98. Of course it is a DOS game and not a Windows program at all. If I ever truly wish to see it run right again, then it should run okay under plain DOS.

      Back in 1997 our small group had no idea of what we were in for, or what we were doing (we really only knew the basics of C and C++), we got lost along the way. I learned that knowing nothing about trigonometry does not help a game programmer; but luckily, the classmate that had stayed in the class did know mathematics very well. Nothing was finished, but boy, did I ever have fun!

      -- Adam Trionfo, March 27, 2012