Design Ramblings

December 1, 2010

I always felt that the early video games, starting with Pong and extending up to the launch of the PlayStation, were appealing partly because of the model of interaction that they presented to the user, which was really simple.  A game showed you the game state, visually and audibly, 60 times a second.  You provided some input that affected that game state.  Ideally, the effect of your input was visible (and audible) the very next update of the game state.  You, as a player,would get into the rhythm of the interaction and develop reactions to the visible state that became reflexive.  Each new game had a different rhythm and you would work to develop your reflexes to work with that rhythm and get as far as possible into the game.

I used to think about games as a tree of interactions where each node in the tree represented a possible game state.  Every 1/60th of a second, your input took you to a new node down the tree.  Of course, it would be impractical to represent the tree visually because there would be so many nodes (if you have N possible inputs,then each level of the tree would contain N times as many nodes as the previous level, which would get out of hand quickly even for a small value of N).  But I still used the tree as a conceptual model.

I used to think of some games as having a broad, shallow tree and some as having a narrow, deep tree.  The broad tree might be present in an adventure game, where the interaction actually happened much slower than 60 times per second, but which allowed for a large number of possible choices each step.  The narrow tree would be present in an arcade game which stepped at 60 times per second but only allowed a few possible interactions (joystick direction and button presses).  I personally enjoyed the fast action games that offered simple, frequent interactions.

When I talk about game design, I’m talking about single player arcade-style or console-style games because those are the games I like.

One of the guiding principles that I used when designing games was that a visual and audible response should occur the very next game frame after the user pressed a button.  I thought this was very important so the player would get immediate feedback so they would feel that their actions were consistently taking effect.  When you pressed the shoot button, the projectile appeared the very next frame along with the beginning of an audio clip.  Any delay made it harder to get into the rhythm.  Worse,a variable delay made the game feel choppy and unappealing.

Another principle that I used was that the game state be communicated to the player in an explicit and unambiguous manner.  The display of health points must be clear and obvious: it could be a number or a set of filled-in icons, but the player must know exactly how many hits he/she can take before dying.  Any ambiguity just detracted from the clarity of the communication between the game and the player.  I never understood the games that displayed health points as a bar graph or, worse, an image of the player’s face that got successively more damaged.  To me, these just introduced ambiguity and confusion and didn’t give the player all the information he/she needed to make good decisions.

Displaying the number of health points goes hand in hand with having a predictable amount of damage.  In general, I preferred having each hit consistently cause one point of damage because it’s absolutely clear to the player what’s going on.  If I have two health points left and I’m about to be hit by a projectile, I know I’ll survive the hit and I can factor that into my decision-making.

Modern games have gone in a different direction.  These days, in third-person games,hitting an action button usually starts a lengthy, realistic animation that eventually causes a projectile to be fired.  Having a different weapon causes a different animation to play out with a different delay before the projectile appears.  Health might be communicated as a number or a bar graph, and hits from different types of enemy projectiles might cause different levels of damage, so when your health is low, you’re never quite sure if you’ll survive.  Controllers have many, many buttons to press and many different modes and sequences that need to be memorized.  The interaction tree is wide.  The standard frame rate is 30 frames per second, and most games have fluctuations in the frame rate that detract from the overall smoothness.

All these things make games a lot different than they were when I was designing.  Obviously,many modern games are technically impressive, appealing to many players, and commercially successful; many of them are very, very good.  I’m not trying to argue that my way of looking at things is better or that the new games aren’t as good as the old games were.  I’m just mentioning this stuff to clarify how Inertia 360 games are going to be different from a lot of modern games.



December 1, 2010

I’ve been working as a game developer since the summer of 1989 when I started out working on games for the Atari 7800.  I have a degree in Computer Engineering and have held the role of a programmer throughout my career.  When I was younger, I had a strong interest in game design and I had a number of ideas about what it was that made games better.  I was even lucky enough to do some design work on a game or two.  In the last decade or so, my interest in design has waned a bit, mostly because of the way video games have evolved over the years.  It’s not that I think games have gotten worse, but I think they have gotten a lot more complicated.  My old hypotheses about what made a good game don’t seem to be valid anymore (if they ever were); modern game designers and implementors seem to go against my hypotheses and still produce high quality, commercially successful games.  I still have a nagging feeling that I have some good ideas, though, but it’s not really practical to work against the tide of the modern game industry in my day job.

Maybe it’s possible to test out my old ideas by working alone in my downtime on some little mobile games.  That’s what I hope to find out with Inertia 360.  In addition,over the years I’ve had a number of ideas for game mechanics that I always wanted to try out to see if they’d be fun.  And I always have ideas for running a project efficiently, but can’t really test them out at work.  So Inertia 360 gives me the opportunity to try out a lot of things.