Wednesday, 31 March 2010

7+2=9?

Not long to go now...

Tuesday, 30 March 2010

7+2=9?

Keep guessing...

Monday, 29 March 2010

7+2=9?

Announcement coming shortly. Rampant speculation in the comments thread below.

Friday, 26 March 2010

Thursday, 25 March 2010

Wednesday, 24 March 2010

In memorium

The flags are flying at half mast today at Valve as they commiserate the resignation of South Australian Attorney-General Michael Atkinson. Luckily for some, they are also flying the Attorney-General's greatest legacy at half-price: the gore free, censored Australian edition of Left4Dead 2. Even this cheap, I'm not tempted by the artistically dismembered version Valve have been forced to sell down under.

Momento mori, Mr Atkinson, momento mori.

Sunday, 21 March 2010

V the Revolution

Parts of the blogosphere are abuzz with the news of the release of Civilisation V this year. I'm cautiously optimistic for a couple of reasons: that Firaxis are willing to trust the lead designer role to a relative novice to professional game development (but long time modder) Jon Shafer; and that what has been revealed of the design so far appears to be heavily influenced by Civilisation Revolution.

I periodically update my Civilisation Revolution house rules, so you may want to check back and have a look at the original article. The design is almost complete: I've solved the dilemma I had with allowing partial capture of cities by adding in an additional civic category (Philosophy) whose starting civic Superstitious prevents you from having your cities captured, and went from there. The inspiration for this is Norman Spinrad's Mexica, a novelisation of the conquest of the Aztecs which is well worth reading even if you're not a fan of historical novels. Cortez doesn't so much capture cities as bypass them to hold Moctezuma hostage.

In passing, I addressed a fundamental problem I had with Civilisation Revolution and the Democracy civic: a) it doesn't feel like how Democracy operates in real life - the myth of that democracies never go to war being part of the dark heart of America and b) once I choose Democracy in Civ Rev, I never consider another government civic. Democracy in these house rules becomes a slightly more historically accurate turtling strategy.

All that is left* is a balancing mechanism to make playing with less cities an effective strategy. I suspect this will end up being a culture boost of some kind, or perhaps making when your civilisation advances to the next age dependent on the inverse of the number of cities you have.

The other Civilisation news of the moment is summed up neatly in Soren Johnson's Fear and Loathing in Farmville where both sides of the argument have valid points. If you prefer the discussion in an audible form, the latest Three Moves Ahead podcast covers the same ground (Congratulations to them for reaching their first anniversary). Of the podcasts I listen to, Three Moves Ahead features the highest ratio of intelligent discussion to noise, mostly because its a relatively specialist area and features panelists with extensive knowledge of the strategy genre.

* With the minor exception of the fact I have no easy means of implementing these house rules. Civilisation in general has been strongly encouraging of modding with the notable exception of Civ Revolution. It theoretically should be simple enough to code from scratch - and there's at least one roguelike developer who's released a roguelike Civilisation game - or FreeCiv may be an easier path. The problem will be getting permission to release a game which is mostly designed by someone else.

Wednesday, 17 March 2010

The Quest for Quests: Part Seven (Enumeration 1)

You may want to start this series with part one, two, three, four, five or six.

What do we mean by failure in games? Let's start with a simple enumeration of the ways we can experience failure in a game.

The first is losing: a subset of all games - mostly those which are multi-player - are competitive and it is possible to win or lose such games (The rankings may be more sophisticated than the binary state, but assume for the moment that anything except coming first is a loss). Whether a player loses is defined by the rules of the game: this initially appears an important characteristic because most failures I'll be talking about are meta-game; that is fall outside of what would normally be considered part of the game.

But this lack of meta-game component is an incorrect assumption, because the game rules say nothing about the attributes of the players. Take a simple game, like rock, paper, scissors, where the rules are entirely proscribed and easily understood. In a single game of rock, paper, scissors against an opponent you have no other information about there is nothing outside game to influence your decision. But as soon as you play more than one game of rock, paper, scissors against the same opponent you have meta-game information: namely the history of your opponents decisions. It is entirely possible to gain significant advantage through analysis of these decisions - as well as any other information about the opponent - and there are a number of AI programming competitions for similar simple games which take advantage of this fact. In this instance, losing a single game can not be considered a failure, because the information derived from a loss can be used to improve the chance of successive wins.

