Sunday, May 17, 2009

Concept: Procedurally-generated content

Designing content (like levels, models, maps, items, etc) by hand can take a lot of time, so this acts as a limit the amount of detail that is put into a game.

The alternative is to generate the content procedurally, which means to create programs that do the design for you in a random and believable way.

One early example is the games Diablo which always create new areas and items so that players never have the same experience twice.

Here's a video that demonstrate this concept:



There is a HQ (Higher Quality) version which you can view by clicking on the "HQ" button on the bottom right of the video.

If you like it, you can download it as a screensaver.
(Note: press "F1" for settings)

3 comments:

  1. You know you are growing old when what you think of as a recent game is referred to as an "early example", although I suppose it makes sense if you consider that Diablo is just a modern roguelike, a style traceable right back to games from the mid 70's such as Moria.

    There are some interesting examples of procedural generation to be found among the 8 and 16 bit games of the 80s, where the technique is used on the fly to to avoid having to store large maps and the like on machines whose total memory was measured in kilobytes.

    The classic game Elite which first came out on the BBC Micro in 1984 used the technique for its galaxy maps. The planets, their locations, descriptions and characteristics were all randomly generated based on a seed value. The developers then picked a handful of galaxies with reasonable layouts (and no rudely named planets!) and put their seed numbers into the code. These are used together with the algorithm whenever the player wants to view the map or information on a particular world.

    Another impressive example is Exile, a BBC Micro game from 1988. This game pushed the BBC hardware to its limits and featured the player exploring a huge procedurally generated cave system that could never have been stored directly in the Beebs 32K of RAM.

    This quote from James Bonfield who hacked about with the code for the game describes it:
    "I did consider writing a map editor, but once I found where the map was "stored" I realised how god-like the programmers were. There's about 1.5K of bitmapped "map", stored in triangular regions. This encodes the complex bits like the ship and a few important locations elsewhere. The rest of it is generated by code. The algorithm takes X and Y as input, and outputs one a tile value (0 to 255, or perhaps less). It accounts for rock strata, water levels, rooms, corridoors, etc. Fantastic!"
    source: http://exile.acornarcade.com/devel.html

    -Andy

    ReplyDelete
  2. Wow, I read that and all I can say is simply amazing.

    Lucky, we no longer are constraint to 32K of RAM.

    ReplyDelete
  3. Yes, nowadays its the opposite problem! The machine imposes few constraints and projects can get easily tied up in trying to accomplish too much and never finish.

    This is one of the reasons I find the competitions over at TIGSource interesting to watch. The constraints of a development time limit and the competition theme really force entrants to focus on the core idea of their game if they are to meet the deadline.

    Which reminds me, procedural generation was the theme of one of last years compos. Alas I haven't had time to check out any of the entries, but could be interesting: http://forums.tigsource.com/index.php?board=21.0

    -Andy

    ReplyDelete