Friday, 21 November 2008

Case Study: An overview of Zenith

Zenith is a rewrite of The Sentinel, originally designed and programmed by Geoff Crammond in the mid-1980s. The clue here is what I said in my first sentence, "originally designed and programmed by...", so these notes are more about design choices for implementation rather than about originating a game idea.

The Original

Geoff Crammond demonstrated some genius to produce The Sentinel. The game idea was daringly abstract, and its basic rules implied enough strategy to provide interest that lasts through a variety of generated levels. Further, it was coded in a restrictive environment: 8-bit computers didn't quite have enough processing power to pull off the 3D rendering that we know and love today, and the polar 3D projection used in the game meant that the camera could be rotated simply by panning and drawing the new edge of the view, rather than rendering the whole scene for 3D each frame. In many ways, the restrictions of the time helped shape the game.

The Rewrite: Zenith

So, some 15 to 20 years later, we have enough technology to make the (now defunct) game fly again, and I decided to see how the game could be played if the previous technological restrictions of The Sentinel were lifted. This is the Zenith project.

OpenGL provides acceptable 3D rendering, so we don't need to re-invent a special 3D projection; we can use a standard OpenGL camera, and program in smooth mouse-driven motion, along with a zoom feature fot the player to seek out distant targets. This improves on the most-complained-about feature of The Sentinel: the slow movement. Now, we can swing the camera around for a more natural survey of the surrounding landscape, and create an in-game map by moving the camera.

Keeping it Simple

In the interests of creating a game with good balance (i.e. a progression of challenges that holds the player's interest), I kept the graphics as simple as possible. Most commercial games will have their objects designed in a CAD program, like 3D Studio, and imported into the graphics engine at various levels of detail. Not so with Zenith, as the objects are created in the code, vertex by vertex, face by face, responding to the requirements of the game's animations. There are no textures - I just use just subtle colouring and lighting effects.

Drawn backdrops, textured scenery, pretty menu screens, particle physics, and animated cut sequences, would all have been distractions for me, and a playable game could be achieved without these 'distractions'. The only hand-prepared artwork you'll see is the loading splash screen (1/3 of the size of the game archive, in terms of storage), and the little 'success' and 'failure' icons for the end-game, which show either your synthoid or the Sentinel on the pedestal. I feel that extra media would severely slow down the development of the game, and impede the tuning of the gameplay. 'Keeping it simple' proved to be the best design choice of this game.

What's different?

Given the available processing power, the graphics engine could cope with some more variables. Gone is the fixed size of the landscape: we can play in 100 x 100 landscapes, the slopes can be any height, the 'steps' can be any height, the Sentinels can rotate at any speed, and at any increments, and so on.

There are two keys to success: (1) Programming the game to accept lots of variations and handle them all consistently, and (2) Setting the variables to achieve the required game difficulty.

Another minor difference from The Sentinel is that I didn't see much use for the 'meanie' object, so Zenith doesn't have one. Instead, 'partial sightings' from the Sentinel just reduce the probability of being scanned.

Animation has been introduced into the game, given that we have the ability to render many full frames per second. The bad guys rotate slowly, and game objects deform and fade as they are absorbed or created. This is one benefit of making an early design decision about the game models: by creating game geometry on the fly (rather than using preset animations), game objects can respond to any number of actions simultaneously. This makes the game very fluid, unrestricted by simple 'preset animations' that make many games look poor, and it is far more efficient in terms of memory, development time, and managing the animations. Again, less preset content equates to faster development.

Hook and Progression

We start the first level with a small landscape, with a single slow Sentinel, plenty of trees, along with a helpful hint box that guides the player through the first few moves. Almost everyone will be able to play that level without a problem, as it allows plenty of breathing space for the player to learn the game mechanics. The first level is probably the most important to get right from a game designer's perspective, because that's when the player will decide whether your game is worth playing further: if players do not grasp the simple game mechanics (objective, basic moves), then they will be disillusioned and frustrated, and might never play the game again.

I designed the first few levels to be very easy, as I think it's better to allow someone to win easily and then want to replay it at greater difficulty, than for them to give up entirely and literally throw their toys out!

So by level 30 (of 100), the player should start feeling the game bite back. There are more Sentinels, they scan faster, and the landscape has more slopes and features. The gentle initiation is over, and failure is a realistic prospect if the player does not rise to the challenge. After every game, there is the option to go for (1) an easier game, (2) something about the same, or (3) a more difficult game. This is another difference when you compare the game alongside The Sentinel. Zenith allows you to play any level at any time, but you'll start with a small amount of energy if you lose a game, rather than carrying a 'reward' amount of energy forward as you do with a victory.

I could have implemented a pass-code system to unlock levels, like the original, but I felt that this would not have improved the experience. This is giving some trust to the player, and I hope that the freedom offered is used appropriately, to quickly match the game difficulty to challenge the player :o)


