Thursday, 28 August 2008

Results for 'What would help you contribute to the Procedural Generation wiki'; new poll

Thanks to the 27 of you who voted, and those of you contributing to the wiki. The results were enlightening:

Media wiki syntax
1 (3%)
More examples
9 (33%)
More content
8 (29%)
Allow anonymous page creation
2 (7%)
More publicity
0 (0%)
More community
5 (18%)
Less advertising
1 (3%)
Less overlap with wikipedia
4 (14%)
Not interested
8 (29%)
Don't have the time
10 (37%)
Other
2 (7%)

Next poll is one I run on a semi-regular basis to get a feeling for whether I'm on the money or slowing losing my readership...

What articles have you enjoyed or found useful on Ascii Dreams? I've also included work from the column 'The Amateur' I occasionally contribute to GameSetWatch.

More Spore prototypes

Maxis continues to release Spore prototypes with very little fanfare at the rate of about two per week. The latest is WaterBoy - a dynamic fluid simulator on uneven terrain, and GonzagoGL - a more advanced and game-like prototype of the creature phase of the game than the earlier SPUG prototype delivered.

I've added these to the PCG Wiki but haven't had time to review any of them. Volunteers?

Tuesday, 26 August 2008

Brainworks: Sitting on the Fence

By far and away the best game AI blog I read on a regular basis is Brainworks, by Ted Vessenes. BrainWorks is also a Quake 3 mod that Ted worked on for developing a realistic AI - that is an AI that plays like a real person would. This is in itself a complex problem - the vast majority of bots in games haven't had the development time and thought put in to get to this level of simulation. Whereas Brainworks bots look realistic even when you see their game play from their point of view.

There is something special about reading a blog by someone who has got inside a particular problem domain and really worked through the decisions and compromises required to get the problem solved. I hope with the Unangband game design articles that I'm doing a little bit of the same for you.

Friday, 22 August 2008

Designing a Magic System - Part Seven (Elements)