Paradoxically, it is also possible to play two losing games alternately, and still end up winning overall (See this wikipedia article on Parrondo's paradox). So our intuition that losing in a game is equivalent to failure is incorrect for even simple games against another player.

Is it possible to lose against a computer opponent in the same sense that you can lose against another person? This is an important question, because if this is the case, it means we can lose in a single player game - the significance of which we'll look at later.

I'm going to use a simplified version of rock, paper, scissors to analyze this question: call it paper/shotgun. In this variant, we have two players, each of whom get to choose either paper or shotgun. If both make the same decision, player 1 wins - if the decision differs, player 2 wins. We'll encode paper as 0, and shotgun as 1, and then each player's decisions on successive games will resemble a binary string e.g. 001000111110...

Now if this binary string is perfectly random, there is no information that can be derived from the string - it's just noise. However, if the string is less than random - that is, there is information that can be derived because the string is compressible and an underlying set of rules is used to generate the string - then it is possible for one of the player's to derive the underlying system generating the other player's decisions and then start to win successive games. If player 1 is a set of rules, and player 2 is a perfect AI, then once the rules have been derived, player 2 will win consistently when it is possible to do so. If player 2 is less than a perfect AI - such as an actual human being, he may not be able to derive the rules perfectly, in which case successive plays can be used to refine the ruleset and improve the winning ratio.

Not there may still be random inputs to player 1's strategy, which prevent player 2 winning perfectly. But once player 2 has derived the underlying system of rules to player 1's choices, or has done so to the best of their capability, the game degenerates into application of the counter to the ruleset derived: it becomes a mechanical process.

This is the second failure in games: where player understanding of the game degenerates to a rote process which requires no analysis. Take tic, tac, toe. The entire game tree (the combination of all possible decisions) has been mapped and so any rational approach to playing the game is will result in a draw.

But people are not rational, which is why a game like tic, tac, toe still exists and is considered a game. You may choose to play it to explore the game tree and confirm that a draw is the logical outcome. You may choose to play against an opponent who is not aware of the correct decisions at each juncture of the tree, to prove your superior rationality, or to lose deliberately as a sop for their ego. On one level, people enjoy rote, mechanical processes because our brains are wired to enjoy a mix of novelty and mundane, as opposed to complete novelty the entire time - some pleasure in rote processes have enabled our ancestors to survive and evolve. The presence of grinding in so many games is testament to this.

Denigrating degenerate games and grinding is as much about game design snobbery as it is about the game itself. I dislike rule sets that result in degenerate game play, but I have to acknowledge that these games exist and are successful, and are an important part of many more sophisticated games. Organising your cards in Solium Infernum, clicklets in Bunni Game: How we First Met and kiting in Torchlit are all examples of mechanical processes which contribute to the feel of the game.

In the discussion so far, I have assumed that the player is capable of improving their ability to play the game as they play successive games or progress through successive decisions in a single game. That is not necessarily the case: and the third example of failure is failure to learn.

Failure to learn is about treating the game as a pedagogical instrument - a teaching device. In parts eight and nine, I'll be talking about how games teach, and more types of failure in games, and what other game designers and the wider world have been saying about failure.

Monday, 15 March 2010

In the firing line

The Unangband 0.6.4 final release is taking a long time to finish. The number of bugs appears to be multiplying and I'm stuck trying to tweak the line of fire algorithm so that it handles some not uncommon edge cases while avoiding breaking it completely.

The problem is that the line of fire algorithm must trace as permissive a path as possible between the source and target - permissive in the sense of avoiding to collide with walls when possible - while allowing for line of fire attacks which are intended to collide with walls e.g. stone to mud. The code I have is based on an earlier version of Sangband's line of fire algorithm. Updating it to the latest version doesn't work.

This is taking what spare time I have available at the moment.

Saturday, 13 March 2010

Question for Game Developer Conference attendees

Anyone at the GDC? I have a sneaking suspicion based on the increase in direct traffic that someone there mentioned the Procedural Content Generation wiki. It'd be good to know if there was a mention - even if it is just someone talking about procedural generation in general...

(And I'm going next year, come hell or high water. A single mention of fellow Australian Ben Abraham getting to sit down and chat to Clint Hocking was enough...)

Friday, 12 March 2010

Sirlin strikes back

Also David Sirlin's blog features some unmissable writing this week - his own coverage of GDC and more importantly pre-GDC, and someone else's compelling story.

A little wisdom

Amidst all the praise for Valve's marketing for Portal 2 there has been very little mention of the person I suspect strongly of being behind most of the hidden message concept. I realise that Valve has a strong tradition of shared creativity and responsibility and on one level it is unfair to single anyone out, but consider the following sequence of events:

1. Independent developer starts releasing messages to his fans using a mix of obscure encoding schemes which decrypt to text, images, programs and other codes.
2. The independent developer is hired by Valve.
3. Some time later, Valve starts a marketing campaign by releasing messages to their fans using a mix of obscure encoding schemes which decrypt to text, images, programs and other codes.

That independent developer is, of course, Adam Foster.

Thursday, 11 March 2010

When the infinite well-springs of the Internet run dry, and you wish to quench your thirst

There is an unfeasibly large number of roguelikes being developed this year for the 7 day roguelike challenge - 84 at last count.

For more coverage, see Temple of the Roguelike, TIGSource and rec.games.roguelike.development.

For everyone in their final coding hours, I wish you good luck and salute you!

Saturday, 6 March 2010

Unexplained absence

One of the things about heading off to visit friends in Martinique for two weeks for a long postponed holiday is that you can't just let your closest friends on the Internet know anymore. So I'd like to apologise for the unexplained absence and promise to renew a more regular service.