To succeed in levels 80+ (of 100) needs the insane action and quick decision that you need at the end of The Sentinel Returns, and I make no apology for this: unless I'm very lucky, I can't beat Zenith at levels 85+ myself! In fact, I don't mind if the game parameters are set too high, as I believe a game should be able to challenge any player. The same goes for my Crossmines, which can set up an almost unplayable game, again exceeding the needs of the most demanding player.

In doing this, I think I've broken one of the 'safe rules' of commercial gaming, in that I've not brought the game to a conclusion - and by that, I mean that the commercial trend is not to make games last forever, but to make a player want to buy more content, more episodes, download more maps, pay for multi-player time, and so on. Another device that I've chosen to ignore is the 'instant gratification reward': I have no pings and trills accompanying floating stars and scores that is typical of Japanese-style casual games. My reward to the player is the journey, rather than the end, or the patronising rewarding of small steps.

Further Tweaks

The New Game box offers a Tweaks tab, which lets the player change the game's variables. There are options to control the aggression of the Sentinel and Sentries, change the availability of resources, and so on. These helped me achieve the right game balance, but I left them in the game in case they provided the player with extra value. There's also a console window, which can make changes to the game, change the graphics options, and display extra information - again, this was intended for development and debugging, and was left in the game for inquisitive players to explore. There is usefulness beyond cheating: during development, the console's parser evolved into a simple scripting environment, which is used to load in preferences and game settings, and the configuration files are, erm..., configurable. I suggest that any game writer equips themselves with a console and parser module, as it has proved invaluable to me for reporting and tweaking the game while it is running.

Links and Further Info

Zenith is a Freeware game, and can be found at

You'll find lots of articles on the web that discuss and review the game, and further reviews and blog postings are welcome.

Saturday, 8 November 2008

Abstraction: The Representation of an Idea

Picture the scene: it's 1982-ish*, and I've spent a good chunk of an afternoon typing in a program in BASIC from two magazine pages. It's called something like Dragon Run, and after spending ten minutes making sure that it is saved to tape, I excitedly type RUN on my flat Atari 400 keyboard.

If memory serves me right, the reality of the game falls somewhat short of the artistry that adorned the page of the magazine: a flourishing drawing of a big green dragon chasing a fearsome (yes, you read that right) knight. The game idea, we're told, is that you must reach the castle from your starting position, negotiating the forest, while avoiding the dragon.

A few seconds after typing RUN, we find that the truth of the gameplay demands some imagination, and that illustration of a dragon has been reduced to a single low-resolution pixel (in a 4-colour, 80 × 48), and the knight likewise. Trees were shown in another colour, each being single pixels.

You might think that is a harsh criticism, but that is not my intention. What we have here is an extreme case of abstraction, where the player has been primed to expect a dragon, a knight, a forest, and a castle, and makes the massive leap from pixel square to dragon. Was it successful? Perhaps!

So, we ask the question, "Is abstraction bad?"

My first answer would be that it's unavoidable, and that it's a question of "How much abstraction is necessary or acceptable?" We can't avoid abstration, which is the substitution of reality for a symbol of that reality. Even images on a live news broadcast are an abstraction of the depicted reality, because lots of information is lost in the representation.

Most modern games strive to be 'realistic' or as unabstracted as possible, often at massive cost (see my previous post), but is this really necessary to implement a good game idea? Most platform games and 2D shooters of the 1980s and 1990s are not very far from the pixel abstraction of Dragon Run, and some imagination was needed to translate the game symbols into something the player understood, whether or not the player noticed this translation into a workable reality.

Players can easily pretend that Pong is squash, tennis, hockey, or soccer (though the latter two are perhaps stretching the abstraction too far!), and that the clump of pixels at the bottom of a Space Invader game is a well-equipped fighting spaceship, so why do we have to spell it all out for the games we make now?

An honest (non-commercial) game would not need expensive graphics to reproduce the game experience, provided the player can do a little mental work decoding the abstraction. In most cases, this player orientation should be a brief learning experience. Game objects just have to exhibit some tell-tale behaviours to remind the player of their function, either in-game, or out-of-game. A good example of the latter (even though it is 'expensive media') is the animated sequences of Astrochase, where we see the astronaut climb into the flying saucer that the player controls in the game itself. The player will then carry this detail into the game, which represents the saucer more simply.

So, with a well-written game, the player can quickly become familiar with the plot, orient themselves, and continue to understand what's happening in the game environment. It doesn't really matter how abstracted the representations are, as long as the gameplay is understood quickly by the player. Further, it is often said that books can be better than films. This is because books make the reader's imagination work harder to fill in the gaps left by an implicit description, often producing a better result.