(You'll probably want to read parts one, two, three, four, five and six before starting this).

Elements are an RPG design trope: but appear initially to be a useful one. There are well designed games which have a huge, nay, exhaustive list of different element types: fire, cold, metal, grass, wood amidst the 17 different types that the Pokemon series has featured over the years. Angband has ‘about’ 15 different elements, from the obvious, to mysterious – Nether, Nexus and Chaos being the amongst the more esoteric element types.

The elemental system comes from the pre-Socratic theory by way of Plato which divides the world up into four different characteristics: fire, water, earth and air, which has inspired countless theorizing by later philosophers and alchemists, who have derived the medieval system of humours (with its temperaments of Sanguine, Choleric, Melancholic and Phlegmatic), the aether through which all planets moved, and the Iron Crown Enterprises' Rolemaster RPG supplements filled with pages of spell tables and colourful criticals. The flaw with the elemental system is that it has never had any basis in fact: it was the earlier Indian philosophers and Greeks such as Democritus who was much closer to the modern understanding of matter with the concept of indivisible atoms making up the natural world.

The elements that feature in computer RPGs are derived in part from Dungeons and Dragons and the Rolemaster system, in part from Michael Moorcock’s conception of Law and Chaos in the Eternal Champion saga, in a kind of Chinese menu cocktail of different inspirations and derivations. Elements are used to divide damage up into different types: they may have related status effects, such as freezing, poisoning or burning, and unique to roguelikes, they may damage or destroy different classes of equipment that the character is carrying or wearing. This last function is a lesson in necessity: roguelike players learn quickly never to rely on a single line of defense which may be exhausted, stolen or destroyed.

It is the interaction of elements and damage that proves the most interesting – at least with initial inspection. Different elements of the same ‘damage level’ are in most RPGs less or more effective against different creature types. This is because hand in hand with elements is the concept of damage resistance – that is, certain creatures are harmed less or not harmed at all by certain attack types. Again, there are numerous RPG tropes in this area: skeletons are notoriously hard to damage with edged weapons in many games, ghosts resistant to physical damage of all kinds, vampires hard to kill except with fire or water.

What ends up forming is a matrix of element against resistance: either directly – in that each element is given an explicit resistance value which reduces the over all damage; or indirectly, in that certain elemental attacks are more effective against creatures of other elemental classes: fire more effective against wood or paper and so on.

Resistance is not the only factor that can be brought into play: creatures can also be vulnerable to particular elements, taking more damage explicitly, or healed by them instead of being damaged by them. With regards to healing, it is assumed that once a player learns of this fact, they will no longer use the attack against the creature so healed. With regards to vulnerability: this is exactly equivalent to the creature affected having less overall hit points, but implicit resistance to every attack except the one that they are vulnerable to.

Having both resistances and vulnerabilities makes it harder to balance creatures overall. As soon as a player discovers a vulnerability, they’ll attempt to exploit it – making the overall creature power reduced by the amount the vulnerability increases the damage that creature sustains. In order to make the job of balancing easier, eliminate vulnerabilities from the game – or at least balance creatures as if the player was always attacking them at their most vulnerable point. Otherwise, a creature with a vulnerability is only a puzzle to be solved one time – any further instance of that creature will be summarily dealt with (at least in isolation).

It is this puzzle solving component of discovering resistances (and implicit vulnerabilities) that should be the focus of elemental damage design. The number of elements that the game has is at the heart another user interface problem: similar to the status effects described earlier. The player needs to be able to establish and track whether a creature is being damaged by a particular element that they are employing in order to determine whether to continue the attack type or switch to an alternate attack. At the same time, the player also needs to be able to remember which attacks they have already employed, and whether the creature was resistant to those previously tested. The challenge is to expose this information effectively in the user interface. Again, this will depend significantly on whether combat is turn based or real time – as the player in a turn based game will have significantly more opportunity to examine the interface to make an optimal decision.

The simplest elemental damage system is two damage types with binary resistance levels: either the attack is completely resisted or completely effective. As Ikaruga demonstrates this can be effectively portrayed in time intensive fashion – the game features light and dark attacks and the player ship has two modes which either ignores or destroyed by the attack depending on which mode it is in. Making the attacks more complex trades off the player cost of recognising the attack against their attention span and the overhead of memory recall. At the other extreme, Final Fantasy allows the action to be paused, and a table of elemental resistances for a particular monster type to be displayed which feature a percentile based resistance system. This removes the player from the action completely and requires rote learning or continuous look ups of the table depending on how frequently the creature type is encountered.

Angband falls somewhere in between, in that it features a large number of elements, but creatures which either do or don’t have a particular resistance type. In reality, elements are divided into common and less common types: the five most common are also resisted across large numbers of creature types. Unangband makes the resistance system less predictable for any creature type, but trades this against ensuring that only a limited number of creature types are encountered on any level. For instance, in Angband, no undead resist fire – in Unangband, a limited number do: just enough to keep the player on their toes. Similarly, the rarer element types are only infrequently resisted.

The behaviour using more complex resistance systems is that of the player failing to recognise a resistance, and as a result, using a sub-optimal attack or wasting a valued resource against a particular creature type. This effectively makes the creature more dangerous a threat than otherwise anticipated by both the player and designer. In Angband and variants, this is guaranteed to an extent by requiring that the player learn the elemental resistance by attempting an attack against the creature type: this is then retained in the monster memory for later recall through a text based interface.

At the worst, the player will ignore the feedback telling them that they are not using an optimal attack for multiple turns – effectively multiplying the creature threat by the inverse of the amount they resist the damage by. This implies that the more a creature resists an attack, the greater the feedback they should receive that their attack isn’t working. Leon Marrick in Sangband adopted a feedback system for some resistances where a certain percentage of attacks fail, with a warning, instead of a certain percentage of damge being resisted with each attack. This makes the feedback directly proportional to the individual attack success, while encouraging the player to ‘gamble’ on getting a lucky full strength strike.

The more usual behaviour though will be for the player to cycle through a set number of attacks, trying each in turn until the correct element is found – or for them to guess or find through user interface feedback or a spoiler which the correct element is first time. And if the element damages are equally available and equivalent: that is a fire bolt has a same effect as a water bolt, as a lightning bolt – then there is no benefit in having an elemental damage system at all. And if they are not equivalent: that is fire is always stronger than water, then monsters which resist fire are simply scaled up in effectiveness.

That is the weakness of an elemental damage system in itself: the choices while initially appearing interesting, often devolve to an only one right answer. Elemental damage when poorly designed ends up becoming a game of looking up tables and exploiting status effects. It is possible to manipulate the availability of different elements to make this more interesting, but this is a difficult balance to get right. In designing a magic system, it is necessary to look beyond elemental damage to games which don’t rely on this technique: it appears that Team Fortress 2 is the shape of things to come.

More to come in part eight.

Thursday, 21 August 2008

The Democratisation of Game Design

No sooner did I finish my last blog snippet on the democratisation of level design, then Brenda Brathwaite, game designer par excellence posted a well considered entry on whether procedural game art was the end of the video game artist.

As she concludes, of course it isn't. Neither is procedural generation the death of the level designer, as I initially suggested. Procedural generation in both these areas will initially be techniques that supplement the skills of existing artists and level designers. But reacting to procedural generation as an explicit threat, one which I will admit to deliberately goading by choosing a provocative title for my essay on the subject, is as misinformed as the British textile artisans who smashed the first mechanical looms back in 1811.

In the long term, the skills of level design or texture artist are as important as those of the monks who hand lettered the medieval texts that predate the printing press. You'll probably be luckier in that you'll survive long enough to resemble the shambling corpse that is the comic industry as opposed to fading into complete irrelevance. Unfortunately, progress will roll gently by like an driver less steam roller and leave you in its tracks.

It isn't until the game design tools are liberated into the hands of the masses will we truly be in the era of gaming (With apologies to Marx). There will be a place for Sony, Nintendo and Microsoft in this new world, just as there is a place for the major print publishers, but gaming needs to be as popular and accessible as newspapers, magazines, blogs - not as hard to publish as novels or make as movies.

At least, that is my first instinct. I'm sure to move from this bilious invecture to a much more nuanced and well considered opinion on how both sides of the argument can live in peace. But for the moment, you'll have to put up with my crazy eyed ranting on the subject, with jagged hands raised to the heavens.

The Death: Redux

When I titled my article on procedural content generation 'Death of the Level Designer', this is what I was thinking about.

The ability to paint a level is going to democratise the level design process. If you weren't excited about Far Cry 2 before, I hope the LittleBigPlanet of first person shooters provokes a little more interest.

Wednesday, 20 August 2008

Bio(rrow)me

Continuing on the Spore prototypes theme, I'd love to have a Javascript version of Biome available for use on the PCG Wiki. It'd be great being able to demonstrate things like fire propagation live on the wiki, using 2d cellular automata to visually show various algorithms. Looking at Biome, it is flexible enough to handle a variety of automata using notation from chemical stoichiometry in a 196 kb executable.


An example of this notation from the ForestFire.txt example supplied with the executable:

;Fire

WIDTH = 150
HEIGHT = 150
PAUSE = 0

%%

INIT = {0,0,64}
FIRE1 = {96,32,0}
FIRE2 = {128,48,0}
FIRE3 = {192,64,0}
FIRE4 = {255,96,0}

YOUNG= {0,128,0}
OLD= {0,100,0}
ASH= {48,48,48}

%%

DISCRETE FOREST

%%

;Fire spreads
FOREST:OLD + 1FIRE2+ -> FIRE1*0.1
FOREST:OLD + 1FIRE3+ -> FIRE2*0.1
FOREST:OLD + 1FIRE4+ -> FIRE3*0.1

FOREST:YOUNG + 1FIRE2+ -> FIRE1*0.01
FOREST:YOUNG + 1FIRE3+ -> FIRE2*0.01
FOREST:YOUNG + 1FIRE4+ -> FIRE3*0.01

;Fire rages
FOREST:FIRE1 -> FIRE2*0.1
FOREST:FIRE2 -> FIRE3*0.1
FOREST:FIRE3 -> FIRE4*0.1

;Fire dies
FOREST:FIRE4 -> ASH*0.1

;Initial random forest
FOREST:INIT -> OLD*0.1
FOREST:INIT -> YOUNG*0.1
FOREST:INIT -> ASH*0.1

;Age
FOREST:YOUNG -> OLD *0.01


;Renew
FOREST:ASH -> YOUNG * 0.001

;spark forest fire
FOREST:OLD + 5OLD+ -> FIRE1 *0.00001
(I would get a screenshot, but none of the Spore prototypes run on the laptop I'm currently using. Given that this is my gaming laptop, I'm a little worried for the final release).

I'm working on a Javascript based cellular automaton tool at the moment, which doesn't quite have the flexibility of this framework. It is inspired by the Five Cellular Automata algorithms, although in the very early days of the implementation. You can have a play with the script here. At the moment it just generates a random 30x30 grid, each location of which has 50% chance of containing a cell, then plays the Game of Life.

You'll see the animation stutter frequently: I presume for garbage collection. I'm not sure the cleanest approach for animation in JavaScript. The recommended approach is to use setTimeout or setInterval which creates a callback into the JavaScript code. But this seems to requires that I make the referenced object global as I don't seem to be able to pass it through the callback. Suggestions are welcome.

Tuesday, 19 August 2008

Spore in Space

I've been playing with some of the Spore prototypes available from the website, and I'm enjoying and intrigued by them. From a game design perspective, it's great having early prototypes available, as you can see some of the thinking that has gone into the game, and the ribs of the final design are very visible. I'm surprised that more people haven't reviewed these, simply to see what the final game may be like but there is a difficulty curve associated with the lack of documentation, and the risks of an untested build. As highlighted when you download them:

Usually these prototypes are never seen by the public, but we thought some of the more intrepid players out there might enjoy playing around with a few of our early Spore prototypes. Keep in mind these are not tested, supported or even easily explained.
I started with Space, on the basis of a semi-review by Stromko on this thread. I have to agree with him, in that the Space prototype is the most enjoyable initially because it is the most game-like. You start off zooming around your solar system, terraforming the other worlds and boot strapping your colonies using plants and animals from your homeworld. Once you've collected enough revenue to build a star drive, you can go conquer the galaxy, using much the same methodology, encountering other alien races along the way and harvesting their species.

What is lacking in the prototype is any real feeling of agency - that is, whether your choices create any kind of difference. As soon as you figure out that altitude is the only real measure of whether a species propagates or not, and that using atmosphere generators seems without drawback, it is just a matter of flattening out the planet to a smooth ball at the right height and dumping a single ecology worth of species on the surface. You soon get access to volcanoes, comets and other terraforming tools, but since the species you carry in the cargo holds propagate without limit, there is very little incentive to use these extra tools. In fact, after you purchase the star drive, you'll see your own species colonising nearby solar systems independently of you.

It is hard to judge a game from a work in progress, but I hope they've increased the level of player involvement because at the moment it feels like a sand box that builds its own mountains and tunnels. The Spore prototypes I've tried are dangerously close to being zero-player games. And where is the fun in that?

Sunday, 17 August 2008

A Technology Bird's Nest

The smudged schizophrenic bird's nest of a graph to the left (click here to download a hi res copy) is the Graphviz output of a technology tree that I've been building. I'm in the early stages of designing a Civilization like game that incorporates a whole lot of my thinking around invention and progress, and I'm doing so in the same data-driven design methodology that I've used so successfully in Unangband, which is to come up with a whole lot of examples, play around with the data until it fits together and then develop the game play from the data.

This technology tree has been an incredibly useful exercise, even in its infant and incomplete stages. I've tried to make it invention focused - that is to take specific examples of how an invention came into being, without worrying so much on the social and economic framework required to take the invention and propagate it through society: that'll be the player's problem.

It turns out that technology is a relatively shallow phenomenon - it only takes a few steps to get from the start of human civilisation, to quite advanced technologies. For instance, as soon as you have a stove and rubber, you can invent Vulcanised rubber, and tires only requires the addition of a wheel (and maybe spokes). The discovery of electricity only requires a kite, metereology and penchant for experimentation. Gunpowder happens very early on: in fact I'm forced to deliberately delay the gunpowder invention by inserting fireworks and pyrotechnics technologies, but as the Chinese showed, you need an effective metal-casting technology, and the expansive aggressiveness to weaponise it. The Maori invented trench warfare with only fortifications and muskets, and if you think subterranean cities occur too early, realise that the Christians were building these in Turkey in the 13th century due to religious persecution and favourable local geology, with little more than determination and sharp digging tools.

That technology is shallow allows me to encourage out of order acquisition of technology that I previously wanted in a game, without flying in the face of the historical accuracy that Chris Bateman from Only a Game suggests many players want to emulate. It also shows me that I'm going to have to design a much better user interface to display up-and-coming potential technologies than the technology tree most games use: because of the wide and promiscuous linkages between inventions leads to the messy tree that I've shown you. I suspect this will be a case of displayed a limited number of technologies at the next age based on what you have currently invented, where the age is defined by the minimum number of nodes to get from nothing. So First Age technologies are hunter, gatherer, cave dweller etc, second age technologies are charcoal, sled, skinning and so on.

And thanks to Wikipedia, I've already learned that certain technology tree tropes are in fact historically inaccurate. Bronze is superior in every way to iron - the reason the iron age follows the bronze is because the Philistines unlocked the secret of recovery the metal from hematite ore and made it far more readily available: it should in fact be called the Metallurgical Age.

Saturday, 16 August 2008

PCG Wiki To Do List

With the exception of this first paragraph, this post is a verbatim copy of the current to do list from the PCG Wiki. For those of you who are interested in helping out with the wiki, you'll also be interested in reading the examples page, which was the number one requested poll item. At the moment, of course, it's more of a how to page, but any feedback on how to improve this would be much appreciated.

Ongoing actions and maintenance

There is always an need to update the news items with anything procedurally related. Try to keep each news item to a brief sentence, starting with a single word linking to the external link that describes it, such as Interview with x or Preview of y. Replace x and y with the relevant link within the pcgwiki. Then, once there are more than about 10 items on the page, archive off the older news items to the more news page, which is intended as a reverse chronological list of all news items that have ever appeared on the wiki.

Any upcoming events should be added to the calendar, and have a separate event page created. To create an event page, Add a new page starting with event: and use the event template to describe the event. Any other important recurring dates, such as the release date for a historically significant PCG game, should have a day page created, starting with day: followed by the month space numeric date, such as 'day: august 8'. This will make the day appear in the Anniversary list at the bottom of the events page. To get access to the Google calendar, email andrewdoull@gmail.com.

The pcgwiki has yet to have a problem with spam, but feel free to check the recent changes and see if all the edits are valid.

To do list

The biggest to do list for the pcgwiki is to add and expand existing entries, particularly the games, software and code pages, particularly by adding code examples to the code pages for other people to follow. If you are not an adept coder, you could simply update an existing game entry to include additional information from wikipedia. Follow the examples to understand how to set up and edit the info boxes.

To discuss any items in the to do list below,

The following items are low-hanging fruit:

  • Add the remaining games from the TIG Source Procedural Content Generation Competition. You'll want to go through the list of all 60 games including downloads.
  • Expand on existing game entries by including more information in the info box and description fields. Have a look at the linked wikipedia entry for ideas.
  • Expand on existing code entries by including more information in the info box and providing code examples. Have a look at the linked wikipedia entry for ideas.
  • Expand on existing software by including more information in the info box. In particular, since many of these can be downloaded and played with, writing a review would be ideal.
  • Start creating person entries.

The following items require more work and understanding of the wiki design:

  • Many of the top menu entries are place holders pending a feature request allowing the module backlinks page to only list some backlinks.
  • Investigate the use of categories instead of backlinks to automatically populate pages.
  • Consider splitting the article and links pages up.

You'll also want to have a look at the bugs and quirks page for more issues.

Thursday, 14 August 2008

Disappointed in the KGB

The first Team Fortress 2 Heavy weapon has been released: The Killing Gloves of Boxing. It makes attempting to melee as a heavy 'useful', but I'm disappointed that they are not choosing to re-use existing sandwich assets.

But wait. What's this 'Don't Touch Sandvich' amidst the Russian themed achievements? I'm intrigued...

[Edit: It looks like the sandwich is going in to replace the shotgun. And further speculation here.]

[Edit 2: No one has speculated on something I suspect will be the case with the heavy update, which is that they'll give the base heavy minigun an ability that they can then 'take away' from the alternate weapon.

I suspect, based on the above evidence, that this ability will be to destroy stickies - either placed or in flight. This may also be extended to rockets and/or grenades.

This gives the HWG an increased measure of defense against Demos (and maybe soldiers), while still leaving his vulnerability to snipers, spies and pyros with Backburner intact.]

[Edit 3: I reckon it'll be a pistol/sandwich combo. Having a pistol allows the heavy to have a long range weapon, plus gives the ability of the heavy to take out turrets/snipers on their own. The sandwich may be a taunt animation as suggested by some guy called Robin in the comments section here].

Wednesday, 13 August 2008

Game Design Sketchbook

There's a great article by Jason Rohrer in the Escapist, called Testing the Limits of Single Player. In it, he explores possible games that have deep game play, setting himself the following limits:

Can you make an AI-free, randomness-free, physical-challenge-free, single-player game with gameplay depth akin to that of Go?
Interestingly enough, his solution i45hg is modelled in part on Conway's Game of Life, which is a no-player game that has the above properties. This suggests at least one way around the problem, which is to design a Turing complete interactive game system and let the player explore that.

I can describe another such game, which involves preventing the player explore any previous path. At least, I can't describe the game, but assume that at each stage, there are enough different choices so that the combination of possible sequential choices grows big very quickly. You could design a game this way, which has victory conditions that can be met in a single game, but the player is restricted from ever repeating those victory conditions again. Provided the ratio of victory conditions to non-winning moves is sufficiently low, you'd end up with a game that could remain infinitely replayable without being random.