Friday, 28 January 2011

1. Much to my (lack of) surprise, a game where you can mix spells and hurt yourself with them plays really well.2. Reading the reviews so far, it sounds like I may have been moonlighting on the development while I slept...

Sunday, 23 January 2011

You are encouraged to read parts one, two and three of this article series, and are strongly encouraged to read the original Designing a Magic System series of articles if you have not already done so. It turns out I had this article sitting in draft for about six months, so some of the Team Fortress 2 figures are a little out of date.

One thing I've tried to play with in Unangband is alternative character development models to the standard RPG tropes: experience and levels. Not that you'd ever guess by playing the game which appears hugely focused on level increase through experience gained from killing monsters. But a high level character in any Angband variant is incredibly fragile without the equipment that they will have gained along the way, which makes Angband much more about the correct selection and management of discovered items in the inventory, than it is about level gain or monster slaying.

I want to talk about these details here - taking two specific progression designs from Unangband and give you the reasoning behind each of them; with specific regard to making the choices interesting.

The weakness of a lot of progression systems is that the choices are uninteresting. Take how most RPG skill systems work: where you buy skills from one or more talent trees using a pool of points which increases the longer you play the game. The choices in most of these systems are not exclusive, and instead merely become an ordering decision, that is, if you buy skill A, you can always buy skill B later on, and there is no difference ultimately in whether you choose A first or B first, provided you get both.

This problem is exacerbated in when the cost of skills deeper in the tree escalates - the Civilisation series of games being a good example - because you can skip buying one of the more expensive skills to effectively 'catch up' on all the cheaper skills you elected not to purchase previously.

The effect in both instances is that the characters end up being homogeneous midway through their progression - and only start to differentiate themselves at the higher level skills, instead of through out the talent tree.

You may argue that a particular system has skills which work in synergy, so that it is always worth picking skill ABCD in sequence, instead of EFGH, because the skills combined are worth more than e.g. ABGH. But in that instance, you're actually presenting less choice to the player, because ABGH users will be beaten by ABCD or EFGH users, so that despite having 8 skills in this example, there are only two real choices.

You may also argue that a particular system has pre-requisites so that to get skill C requires that you have learned skills A and B, E requires A and C, and so on, so that the skills at the tips of the tree are entirely dependent on which skills you have chosen earlier. But by using pre-requisites, you're again restricting the range of possible choices to only be meaningful at the tips of the talent tree, as opposed to choices further up the trunk.

There are several ways to avoid this. The first is by either using slots or sockets, so that the player can only choose a set number of skills to equip out of the possible talent trees. The inventory system in Angband is an example of using 22 slots to carry all possible discovered items, and the equipment system an example of using sockets to carry a single weapon, shield, amulet, light source, 2 rings and so on. A particular socket may hold weak, middle or powerful skills, so that you are forced to pick only one of the set of possible skills of each grade.

Take Team Fortress 2 as an example. At the time of writing, the sniper has 2 possible primary weapons, 3 secondary weapons, and 2 melee weapons. Using only 7 weapons, we have 12 possible sniper combinations because of the division of weapons into these 3 exclusive buckets. And if we could choose 3 items to carry, from 7 items total, there would be (7x6x5)/3! = 35 choices in all. Whereas a talent tree of 7 skills from, for example, 100 Rogues, would have at most 3 branches of up to 3 depth. Assuming a similar 3 selection limit, and approximating the possible choices by using a combinations with repetition counting approach, there can only be (5x4x3)/3! = 10 choices.

In general, if you have lots of skills and don't allow the player a large number of selections, you are better choosing a slot or socket approach. If you do allow a large number of selections, relative to the total number of skills available, the analysis of choices available in the talent tree by using a combinations with repetition approach breaks down, and you are instead limited by the depth of each talent tree which at best behaves like the slot approach. The socket approach has degenerate cases where the talent tree behaves better, but in general is far easier to design.

The second way to avoid this is with a sliding window approach, which is what I use in Unangband for developing abilities for familiars. A sliding window allows you at best only a subset of choices at any particular time, and periodically the window slides, so that early choices are no longer available, and later choices become available. With familiars, you can choose a new ability every two levels, and every four levels the window slides 10 abilities further on into the list of possible abilities. Since the window is also 10 abilities big (but in general does not have to be the same size as the slide distance), effectively you can choose 2 abilities out of 10 different abilities every four levels. This gives you approximately (10*9)^12 choices over the course of the game, at the cost of designing 120 different familiar abilities and putting them in an approximate order of power.

(I would hate to have to design talent trees containing 120 skills to give the same variety of choice.)

I could, of course, provide far more choices by allowing the player to pick from any of the 120 familiar abilities every time they advanced two levels (the slot approach), but aside from the game balance issues of allowing some high level monster abilities from the start, there is the real consideration that the human mind is limited in its ability to comprehend more than a limited set of choices, and breaks down its rational decision making process if presented with too much choice at once.