Concluding statements, then:
  • Do we really need explicit representations within games, when the player's imagination can fill in the gaps inexpensively?
  • Is there a danger of providing too much poor detail, which would be worse than having very little detail?
  • An abstract representation in a well-designed game can produce an enjoyable experience.
*Further research [here and here] reveal that this game was in G&VG magazine in 1983.

Friday, 7 November 2008

On simplicity

I'll start with what is perhaps a controversial question, "Has the gaming industry lost its way?"

That's quite a bold opening punch, but I mean to be selective with it. Over the past few years, we've seen an increase in games having budgets in the millions, and creative contributors in the hundreds, all in the name of 'player experience', where the aim is to create enough content to immerse a player in the experience. Unfortunately, the type of content being generated needs lots of artistry, architecture, and skill. There are some negative side-effects that spring to mind immediately.
  1. The first side-effect is that it's nearly impossible for an individual, small, or self-funded software company to generate the vast amounts of media and content that the newer big games have. This is my first attempt at justifying my opening statement. Are the big games publishers guilty of pushing a product that only they can create to the exclusion of all others? Is this a realistic aspiration: to be untouchable?

  2. The second is that consumer gaming limits the long-term appeal of a game. Following on from my first point, the vast amounts of media, maps, and so on, give a sense of value: that the gamer has bought something that is finely crafted, and it's possible to see the amount of work that has gone into the product. It contributes to the gamer's sense that the game is worth paying for. Commercially, it makes sense to create a product that gamers are in awe of, but there is a flip-side to consumer gaming: limited play. Many recent games, particularly adventures, and their numerically-driven evolution, the single-player RPGs, lead the player through a scripted story. Like a paperback novel, once you've read it, there's limited potential in going back to do it all again. So a gamer's cash can be viewed as being spent on 'timed play', and currently, the rate seems around $1 (£0.60) per hour for those new-ish games.

  3. There is less gameplay innovation, when you can pad a game out with massive media content. For any new game release, ask yourself this question: what is innovative about the gameplay? I'm not thinking of the typical developer's strategy of extending a game's life by "Using the maps in multiplayer mode", nor the technological haze that gets in the way of gaming, such as "new Rasp3X!G engine that can render ten layers of dragon skin", nor "full seamless HDRI multi-pass scene buffers", and so on. I'm thinking of the genuine novelty of something that takes a minute or two to learn, and then the penny drops when the player feels completely at ease with the game! Among the examples I could quote, I'd say Nintendo have succeeded in bringing new (HCI) interaction methods to games by bringing innovative game controllers to the masses. Given that the PC/console setup is mostly an unchangeable 'given', it would be a bit unfair to expect software developers to do anything that radical! I'm really looking new game mechanics, which are successful enough to create their own genres.
Summary and Closing Comments

You might sense that I'm generally not in favour of consumer gaming, and would like to see a return to old-style gameplay. You'd be right. I think the industry is becoming lazy, by defaulting to the safe option of creating lots of limited-life content to support a tried-and-trusted formula, instead of innovating with a unique idea that leads to interesting gameplay.

My opinion is that you can create a far richer game experience by concentrating on new gaming. Instead of spending time and money on content, spend programming time on code that generates the content: procedural generation, when managed well, along with a good gameplay model, it can produce a very replayable game.

Perhaps we should, as an exercise, return to the days when resources were scarce, and see what innovation results?

Finally, a some closing statements, as food for thought:
  • Are modern publishers destroying gaming by changing the shape of games, in order to make a long-term profit?
  • The less you give someone to work with, the more innovative the solution will be.

Background: about the author

I should probably start with a bit about me (you can skip this bit if you like, but I'm writing it in case you want to understand my background).

Essentially, I'm a hobbyist programmer, having completed a few game projects purely for the pleasure of playing them, and from this (relatively light) experience, along with a view of game-playing starting from the days of Pong-alikes, hope that I might have something of interest to contribute to this blog. I do not consider myself to be a professional games programmer, as my commercial programming is limited to the business environment.

If you fancy a wander, my personal website here. You might think it unusual that I reveal that site: I'm not hiding my identity by working under a pseudonym, but essentially, there's nothing to be gained or lost by denying this link. If anything, it will help me to illustrate some of the points I'll write about.

First post and Introduction

There's nothing like the smell of a fresh blog...

So, you've arrived!

What have you come for? Hopefully, you'll be here to read a little about simple game design.

I'm not trying create a serious reference work here, nor am gunning to change the world with my views on game design, nor am I going to make statements about games that will apply to every game and genre. I can not hope to cover everything, but instead, will choose an aspect of games, and shine a small light upon it. I hope you'll enjoy my perspectives on the design of simple games.

Comments are welcome, especially alternate views and experiences. Behave nicely :o)