Designing the Single Player Economy

An excellent article by Richard Knight called 'Designing the Single Player Economy' has been sitting in my Google Reader starred items for some time, waiting to be let out. It's well worth the read, if you'll excuse the slight pun.

If you're a budding game economics designer, you may also want to read the article I mention in the post script to an article I did about shopping in Angband on the meanest game Nintendo ever made.

Results for 'Which procedural content generation types will you use for the Independent Gaming Source competition?'; new poll

The results for 'Which procedural content generation types will you use for the Independent Gaming Source competition?' are in - thanks to the 8 of you who voted and I'm looking forward to playing your entries.

Wikipedean little 'p' procedural generation	0 (0%)
Runtime random level generation	3 (37%)
Design of level content	2 (25%)
Dynamic world generation	4 (50%)
Instancing of in-game entities	3 (37%)
User mediated content	0 (0%)
Dynamic systems	3 (37%)
Procedural puzzles and plot-generation	3 (37%)
Other (answer in the comments thread)	0 (0%)

The new poll is relatively straight forward. You may want to read Minesweeper vs Solitaire to refresh the arguments, including the relatively long comments thread.

Nevermore

We are currently toning down the random deaths in Unangband. (With apologies to Edgar Allan Poe).

Are you a true athlete?

Real men chessbox.

(Thanks xkcd.com)

Minesweeper vs. Solitaire

I was going to write this another day (heh), but I've been preempted by an article in Slate magazine. Amidst the procedurally generated games I listed on the PCG Wiki, I slipped in Minesweeper as a way of leading into a discussion about what constitutes a PCG game.

I was going to argue that Minesweeper is PCG, but Solitaire is not. The reason being that randomness is a necessary but not sufficient condition for a PCG game. What is important is biased randomness. Procedural content is about exploring a set of rules underlying a seemingly random system. I wanted to exclude a game I deemed 'sufficiently random' that was clearly mental junkfood to compare it to a more controversial position that Minesweeper is PCG.

Apparently though, Solitaire is not mental junkfood (supported by an intelligent comment on Slashdot. Now the world has turned upside down, you can return to your regular service).

So feel free to argue for either game as being PCG. And the consider, is Poker a procedurally generated game?

Strafe Left: Catacombs of Zascii

Amidst the many roguelike comics out there, Strafe Left has just republished the best ASCII sight gags ever. Giggle to yourself contentedly here.

Thanks, Rock Paper Shotgun. You can make love to my undead tadpoles anytime.

Boing Boing

Rob Beschizza of Boing Boing Gadgets has thoughtfully linked to the fledgling PCG Wiki. He's overstating the number of articles on the wiki already (I think he confused the visitors figure with the articles figure on the last wiki post I made). Many of the articles are stubs which link through to the relevant wikipedia entry, but I'm hoping that contributors (that means you, gentle reader) will fill out the details.

I also hope this isn't premature publicity: I want the wiki to be a long term resource, not a flash in the pan, and don't just want people to turn up, wander around and leave disappointed at the early state of the site.

Motif-Index of Folk Literature

A comment by Mandaya in the John Harris column on narration in roguelikes has pointed me to the 'Motif-Index of Folk Literature'. This fabulous resource for procedural generation of narratives is handily arranged in a 600 page index which you can use to create random plots from. It might need a little massaging to fit into the context of a game, but the contents are inspirational to say the least.

You can learn about how to read the index here, and the alphabetical reference starts here. The full title of the book alone suggests how exhaustive it is: Motif-Index of Folk-Literature: A Classification of Narrative Elements in Folk-Tales, Ballads, Myths, Fables, Mediaeval Romances, Exempla, Fabliaux, Jest-Books, and Local Legends.

Slight oops

I started writing Unangband Magic System - Part 3 (Powers and Patterns) on Friday, which is why it appears out of order below. I've only just published it now - have a read.

What they want...

It's been about a week since I announced the Procedural Content Generation wiki, and it has had a few visitors already (350 or so) - thanks to whomever added the site to stumbleupon.com. When I first started, I expect the most popular parts of the site to be the list of articles on procedural content generation and related references but I should have known better. What it appears that people want is lists. Specifically, lists of what games feature procedural content. I've been adding to that list today to try to fill it out a bit, but I'm open to suggestions as to what is missing. I know the majority of roguelikes use procedural content generation, and you're welcome to create an account and add those in, but I don't want the wiki in general to replace the already excellent resource RogueBasin.