This limit also suggests an upper bound for the number of available talent trees to choose from, as well as the number of slots or sockets and the number of choices to be presented per socket. A lot of this is avoided in Angband because you only encounter so many items at once, and must discard choices that you've no room for in your inventory or equipment.

Monday, 10 January 2011

I'm going to take another brief pause in this somewhat interrupted article series to point out a dark tower on the horizon, wreathed in storm clouds, through which wretched things take wing. That is our ultimate destination: the tower of the end game. Before it, we must pass through two great lands: the first, a pile of haphazardly placed blocks of rock and earth, through which water and lava and sand spill, fall and lap; the second, the rolling hills and forests and villages filled with warring medieval kingdoms. You know these places as Dwarf Fortress (or perhaps Minecraft), and Mount & Blade, and both have 'solved' many of the problems of quests that I have highlighted so far.

(The perceptive of you may notice the glint of recent flash of steel, from a hardy duo trapped somewhere in the wilderness before you).

Within a few minutes of playing Mount & Blade, I could feel the tingle in my fingertips of a game that does everything right that I've been writing towards with this series. Trading system instead of fetch quests. Check. Constantly changing world governed by an underlying set of rules that changes the environment while you play. Check. A faction system instead of quest givers. Check. Metagame (conquer the kingdom) which sits above the primary game (Pirates! plus first person sword fighting). Emergent complexity, whatever that means. Check.

Regardless you do need some fixed content, otherwise everything ends up like the repetitive and dull wandering of Mount and Blade’s mid game.

That is because Minecraft, and Dwarf Fortress and Mount & Blade are all missing that one essential landmark of any great game: that dark tower of the endgame which you can see in the distance. I use the tower as a metaphor, but one of the greatest games, Half-Life 2, makes it literal, a beacon that you can see from almost anywhere inside and out City 17. Your endgame must cut through the moment like a dark stained blade, poisoning every decision the player makes with the final flaw 'what are the consequences'?

For many games, the path to the endgame is easy: Angband has stairs which lead only up to retreat, or down to advance, Mario is always moving to the right. The fight before the finish must be the crescendo. Games with fixed quest content end almost fitfully, because you have consumed all that they can deliver. Dwarf Fortress at least has that dull blade of finality 'Your dwarves have dug too deep.' that mercifully finishes off a fortress that groans with the fat of success, as opposed to the glorious bright eyed failures fallen before it.

The end game ironically is for the most part a given. The pieces you have moved into place, the choices and sacrifices that have built up to it usually come down to a single decision point or few and the best designed puzzle games leave resolution of success or failure to the last possible moment with all sides (in a multiplayer game) in contention as long as possible. Where the end game shines is not in the stalemate avoiding final dance, but in how its shadow is cast on mid game.

The mid game is where you are forced to implement your plans of how to win. In game where you are not faced by the infinite lego set of Minecraft, not everything is possible. There are time constraints, resource constraints, skill constraints, mutually exclusive decisions which force you to take a but not b, a battery of tests which wear down what resources you have available, wastage where your toil amounts to nothing, a slippery slope towards inevitability, set backs outside of your control, gateways through which you can pass one way only, entropy, a rising tide that pulls you in one direction, checkpoints which require minimum standards of you, irreversible decisions, stalemates, fatigue, failure states which trap you into restarting, or worse: mulligans, treadmills, grinds, false economies, exploits which encourage bad behaviour, fool's gold, mudflation, Garfield cards, bad designer prisons and gear reversals.

(To avoid linking to TV tropes and losing you, I'm forced to invent my own private lingo to lose you instead. A Garfield card is something that has the same cost as a clearly more useful item - therefore essentially useless. Reference is Magic: the Gathering's designer Richard Garfield who uses this technique. While I have disparaged it previously, I suspect, like many hill climbing algorithms, sometimes you need to move through low value points represented by Garfield cards to get to higher peaks. A bad designer prison is a part of the game where the rules are suddenly and artificially limited. Think of bosses who are immune to abilities you have used previously, for no good reason. A gear reversal is that point in the game where you are stripped of all equipment.)

Without an endgame, most of these are meaningless. To take one example: Chess defines a stalemate as a series of repeated moves and clearly enforces them. A series of repeated moves in Minecraft could be you admiring the same view each morning. You can 'do-over' a building by cutting down another mountain one valley along, but in chess, your mulligans are misconduct.

To be clear: I'm valuing what you might consider a certain kind of game, a certain kind of way of playing games, and a certain kind of player (more than 800,000 of them at last count) will never take issue with Minecraft's unlimited sandbox world. But games without endgames are much more limiting in terms of the types of play they support, and much more limiting in the types of players they satisfy, for all that they promise no limits.

To see why, consider a variant of Minecraft, which has an endgame: to build the highest tower of any player anywhere in the world, and new building block type governed by more sophisticated physics system which requires the player master it to build high above the clouds. Moreover, the ingredients required to build this tower are collected and limited by interaction with a linear narrative, but where you can get enough resources for sandbox play 'readily' if not right at the start (A certain part of the narrative may consist of tutorials to highlight techniques and physics interactions you may not have considered). We'll call this variant World of Goo.

