Saturday, 7 March 2009

Game Complexity and Emotion

We ask ourselves, "What makes a game good?", and then we leave you with the question, "What is the minimum we can do to evoke this in the player?"

What makes a game good?
  1. A sense of achievement. This can be recognised 'stages' of gameplay, measured score, moral reward, or an unlocking of more content in the game environment.

  2. "Bargain!" - the feeling that the game is value for money, and has potential to lasts a long time, such that the player does not think about when the experience will end.

  3. Inspiring a sense of awe from the presentation (graphics are a little more than one can fully take in), and conceptual immersion (the environment itself is awe-inspiring, either technologically or immersively).

  4. Engagement: the feeling that the player can make a big difference to a complex siutation.

  5. The appropriate learning curve: is it adaptable to the players, so that they are challenged but not alienated and without hope.

  6. Any action or threat is well-paced, so that it is never constant, but varied in a way that has maximum impact and engagement.

  7. A suitable environment for (multiplayer) social interaction, to add fluid intelligence to the feedback that computer-controlled players cannot (yet) provide, and to extend existing friendships into the activity to enrich their common experiences.

  8. An interface that is not a barrier for the user, but is instead intuitive and helpful, like an extension of one's own nervous system or limbs.

  9. Fashionable ownership of a recognised asset. This one deserves some explanation: it is the 'me too' aspect of game ownership, when people in the key demographic generally acknowledge that a game would be good to own, for whom talking about it earns social kudos. Although we might at first think that only a marketing exercise can make a game 'cool', we think it's possible to design a game this way, so that it has slowly-uncovered features (so that there's something emergent to talk about), and a social aspect (multiplayer).

Questions
  1. Are there many games that tick all these boxes?
  2. Are there any games that tick most boxes, but frustratingly fail in others?
  3. Are there any more boxes?
  4. Finally, What is the minimum we can do to evoke this in the player?
That last question is really the point of this post. For example, can a very simple game, developed in short time, and with few assets, engage multiple players in an awe-inspiring environment that offers many possibilities, and allows them to use their intelligence to achieve a goal? Do we really need to spend vast resources on developing games, and can an indie developer compete with the big boys?

Thursday, 15 January 2009

Project Spaces - A New Way of Working?

A slight diversion with this post... I'm writing about applications here: using your puter to do things other than gaming.

When it comes to designing user interfaces, I think the main industry players have lost the plot... again. Back when computers were quite raw, and had exclusively hobbyist and enthusiast ownership, we were very accustomed to using 'tools': inserting a disk or ROM for the operating system, loading up an application (or loading a language, then a program, and typing RUN), then inserting another disk to find the object that you're working on.

Then came stories of object orientation from HCI (human-computer interaction) theses and R&D companies, and promises that we'd be working with nouns, rather than verbs when we used our computers, i.e. "This is a book and I want to work on it!", rather than "This is a word processor, and I'll use it to edit my book!". Since then, object-orientation has slowly encroached into developers' mindsets, and into their tools. It has even made its way into desktop environments for ordinary users, a widespread example being OLE, a brave attempt to have people work with objects, without having to think too much about the tools that are needed to use them.

But I think we've lost the plot. We're still thinking on the small scale, where nouns dominate. I can't help thinking that we could work more comfortably, with the larger-scale verbs and nouns: not just the 'book document' and its editing application, for example, but the filing, the resource-gathering, the creative process itself, and the final presentation. I want to work in terms of projects.

I'd like an environment where I can start a session by thinking "I'm going to work on this project", and the environment would present the objects, tools, and data files that I need. If I need to switch quickly to something else, like I often do when working, I'd like to sweep everything to one side, and bring out another set of objects and tools. I feel we're not quite there with this 'modal' way of working. Instead, our computing sessions have all our toys out of the cupboard, all the time, and it's quite a mess. Even though we try to put our toys in the right cupboard, and into self-contained boxes, we're forever wading through the clutter, and some of us lose our things, and don't put our toys back where they should go!

My question now is, "Can we achieve project spaces simply?", but my initial thoughts answer this question with a resounding "No!", because we'd need to sweep aside elements that are currently at the centre of our user experience, and write some new ones, starting at a low level. Explorer or Finder, for example, are fine for moving files around, and finding the appropriate tool to edit a file with, but they don't help much with 'project spaces'. We need a revolution in managing user sessions, so that resources are brought to us as needed, and stowed away again when we're done. As I see it, we need the following components:
  1. A seemingly simple GUI interface, which manages project sessions, in 'project spaces'. These spaces expose your documents, likely tools, and referenced resources, and manage the delivery of finished works.
  2. In the background: archive management, and version control, so that our objects can be accessed as needed by a higher-level interface, stowed away safely, and shared as required. The low-level (conventional) foreground exposure of this functionality would be a file manager, like Explorer, and an FTP client, for example.
Is this all realistic? When can we expect such a revolution? Who should we appeal to, in order to get a useful ball rolling?

Monday, 8 December 2008

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]

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)

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.

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.