So what other games feature procedural content generation that I'm missing off the list? In particular, note that the game can have content generated procedurally in the level designer - it doesn't have to occur at run time. So any games featuring SpeedTree for instance are good candidates. But at the same time, I don't particularly want to include games that use procedural generation for things like graphics and textures.

Also, anyone particularly interested in cellular automata: there is definitely a place in the site for you.

What they lack...

John Harris just laid the smackdown on those narrativists who complain about the lack of story in roguelikes. Oh, and he justifiably pimps the original Dungeons & Dragons against the spineless emo modern edition.

(My apologies for language: I've just been reading those hos at Penny Arcade).

Designing a Magic System - Part Three (Powers and Patterns)

(You'll probably want to read parts one and two before starting this).

In the first part of this series, I outlined the importance of suspension of disbelief in designing a magic system to fit the narrative of the game. But from a game design perspective, what do I mean by magic system? After all, there are distinct differences between the implementation of magic across various games - what unifying factors can we find within these implementations to allow us to consider which design is 'best' for the game play? Several games which feature magic prominently should help suggest the common ground.

Angband and the majority of Angband variants have a limited amount of mana available which slowly regenerates over time. Spells cost mana to cast and take a single turn to use, and the player can cast a spell that results in negative mana, but at the risk of fainting, both losing health and costing additional time. In addition, magic objects can be found, which have a limited number of charges, or require a recharge time to use. As the player power increases, their maximum mana also increases, which means that they can cast spells more frequently.

Advanced Dungeons & Dragons (2nd edition and earlier) limits the player by forcing them to pick a set number of spells each day to use. As the power of the player increases, they may learn and therefore cast additional spells per day, including spells of higher 'level' which are more effective. The spells must be learned in advance, so priests, especially, tend to conservatively learn healing spells, as these are almost inevitably useful. The 3rd edition of D&D allows a priest to substitute any spell for a healing spell to alleviate this defiency in the design.

Magic: The Gathering uses the concept of mana pools. At the start of each turn, the player has an empty mana pool. Then, by tapping sources of mana from cards that the player either has in play, or plays throughout the turn, the amount of mana in the player's mana pool increases. This mana comes in various colours, which correspond to the five basic card colours, as well as a colourless mana, which can correspond to each type. Then, the player uses mana from their mana pool, to play additonal cards or use powers of cards already in play. This deplenishes the total mana that the player has available. The limiting factors for the use of magic, are the total cards that the player can tap to generate mana, the majority of which 'untap' at the start of the player's next turn and can be tapped again. In particular, the player can place one land card per turn, and land is the primary source of mana in the game.

World of Warcraft is similar to Angband, in that the player has a total pool of mana which they can cast spells from. In addition, spells individually have a cool down, so that a spell cannot be spammed multiple times in a row. Some spells have an instant casting time, which means they take effect immediately, but others take longer to cast and can potentially be interrupted or delayed. World of Warcraft is well worth studying because there are a number of excellent resources such as the WoWwiki which provide thorough detail of the in-game magic system for those of us worried about the addictive effects of actually playing the game.

Looking at the above four magic systems, there are a number of systems that limit the use of magic. And this suggests a more formal definition of what an magic system is from a game design perspective: 'the use of any game ability which is limited over time by a game mechanic intended to balance this ability'.

This definition is sufficiently general to cover all of the above games, whether time is real time (WoW) or over discrete turns. It also potentially includes abilities such as Mario's double-jump (which can be used twice while in the air but no more), any game that allows you to sprint for a limited time (such as Half-Life), or even first person shooters that that have a limited rate of fire to the weapons.

But I don't see this generality as a problem: you can turn this around and use the same techniques for game design of first person shooter weapons, to design an effective magic system. The damage per second metric that the developers of Dystopia carefully evaluated for the design of the weapons in this Half-Life 2 mod (interview was here but appears to have disappeared), is as important for the design of the Rogue class in World of Warcraft, is as important as the damage per turn metrics that are critical in Angband and variants.

So what game design patterns are common to magic systems? I'll take a leaf from Gamasutra's excellent overview of game design patterns, in particular with regards to the importance of naming patterns, for presenting several ideas. Each of these design patterns is used in one or more of the magic systems above.

1. Battery

Problem: We don't want the player to use an in-game ability an unlimited number of times in succession, as this would unbalance the game. However, a short sequence uses is appropriate, followed by a delay during which the ability cannot be used. This may be to balance the damage per second of the ability, or create an interesting trade off between selecting different abilities to use.

Solution: The ability runs off of a battery which has a total charge. Each ability costs some of the battery charge, and the battery regenerates over time to replenish the charge. The maximum charge divided by the usage cost determines the total number of times that the ability may be used in succession, and the regeneration rate determines the time required to get back successive uses of the ability.

If the player has multiple abilities, they may have a different battery for each ability, or abilities may share a single battery (Such as the sprinting and the flashlight in Half-Life 2). The total amount of recharging may also be limited, in which case the battery reserve acts more like ammunition. There may be a recharge delay between the initial use and the start of recharging (cf shields in Halo or mana in Magic: the Gathering). Battery power may also be 'coloured' so that some abilities can use the battery power but not others.

Consequence: The battery allows the player to have periods of high utilisation of an ability followed by a respite during which the player is more vulnerable. This results in the game having a flow of activity followed by recovery; which fits the pattern of behaviours that Valve has reported being ideal behaviour at a more macro level, as players are unable to sustain frantic activity continuously. The battery also has tactical impact due to the increased risk during the recharging period - should the player space out use of the ability to ensure that they have a reserve in the event of requiring it unexpectedly, or should they use the ability as much as possible immediately to overwhelm any obstacles.

Examples: Mana in Angband and World of Warcraft fits the battery paradigm. The recovery time in Angband also results in increased danger, as more monsters will spawn on the dungeon level the longer the player rests.

2. Power plant

Problem: The player has a number of abilities which we want them to use simultaneously, such as moving and attacking. We still want to allow a tactical trade off, but to have periods where the player is completely unable to use the ability extremely risky, so we want these periods to be rare and explicitly requested (as opposed to the battery design pattern, where normally use can exhaust the battery).

Solution: The abilities run off a power plant which has a total power output insufficient to allow all abilities to be used simultaneously. Power is allocated to each ability explicitly, so that a percentage of the ability can be used if less than full power is allocated to it (e.g. the player may move slower, or not be able to fire as quickly, or use as many weapons at once). Some abilities may instead have a threshold power level, which is the minimum or mandatory power level required to use the ability.

Consequence: The power plant requires more management than the battery, in that instead of just explicitly using the ability, the player must also be responsible for allocation of power appropriately. If the player does not specify an allocation, the previous allocation continues to be used until the power levels are changed. Note unlike the battery, the power plant is never explicitly exhausted (see refueling below, however).

Note that the power plant design pattern may implicitly occur for an ability that has a timed effect and uses the battery paradigm. If the recharge time exceeds the charge cost, it is possible to use the ability continuously, and therefore the power plant design may be more appropriate in this instance. This occurs in UnAngband where bless is a timed spell, whose casting cost is so low the mana required to cast the spell is regenerated by the time it finishes. An equivalent power plant design for timed spells would be a significant UI improvement in this case.

Example: In Incursion, spells that have timed effects that last all day. Instead of casting these explicitly, the player just decides whether the effect is on or off, and then reduces the total amount of mana available to them for the remainder of the day if the effect is applied. This means that they regenerate to a lower total mana level than if the effect was not applied.

The power plant design pattern could be used to increase the tactics required in Eve: Online, as at present, there is no decision around whether or not to move at full speed and fire all weapons at once.

3. Refueling

Problem: Suspension of disbelief may require that a resource does not regenerate perfectly or is completely inexhaustable. Therefore, a battery may run out after a limited number of recharges, or a power plant may be exhausted after a limited power output.

Solution: The player must refuel the battery or power plant by performing a small fetch quest to a refueling point on the map. To increase the likelihood of nearby fuel being available and to decrease the repetitive nature of the fetch quest, fuel may also be dropped by defeated enemies.

Consequence: The player may have to risk exposing themselves or abandoning a secure position in order to recover fuel. This may minimise the risk of any map exploits being taken advantage of. This is balanced by the unfortunate necessity of having to repeatedly move to a common point, away from the action in the game.

Example: Weapons in Team Fortress 2 all have limited ammunition, which is quickly exhausted. Replacement ammunition boxes of various sizes respawn around the map, as well as an ammunition cabinet at the player respawn points which fully replenishes ammunition. Killed enemies will drop their weapons, which can be picked up to replenish ammunition as well.

4. Cool down

Problem: Some abilities can be used by the player to trap an opponent, by using the ability frequently enough that the opponent is never given sufficient recovery period from the side effects of the ability. These abilities can include anything which involuntarily moves the target around the map, as well as anything that disables the target or interrupts target actions. The player can then exploit the trap, by using the ability continuously.

The battery design makes it hard to enforce an upper limit on the number of times an ability can be used, because it may be possible to regenerate enough charge during the time the opponent is disabled or the time recovery to move or recover from interruption. The power plant design makes this impossible to enforce.

Solution: Allow the opponent to have a counter move to each possible ability, that they can use to avoid the trap (See David Sirlin's website for commentary on this design pattern). However, designing counter for each ability is difficult - in which case, the cool down is a good fall back method. The cool down is a period during which one or more abilities may not be used again, following an initial ability use. Note that the cool down may also apply to a combination of abilities that could create a trap together.

Consequences: The cool down forces the player to use other abilities during the cool down period, which may result in greater UI complexity, both to show the cool down duration, and make additional abilities quickly accessible.

Example: Many abilities in World of Warcraft are restricted by cool downs. Rods and activatable artifacts in Angband also have a cool down timer.

5. Juggling

Problem: Allowing a player to use abilities limited over a time period may not be appropriate. For instance, a platform game may require that the player jump twice with millisecond separation, but allowing the player to do this while in the air will allow the player to walk on the air between platforms. Additionally, resource constraints may prevent the game from running multiple copies of the ability at once.

Solution: Restrict the use of the ability on a non-time dependent criteria, usually related to either how many uses of the ability are already in play or having a battery regeneration condition that is not time dependent.

Consequences: The player is forced to juggle use of this ability in a less intuitive manner.

Examples: The original Space Invaders could only display a limited number of player bullets. The player could fire immediately once one bullet hit a target however, allowing them to attack closer targets more quickly than further away targets. See also Mario's double-jump for another example.

6. Ramp-up

Problem: The player wants to feel progression over the course of the game, and there is not enough of a skill requirement in the game to provide this feeling of progression through improving player skill.

Solution: Over time, the maximum capacity (either battery charge, power plant output or another measure) of the ability improves. This could be from turn to turn, as additional resources are brought into play, or over a longer period of time as the game is played. At approximately the same time, the challenges faced also ramp up, to ensure the game stays approximately as difficult to play.

Consequence: There are two key consequences of this design. Firstly, any part of the game design that modifies the slope of the ramp up curve needs to be carefully considered. Secondly, the skill level requirement of the game may be flattened out completely by grinding parts of the game to increase the capacity ahead of the difficulty curve, or by making the increase in challenge too explicitly linked to increasing player power. The best decision here may be to make one or the other increase explicitly time dependent, so that the player is unable to take advantage of grinding for extended period.

Example: The Power Nine in Magic: The Gathering are an excellent example of abilities which unduely increase the slope of the curve of mana development. In fact, almost every card which provides additional mana has the same consequence. With regards to grinding, no examples are necessary as it is a core RPG requirement.

7. Build & Respec

Problem: Giving the player an unlimited choice of abilities makes them unduely powerful, because of some of the abilities are designed exploit a specific opponent weakness. If the player can use any ability, they can always exploit this weakness, therefore any opponent with a weakness is less powerful than otherwise designed.

Solution: Restrict the player choices by having a build system of some kind, such as by using classes, skills or an inventory of abilities that they can use. Put restrictions in place, so that the build system allows a balanced set of abilities to be chosen, and the player to learn the advantages and disadvantages of each ability selection early in the game. Make respecifying the build as easy as possible, so that the player can change the ability load out at any point in the game, while limiting the respec so that it cannot be easily done in the middle of an encounter with an opponent.

Consequences: The build and respec system is a complex process, both to design and for the players to understand. It is critical that the player is given the opportunity to respec as often as possible, so that if they make an incorrect or suboptimal choice in their build design, they can fix this with minimal consequences. The game designer can also use this to evaluate if certain abilities are under or overpowered by the frequency of their selection in builds.

Examples: Unfortunately, class and skill based games do not usually have a good respec system for the class and skill builds, unless it features frequent death and respawning into a new class. The Dungeons & Dragons magic system allows a respec of the spell list at the start of each day, which is as close as that game system comes to an adequate respec system. Only inventory based games allow a flexible respec system with the appropriate limitations. See Skills vs Classes for an expanded argument to this effect.

Part four discusses some further design patterns: damage and status effects. Feel free to suggest other design patterns in the comments thread.

Fatherhood and Moorcock

Following the review of the 7 day roguelike Fatherhood on Play This Thing Jeff Lait has written up his design notes of the philosophy behind the game. It is well worth reading for to see how he uses simple mechanics to reflect real world behaviour and how those translated into the game.

And off-topic from roguelikes, but interesting nonetheless, I've been enjoying Chris Bateman's series on the works of Michael Moorcock. I immensely enjoy Moorcock's approach to fantasy writing as opposed to the staid generic fantasy worlds of so many other authors. You definitely have to start with his earlier work to build up to the incomprehensibility of some of his later novels and get a feel for his rhythm of writing and ideas behind the worlds.

Misty eyed reminiscing

I stumbled across some old writing of my while googling my own name earlier today (Come on: you do it too. Admitting it is the first step). I wrote a couple of articles for Traveller: TNE 'back in the day', which Sword of the Knight Publications ended up picking up and publishing in their magazine Traveller Chronicle vol. 9. You can see the article details here.

As I recall, Hardware: New Cybernetics added more extreme body modifications, including lower limb removal for those dedicated to zero-g combat, while Lock on Sensors was a redesign of the Traveller space combat to make the decision around 'going active' more significant. The text of both these articles was online at one point, but I've not been able to find the links in a cursory search.

Announcement: Procedural Content Generation Wiki

In what little free time I have at the moment, I've been busy.

A large number of people come to this site looking for information on procedural content generation, and while I'm happy to act as an unreliable source of advice, I know there are greater minds out there than my own. But there is also a gaping hole in the Internet where procedural content generation seems to fall through.

Therefore, I'd like to pre-announce the Procedural Content Generation wiki. This wiki is intended as a home for all things procedurally generated, and over the next few weeks I'll be building up a repository of links and articles that are less focused on what I think PCG is, and more on what the world at large does. You are invited to contribute to what is very much a bare bones project at the moment.

It's also a great opportunity to initiate more of a n-dimensional dialog with you the readers, that the comments section of this blog does not have the ideal design for. That's why in addition to the wiki at large, there is an extensive forums section which you are invited to join and start talking.

I'm always conscious of the balkanisation of the Internet, which is why the forums are intended for discussing about procedural content generation and not necessarily any game in particular. But you may find it as a refuge for the slightly older 8 bit generation, who remember X-Com, Elite and other gaming greats that used these techniques.

Poll results for 'Which of this years 7DRLs have you tried?'; new poll

It's been a while since I've updated the poll - mostly lack of inspiration for new polls. Luckily, I can segue from the current results straight into a new game competition. The new poll is for those of you thinking of entering the Interdependent Gaming Source procedural content generation game competition. What procedural techniques will you be using in your game? If you haven't already, have a read of the series of articles on procedural content generation, to give yourself an idea of what I mean by each choice.

The results for the last poll (15 of you voted) were:

chrysalis	6 (40%)
Countryside Zombie	1 (6%)
Fatherhood	7 (46%)
TrapRogue	3 (20%)
MegamanRL	6 (40%)
Dungeon Climb	0 (0%)
Numbers	2 (13%)
Tribe	2 (13%)
TimeRogue	1 (6%)
Mines of Elderlore	1 (6%)
ASCIIWar	1 (6%)
Crown of the Forest	1 (6%)
Fridge	2 (13%)
None of the above	3 (20%)

AI and Procedural Generation

For those of you who haven't grokked procedural content generation for things other than maps, you may want to read Chet Faliszek's clear explanation of the AI Director in Left4Dead. For those of you who have, you can instead depress yourself with Dave Mark's description of the combinatorial explosion that causes problems for automated testing of AI (and PCG).

Designing a Magic System - Part Two (Choices)

(You'll probably want to read part one before starting this).

So if suspension of disbelief is the key to the designing reasons that magic could exist in your game world, what is the key to designing the game play role that magic should have? In Unangband, and I'd suggest in the design of every single player magic system, the answer is choice.

A key component of the Angband game design is the inventory limit - that is the hard limit of 23 different types of items that you can carry at any one time. From a realism point of view, limiting the player to carrying 99 potions of the same type, but using up a second inventory slot to carry an additional 1 potion of a different type makes no sense - but when considered from the paradigm of limiting choices, it fits perfectly.

The sum total of choices you can make every turn in Angband, in fact in all roguelikes, is the number of possible commands not involving equipment, plus the number of different ways you can use each item in your inventory. The importance of having a range of choices is even more pronounced when you realise the three goals in the game:
1) Stay alive
2) Kill Sauron
3) Kill Morgoth
At every turn, you must make the choice that ensures 1, and maximises your chance of 2 and 3 occurring at some point in the future. And to make the choice, you must have the choice available to you. A wide range of equipment types in your inventory increases your possible choices, and consequently increases the chance of having the correct choice available to ensure you stay alive.

As a warrior in Unangband, you have the least choices available of any class. You can move, attack, use potions and scrolls reliably, and have a slim chance of using any other item in the game. Playing a magic using class on the other hand greatly expands the number of choices you have, because each book can contain up to 26 spells, any one of which you can pick if you have learned the spell. This means, depending on your spell selection, you significantly increase the number of actions you can choose to do at any turn. The sacrifice that the magic using classes make is to trade these increased choices by reducing their effectiveness at the most straight forward choices of move and attack, and increase the overall risk at every game turn (by having less total hit points).

A class based game is uses this warrior vs. magic user as an indication of preferred playing style: a few, shallow, easy choices vs. many, deep, difficult choices. The disadvantage of class based games is that they require considerable play to determine the capabilities of the class - choosing a class is a decision you're forced to make in advance of knowing the costs and benefits of the decision. In a skill based system, not only do you have this problem, but you're also burdened with the fallacy of equivalence: the game design has to somehow equate one point of each magic using skill with a point of melee skill (or worse, figure out the relative 'cost' of each). In a classless, skill-less game, you can easily choose and discard inventory choices as you encounter new items - additionally you are not penalized by having items generated that you can never potentially use. This particularly affects magic using classes from the Dungeon & Dragons tradition, who are restricted from heavy armour or sharp weapons for seemingly arbitrary reasons.

Note that choice is not a necessary component of multi-player game magic systems. Multi-player games are usually about doing one thing and doing it well. In World of Warcraft, as an example, this consists of the holy triad of tanking, healing and dps. Tanking involves taking damage from the main monster in an encounter by manipulating the monsters attention (aggro) so it always attacks you, healing involving keeping the tank alive, and dps involves damaging the monster as fast as possible in a way that prevents it attacking you instead of the tank. A tank that can do two other things, at the trade off of not tanking quite as well, is almost entirely useless. This is the problem of hybrid classes that John Hopson examines in MMO Class Design: Up With Hybrids - An Economic Argument. His basic argument is that the tanker - healer - dps triumphvate is so effective, that you have to engineer specific encounters in the game that force hybrid classes to be useful by breaking up the ability of this grouping to work.

World of Warcraft emphasises the choices you make in the 'build' of your character prior to combat, instead of the choices you make in combat. Eve Online operates in the same way, as James Lantz of In Machinam explains in The Machinery: Eve Online. Eve space combat usually features a lead pilot 'calling out' targets in sequence, with everyone in the same combat group / fleet / wing targetting the nominated target until it is destroyed, before moving onto the next. This mechanic relies on the accumulation of overwhelming firepower to bring targets down, with very little tactical choice from individual participants.

One vs one multiplayer games are an exception to this ganging up process that demands 'excellence in a single activity'. David Sirlin advocates an asymetric rock-paper-scissors approach as a means of encouraging yomi - that is the state of knowing what your opponent will do next and countering it. In asymetric rock-paper-scissors game, the game plays the same, but the pay-off is different for each winning move: $1 for rock, $2 for paper and $10 for scissors, for instance. This means that you always have a low risk, and high risk strategy - should you go scissors for more money, or rock to counter the high-risk strategy? A good opponent should be able to take advantage of this concept of yomi to predict what you'll do. But the theory of mind behind this prediction strategy breaks down when you are not able to determine your opponent reliably, or you encounter them infrequently enough not to be able to learn their playing strategy and take advantage of it.

In this series of articles so far, the lines between 'magic system', inventory and technology, and abilities / talents / skills (call them what you want) has blurred. I'll attempt to more formally define what I mean by magic system in part three.

Procedural Generation Competition

In the continued argument why everything old is new again, TIGSource is now running a procedural content generation game programming competition.

You may remember previously (Make a Game March Madness) that the Independent Gaming Source ran a video game design competition based on the Video Game Name Generator, resulting in a significant number of entries that received wide spread coverage.

This time around the theme of the game is something dear to my heart, with an emphasis on "generating new content every time the player starts the game" and you have from Monday, May 5th to Monday, June 2nd to write your procedural pièce de résistance.

And they've thoughtfully linked to something I wrote on the subject.

Designing a Magic System - Part One (Suspension of Disbelief)

(This article is in fifteen parts: parts one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, thirteen, fourteen and fifteen, along with the follow up series Designing a Magic System Redux).

I have a confession to make: The Unangband design articles so far have primarily been about solved problems - game design issues where I have come up with a solution I'm satisfied with. The Unangband magic system on the other hand is still an open challenge.

Magic have existed as a part of role-playing games since the earliest days of Dungeons and Dragons which borrows liberally from fantasy novels, in particular Jack Vance's Dying Earth series. Magic systems exist as two separate challenges in game design: firstly, there is the underlying reason that magic exists - required to make a completely unrealistic mechanism a believable and consistent part of the game world, and secondly, there is the game balance issues of the magic system design and implementation. It is this second challenge that this article series will focus on, but it seems to be this underlying reason for the existence of magic that most people try to address when they first approach designing a magic system.

Suspension of disbelief is an important aesthetic theory: the ability for the person playing the game to buy into the consensual fantasy that you are building. When it comes to designing a magic system, you must consider how magic 'works' - that is, how the people in the game world can influence the world around them in seeming arbitrary fashion. There is a wide range of sources you can draw from as inspiration for how you design the magic system: existing superstitions, a large body of 'magical theory' for people who believed that they in some way could practise magic in real life, a larger body of religious beliefs you can similarly draw on, and various modern pseudo-scientific traditions that are more relevant if you are designing a modern or futuristic game. Finally there are genre tropes and conventions that you can quite happily slot into the game and have the vast majority of role-players immediately understand because they have played with these conventions before. Unangband definitely falls into this final category, as does any other game which starts players off with a 'magic missile' spell.

Conversely, to make your game world more believable and immersive, you should also apply the corollary - consider how the existence of magic in the game world has influenced the people, cultures and places. Build up a body of creation myths, early religions, histories of magic powered kingdoms which have risen and fallen over times, schools of different magical theory and practise, value judgements about how magic should be used and not used, cults, societies, empires, individuals. Is your world low fantasy or high fantasy, magic common place or rare, trusted or ostracized? Have parts or all of your world been blasted and destroyed by magic gone out of control - is society recovering from the equivalent of a magic holocaust or is there the coming of a prophesied Armageddon? Again, Unangband comes with a pre-built Tolkien based fantasy world that saved me having to extend much consideration here.

(It is worthwhile pointing out that by magic, I'm not just including the standard fantasy tropes. Any game mechanic that is not firmly grounded in the real world is in a similar position. This is why I'll be discussing Eve Online as much as World of Warcraft. The world of Eve is as much fantasy in the sense that the technologies and processes are as much a work of imagination as Harry Potter - we will never have a star drive and are unlikely ever as a species Homo sapiens to colonize another planet - even as close as Mars.)

As a game designer, this flavour is all important, but ultimately distracting. The history of the game world is important, but not as important as how the game plays. This should drive your design. An interesting narrative will ensure you game is played once, an interesting game design will ensure your game is played over and over again (Much as a well designed game beginning vs. a well designed end game). And it is this influence of magic on game play that I'll be addressing over this series.

More to come in part two.

Procedural Story Blocks

If you're interested in procedural content generation, you may want to read this interview of Eskil Steenburg by Jim Rossignol on Rock Paper Shotgun. Eskil discusses the concept of building a complex plot up from simple story blocks, much like you'd make sentences from magnetic poetry.