World of Goo lets you participate in sandbox play as much as you desire, as well as more narrative driven play that Minecraft lacks, and which some people express a preference for which never could be fulfilled by Minecraft. In addition, a third type of player plays competitively, min-maxing their way through the narrative and resource acquisition phases to acquire as much of this tower building resource as possible. Another type of competitive player comes up with unique tower building techniques which require less pieces, or excels in specialist league maps, which try to build the towers with the most unique properties using a fixed number of resources.

There is one key decision that this hypothetical World of Goo makes that loses some potential players who are well-served by Minecraft: it limits the total amount of goo available. But the players it loses are only noncompetitive tower builders, who want to build towers over a certain height 'easily'. You could address this by making an unlimited tower building resource available that is distinct for goo, for which players can buy, or grind over time: call this resource hats. I'm not sure if the tower of hats model is the right approach, but it clearly is a popular direction to take.

All other builder types are well catered for by the sandbox that thought experiment World of Goo makes available, because only goo for towers is limited. And competitive tower builders are under served by Minecraft. In particular, Minecraft doesn't cater at all for (for want of a better term) Chinese mother tower builders - to paraphrase the linked article, tower builders whose limits can only be reached by rising to the rigors of strict competitive environments.

My argument is that Chinese mother tower builders are the reason your games need goo and endgame, not just bl0cks and sandboxes. The designers of many games could not possible anticipate the depth to which some games could be played whether they be Chess or Starcraft, and an endless sandbox cannot alone offer compelling enough a reason for a competitive community to emerge to explore these depths. There is one caveat: if the game has a big enough an audience, all things are possible. Team Fortress 2 has surf maps, Star Craft has maps with unlimited resources and Defence of the Ancients, Civilisation IV a menagerie of mods. But all of these examples have a strong end game component, and clearly defined goals, even if they have mutated beyond the intent of the original designers.

(Magnasanti being the artistic vision of one man shredding a game with concrete depth charges).

There's been some recent argument against and for forums as a medium of exchange between developers and their communities.

I decided against forums (in a tied poll) specifically for Unangband, on the basis there is already a well developed Angband forum community and I didn't want to splinter that base. I'd similarly not have the time committment for moderating an Ascii Dreams forum, but feel free to comment, or head over to Temple of the Roguelike for general roguelike development forum-ness.

I do have some thoughts on the issue, based solely on my recent experience trying to shepherd some changes through the TF2 beta process, but I'll leave these for another time. Instead, I'll offer up the best response I've seen to some of the needless rage and anger on community forums, from Chris King, the lead designer of Victoria 2:

You know I had to go and look at the Civfanatics forum to see how they were taking this new and my God there are some bitter people there. My favourite was as long as Jon stays away from Paradox I’ll be happy. With that in mind I would like to make the following public offer.

Jon, if you are reading this and if you do have some free time, would like to be our special guest programmer on the Hearts of Iron 3 patch?

Monday, 3 January 2011

For the fourth year running, there have been more roguelikes being written, played and voted for. Thanks to all 981 of you who voted this year - almost twice as many as last year. It's getting to the point where there are too many roguelikes for anyone to be able to sample them all, let alone give them the play time needed to explore their depths. I hope this list gives you the opportunity to play at least one roguelike you wouldn't have otherwise considered.

Dwarf Fortress is the 2007 winner, and recent development cycles have seen the roguelike Adventurer mode receive a lot more attention.

Rogue Survivor is a relatively new entry into the field with its first release in May 2010, but has quickly grown in popularity being featured on the Indie Games blog and Rock Paper Shotgun. It is a zombie outbreak survival sandbox game, with all the scavenging, barricade building and alliances with other survivors that entails.

Dungeon Crawl: Stone Soup has won once, and been a runner up once already, and continues to go from strength to strength. Version 0.7.1 was released July 2010 and continues to be developed day to day - undoubtedly the Crawl development team have started thinking about what version 1.0 must entail.

The links to Dungeon Crawl's resources have been updated, and the best place to start is the development blog.

I had written an obituary for ToME as a part of an article on how uncontrolled ambitions of developing a roguelike can ultimately cause the game to fall apart. Then there is the received wisdom that you should never ever rewrite your game from scratch, because you throw away all the learned knowledge embodied in the old code base. Then there are the design problems inherent in trying to build both a game engine, and an implementation of that engine, from an old code base which ultimately bogged down and halted development of ToME 3.0.

But DarkGod is irrepressible: with the words 'The board is set, the pieces are moving.' he unleashed the 3rd major iteration of a game that started as a variant of Zangband called PernAngband, changed its setting twice (to Middle Earth, and now a whole new fantasy world), but keeping his fans and development team intact and excited about his vision.

ToME: the Tales of Maj'Eyal to give its relatively new full name consists of a fantasy world designed from the ground up, but also a Lua based OpenGL game engine called T-Engine 4 that you can develop your own unique roguelike for. While the engine is in the early days of adoption, based on the number of roguelikes built on the earlier ToME engine versions, there will be plenty of modules coming out soon.