On Procedural Generation

Thanks to hribek for a recent thoughful comment, which forms the basis of this post...

> My wish is to grasp procedural generation to such level that you could express yourself by a game.


I suppose you mean 'broaden the scope' of what can be procedurally generated, so that you have a very general object creator, and tweak it according to purpose or whimsy, to generate many different enviroments? Yes, that's possible, but with that depth, you have the potential to generate a higher proportion of useless outcomes, so a designer or programmer needs to be more responsible and clever about controlling the outcomes so that they are playable (or enjoyable for a player).

The very best procedural alrogithms will offer convincing output across a wide range of variables, to give varied experiences. It's no good giving the player something that seems almost the same every time, or the game will be consigned to the bin after just a few plays. There must be a reason for the player to 'up their game' to meet new challenges.

To me, art is about presenting a symbol that is not quite complete, so that it gives the viewer something to puzzle over. Like a game, it is this puzzling, interpreting, exploring, discovering, and making new symbols, that gives the art a purpose and a pleasure. And so, to challenge the human brain, we need to generate symbols that have at least some connection with common experience (a match to the symbols that a common human or seasoned gamer will already know), and combine the symbols (or offer to combine them) in interesting ways to achieve game objectives.

So, we have a very good proposition for a game-writing challenge: Can a game session become a unique piece of art? Currently, the answer is "Not quite", because the basic game will necessarily be almost the same every time. However, we can approach this ideal (in theory - even if it would make no money commercially) by creating enough variation in each game experience to keep the player interested.

For procedural environments, this typically means slowly introducing new features as the player develops experience, or allowing more game objects (or symbols) to interact. This is where the player is invited to create the novel solutions to a posed problem; with each new object, there is a whole new set of combinations available to try, and a new set of strategies available to use as tools. As hribek says, a game like chess offers too many analytical opportunities for a player to fully comprehend, which makes the game difficult to master. A successful game will present the player with a pallet of options, which can be mixed by the player, with some degree of uncertainty, in an attempt to achieve a game objective.

The most successful games have a good pallet of tools for the player to use, such that the players of the game might find solutions not foreseen by the game designers. Such 'implied solutions' are important in sandbox play, and I feel they add more interest than linear games.

The game author must therefore aim to make the complexity managable: enough for a typical player to cope with, without alienating lesser-able players. This is the key responsibility faced by the designer of a procedural environment generator: Offer too many combinations, and the game will appear to be too complex or confusing; offer too few, and boredom results! Not only that, but the designer must also control the variables offered by the generator, to give a game balance that matches the learning curve of the player, to sustain the perceived challenge and enjoyment.

Summary:

• The game designer has a responsibility to make games playable, interesting and varied. To be playable, a game must be readily understood (see previous posts).
  
• Achieving this with a procedural environment generator can potentially give the best results, but this method is frought with potential problems, and the balance is more difficult to achieve with complicated generators. The designer will need to spend a lot of time ensuring that output is suitable for the purpose intended.
  
• The game-playing experience can be likened to the consumption of art. hribe's point is a valid one, that ideally [given enough variation], each game session could become a work of art in itself.

[GameOI]

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)

End-Game?

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 http://johnvalentine.co.uk/zenith.

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

• Zenith - Home Page
• MobyGames entry for Zenith
• Wikipedia description of The Sentinel
• Wikipedia article on Geoff Crammond
• Theodor Lauppert's write-up of The Sentinel
• AtariAge: The Sentinel gameplay
  

• Doug Roberts: Discovering Zenith - remaking a Classic
  
• CNet Download.com listing for Zenith (with user reviews)
  

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.