UnBrogue postmortem

This isn't an actual postmortem, because I've not finished with UnBrogue, but the 1.1 series of releases is coming towards a natural conclusion (with soon to be released 1.1.6 - assuming there are no further bugs requiring fixing that I can resolve in this branch) and I suspect there'll be a significant break between the 1.0/1.1 releases and 1.2 releases for reasons to be discussed.

UnBrogue started as a personal variant where I added and changed a few things that were annoying me, and then grew enough legs that it became worthwhile releasing for the 2012 Annual Roguelike Release Party (and which I deliberately kept under the radar prior to then). The main focus of the earliest release were about making plate armour and staffs of lightning bolts less of a no-brainer choice, making ogres more useful allies, and trying to increase the viability of a stealth game which I thought had potential but due to a dearth of rings of stealth in games I had been playing was something I hadn't experienced.

At a more meta level, I was curious to see whether I could incorporate some of the ideas I had been playing around after having played and fallen in love with the Binding of Isaac, a game which is particular "content-wide" in the sense that you will only encounter a small vertical slice of the possible content in the game in any one play through. Brogue has some of that width, but I wanted to see how much further and in what directions I could push it and still have a robust and interesting game.

What went right

1. Choosing a great game and code base to base it on.

Brogue is a great game of ideas to play around with, and a beautiful code base to write with. This ensured that when it came to development I was generally working at the coal face of working on new designs and ideas rather than having to worry about the back end framework. This is especially important for roguelikes which have a large number of complex systems with robust and interesting interactions; and in a hobbyist area where motivation is always a challenge, you want to maximise the amount of time you spend doing interesting things.

2. Not limiting myself to ideas that I could argue be reintroduced to the main game

This meant I could quite happily go and break the beauty of the code in search of new ideas. There is some pretty ugly additions to the code (Talismans of the Sinister Hand being the worst offence here), but I could quite happily add lots of stuff without worrying that I was adding a second (or third) set of flags to a particular data type, or that the elegance of the code was being diminished by bolting on a new way of doing things.

3. Spears and war pike redesign

The entire 1.0 branch pretty much failed to change the flavour of the game because while I added a lot of stuff, you only rarely encountered it (talismans) or found it useful (shields) - the changes to armour impact on stealth and enchantment impact on sneak attacks notwithstanding. Whereas, redesigning how spears and war pikes worked immediately made 1.1 much more interesting because you had a frequently occurring mechanic which worked significantly differently from the Brogue baseline. They were (and still are if you are on 1.1.3) a significant source of bugs, but the idea (which had to be modified prior to implementation because the original plan matched what Pender did with rapiers) is sound, makes sense as a game mechanic, and contrasts with the way other weapons work. The mace and warhammer changes helped here too.

4. Honouring the implementation of the Discoveries screen while changing the intent

The implicit contract in Brogue is that you are always given enough information as a first time player to be able to make intelligent decisions from a turn to turn basis. The Discoveries screen is a great example of this: you are told ahead of time what all the items could possibly be, which you can use as a source of making educated guesses about what specific item you're carrying. UnBrogue breaks this contract: there are staffs, wands and potions which are deliberately withheld from this screen, as well as whole classes of items (tomes, elixirs) which don't appear on it. But none of the items which are hidden from this screen can be both a) randomly found in the game and b) harmful to you (allies are fair game) except where c) staffs/wands of summoning which as a class are listed on the Discoveries screen, but which list of monsters can be summoned by these items is hidden information. Brogue went on to weaken this contract in the 1.7.x release with charms which are not listed on the Discoveries screen, but are always identified; of course, weapons and armor, and runics were never listed previously and could only be enumerated through repeat play.

5. The crafting system

I'm incredibly happy with the crafting implementation in UnBrogue which I have designed in such a way that it is possible to play 95% of games without even knowing it exists. Crafting ingredients are always useful items in themselves, because the ingredients are (almost) always other items: potions, scrolls and so on; and the method of combining them is as logical as I could make it. There are three methods of crafting in UnBrogue: a) fixed crafting locations which allow you to combine two existing items to make a new one, b) certain talismans which are only rarely available and c) potions of Winds. The crafting system also forced me to add lots of items: the vast majority of which are incredibly interesting in their own right because of the way Brogue's systems have been designed, while allowing these items to exist behind the wall of item placement - because they are not randomly placed, I could add as many as I want freely, while leaking them into the game in a process I hope feels like peeling back the torn edge of the wall paper to find a hidden treasury. I've changed this approach slightly in 1.1.4 and later, so that the majority of these items can be randomly generated, while reserving some as craft-only special creations. The only instances where the crafting locations require a non-functional ingredient allow me to use this non-functional ingredient as the bait in one of Brogue's machine rooms or one of the many rooms I added to support these.

6. Armor redesign and armor prefixes

While making stealth degrade as your armour improved made plate armour less of a no brainer, armour in UnBrogue was pretty flavourless and uninteresting, runics aside. This changed significantly in 1.1.4 in two ways: I redesigned the existing armour types to make them more distinct, including adding three leather armour variants, and dropping one intermediate armour type; and I added armour prefixes which gave various armour types new abilities which in many cases were just buffs or tweaks, or the equivalent of low strength runics but with drawbacks. I didn't want to overburden the armour identification mini-game, which is already the weakest of any identification routine, so I made armour prefixes obvious - this also meant I could add more flavour to them without affecting suspension of disbelief; and one of the leather armour variants, robes, is effectively automatically identified as being runic to make things even easier. Armour prefixes have been pretty much great from their initial introduction, bar one which is undergoing redesign, but the work I put into the leather armour variants was at risk of going to waste because so few games result in winners in leather. So I compensated by balancing them up by allowing scrolls of protect armour to buff them to the equivalent power level (give or take) of banded mail. This may have made every suit of armour too useful: but it is a risk I'm willing to take to make them more interesting.

7. Adding lots of the right stuff

1.1.4 seems to have hit the sweet spot for item generation so that there is sufficient variety for every single play through I've experienced: 1.1.6 is getting to a similar place for placement of machine rooms in the dungeon so there's enough variation from game to game (prior to this version, there's not enough different rooms early on). I'll just quickly enumerate how much stuff UnBrogue adds to the game: as of 1.1.6, I've added 12 autogenerators (flavoured blobs of terrain which gets added to the dungeon), 12 reward rooms and another 23 machine rooms (rooms which have puzzle type challenges in them) - I'm guessing all up roughly doubling the original figures, give or take, and this doesn't include modifications to 3 or 4 existing rooms - 12 monsters (of which only 2 appear as 'regular' monsters in the main game), 5 melee weapons, 9 missile weapons, 3 armours, 19 armour prefixes (new 'runic' type), 3 shields (new item category), 2 scrolls, 14 tomes (new item category), 5 potions, 21 elixirs (new item category), 7 wands or staffs of which staffs of summoning can summon 13 different monster types, 12 wand or staff runics (new runic type), 2 rings, 22 charms and 16 talismans. Having said that, other than talismans, autogenerators and reward and machine rooms, there's very little of which is truly original: I would say across all these items only marking, grappling and extinguishing darts, potions of Winds, staffs/wands of Nature, Telekinesis and Detonation and wand/staff runics bring new systems into play, and Nature and Detonation both riff on ideas which Pender originally introduced to Brogue (bloodwort plants and explosive mutations).

Next to UnAngband (where I added over 1000 monsters to vanilla Angband), these numbers pale into insignificance - but here they have far more impact. Even the humble potion of Water is incredibly useful - you can steal items from monsters, use it to make your escape or cover your scent, make a temporary bridge over lava, create a steam bath to kill something in; and more importantly, due to the finite constraint on resources that Brogue's core design entails, these actions can be life saving and even game winning. At the same time, items I added as an afterthought can become core to a play strategy: I recently almost ascended relying on a staff of Dead Man's Ear which creates a immobile and inactive monster which simply acts as a damage sponge, which more than doubled the combat capability of my single troll ally since it acted preferentially as a target while he engaged in melee (wiser players than I would have taken a direct path to the amulet of Yendor using my wand of Tunnelling instead of naively walking the long way around).

These successes are testament to the core Brogue design, but also the strengths of the roguelike genre: provided you play to those strengths as Joshua Day has written about previously. And it turns out that my central thesis: more variety is better appears to hold for the most part, even if the variety is 10 or more sets of 3 similar items with the same effect but with non-uniform activations. As it turns out, the most problematic parts of the game occur when I try to strike out further with new abilities, instead of tweak and iterate on existing systems.

And in the follow up article, I'll write about what went wrong and discuss in more detail some of the stuff I've implemented and hopefully come to some more robust conclusions.

CYA

While we're on a science fiction theme, I've started playing Deus Ex: Human Revolution and, hmmm...

Somewhere in me is a large, thoughtful article about how playing semi-sand box, RPG-lite, side quest focused collect-a-thons one after the other is destroying my ability to enjoy games. I don't want to be a vacuum cleaner who is ordered around from place to place with a GameFAQs article in one hand and the  threat of 'consequences' in a game I can never lose (except by making poorly informed choices in the skill tree). Instead I'll refer you to recent articles by Richard Terrell (part 1, part 2) and Keith Burgun (at Gamasutra), both of whom get too tangled up in the definition problem of what a game is, but whose basic thesis I agree with. Today is not that day.

Instead, I'll talk about the sixty seconds of fun I had in the prologue. This is the first cover based shooter I've played which uses hiding behind cover as the central mechanic (Red Faction: Guerilla doesn't have enough waist high walls to count). It took me a while to grok the mechanic, which primarily came down to getting the key bindings right, which for me is remapping F to jump, space bar to take cover, right-click to aim. But when I did, there was this amazing fluid joyous room-clearing experience I want to repeat. (Perhaps by not ever using that sentence again in the wrong context).

Can you suggest a PC cover based shooter that doesn't have everyone telling me I'm an asshole afterwards?

GDC coverage

If you are not at GDC, the best coverage I've seen this year is by David Sirlin. Day 0, day 1, day 2.

Diablo III pull quote

We want to drop a ton of items, but to really pull off a sense of excitement when finding a great item, there needs to be non-optimal items, both for your class, and in general.

Off to the Fortress

For some light reading, you may want to refer to the recent controversy of Dungeon Crawl Stone Soup removing mountain dwarves from the game.

Rage on RAGE

I hate to see a developer getting burned by speaking to the public frankly about the issues they experienced during development; but the sheer idiotic rage of PC fanbois when John Carmack stands up and speaks his mind has to be seen to be believed.

As far as I can tell, there are two (actually 3) problems with Rage:

1. Six years ago when they began developing the engine, Mr Carmack made an (incorrect) call that the PC was not going to be significantly more powerful than consoles when RAGE was released - which he has spoken about at length.

2. id was anticipating AMD would have a graphics card driver released prior to RAGE being released which had the correct OpenGL extensions and/or performance necessary to handle the code RAGE is using (and AMD did not - in fact they made things significantly worse by releasing some Battlefield 3 beta drivers which bundle an 'ancient' version of the OpenGL drivers).

Sure, John isn't helping things with making public statements prone to misinterpretation, but he's staying consistently on message about this.

The third problem is the technology itself. The megatexture technology uses virtual texturing, in a similar way that the processes on your computer uses virtual memory, so that the actual texture can be much larger than what the graphics card can fit in its memory - with megatexturing it is in the 10s of GBs on disk. Reading some of the patch and graphics tweaks notes, it is also compressed, with both the GPU and CPU tasked with decompressing the texture on the fly with preference given to maintaining 60 FPS. What this means in practice is that you cannot compare your computer's performance running RAGE, to any other game that you've played (even ignoring the additional complication that id is pretty much the only company to use OpenGL instead of DirectX drivers).

The reason boils down to what parts of the computer are getting stressed enough to become a bottleneck. In a traditional game, levels are hand designed so that textures can be loaded (relatively) far in advance, so that the disk performance is almost never an issue - it is occasionally, because you get pop-in - typically at a scene start, but that may as much of an issue with the I/O bandwidth between main memory and the graphics card as between disk and main memory. With RAGE, every part of the computer becomes a potential performance problem - disk, disk cache latency, I/O between disk and main memory, CPU, GPU, I/O between main memory and CPU cache, CPU cache misses, I/O between GPU and main memory and/or CPU cache, GPU memory, other processes running on the system etc. It is highly likely that you have something slowly down one of the areas I've listed that you're not aware of, and a system which stresses all of these will only run as well as the slowest part. To take one example: if you've got a relatively full non-SSD drive before you installed RAGE, not only will you have disk fragmentation, but the files will be written to part of the disk which rotates slower under the drive head, which means that the data will be read from the drive slower.

(The consoles have a significant advantage here, because everything except the game can get out of the way - for instance, you are not running anti-virus software on your Xbox 360 or PS3; and the developers can write to 'bare metal' bypassing the abstraction layer required to support multiple graphics cards.)

So what possible reason could id have with going with such a high-risk design? Well, I'm guessing for much the same reason that every operating system now uses virtual memory - it incredibly simplifies the process of development. Under older memory management systems, such as OS X 9's segmented memory model, and (heaven forbid) DOS's flat memory model, you had to worry about a whole lot more variables: such as the maximum amount of memory you could be allocated at one time, whether that memory was 'near' or 'far', whether another program was attempting to access the same memory, and so on. With virtual memory, memory is always yours, flat and you can effectively have as much as you want (within the limits of the address space) provided you don't try to access all of it at once - the operating system handles the underlying details (relatively) transparently.

With megatexturing (and other virtual texturing methods) you don't have to worry about a texture budget for each discrete level: you just go ahead and design whatever you want, and the underlying engine will handle all the loading and unloading of the parts of the texture that are within (or close to) the actual field of view.

If you've been following John Carmack's public statements in the lead up to RAGE's launch, and have enough understanding of how computers work, none of the above should be a surprise to you.

Equally which, if you have enough of an understanding how people work, none of the subsequent overreaction should be much of a surprise to you either. But the subsequent un-PR-filtered statements by Mr Carmack are doing nothing but add to this overreaction. Which is unfortunate in the extreme, because from all appearances, the technology is the right approach to solving the issue*. Almost as unfortunate as Zenimax' decision not to license it, and likely prohibition on releasing it as open source at some point in the distant future.

*Except that apparently ray tracing is.

Importing save files

It doesn't happen much (at all?) these days, but more games should support importing the save file from an entirely different game.

Early on in Unangband's development history, I supported important vanilla Angband character saves: the game was initially - and arguably still is - an Angband + cool stuff variant. Since then, the two save file formats have undoubtedly diverged, but I'm still tempted to redo this functionality.

Here's a chart of some games which did support this functionality.

Historium: A Concise History of A World

You may remember a blog post about some 'house rules' I put together for Civilisation Revolution... umm. I've spent a little more time working on them.

210+ page PDF.  TeX source. PNG tech tree. GraphViz source for the tech tree.

I have it on good authority that this isn't how you design a game.

(Doing this just reinforces in my mind how awkward it is to design a tech tree, and how clumsy a game mechanism it is).

[Edit: Version 0.2 is up. This is final unless a) there's stuff people want clarified or b) I realise I forgot to put something else in].

[Edit 2: Version 0.3 is up, which fixes refugees - see change log for details. Thanks to Tom for feedback and suggestions regarding Conscription and Professional doctrine changes].

[Edit 3: Version 0.4 is up. Change log.]

[Edit 4: Version 0.5 is up. Change log.]

[Edit 5: Version 0.7 is up. Change log. Change log for version 0.6.]

[Edit 6: Version 0.8 is up. Change log.]

[Edit 7: Version 0.9 is up. Change log.]

[Edit 8: Somehow got up to version 1.6. Renamed from Alternal to Historium, for a variety of reasons]

Is user interface design holding roguelikes back?

I've been playing the excellent Cardinal Quest by Ido Yehieli and I can't recommend it strongly enough. You can download the demo from links at his site, read the IndieGames.com article about it and there's a great interview with Ido at True PC Gaming which outlines some of the challenges in designing an indie game.

While Cardinal Quest doesn't necessarily have the depth of some roguelikes - and isn't intended to, it has one outstanding feature, which I also praised Terraria for: amazing user interface design. Here's the first screen you see once you choose which class you'll play (click to see full size):
The user interface entirely describes what you can do in the game. There are keyboard shortcuts for every function you need to do but you don't need to look up help menus: everything is discoverable by mousing over it and a small pop-up reminds you of the key to use, as well as describing the item in the slot.

Not only that, but whenever you pick up an item, it automatically is placed in the correct slot if it is better than what you're already using, replacing any existing item which is converted to gold.

And perhaps best of all, the spell system has separate time outs on each spell, which are displayed by a clock ticking down effect which slowly highlights a slice of the spell icon as the spell recharges.

The user interface is so good, it has seriously forced me to reconsider my priorities in Unangband. I typically find other (non-Angband variant) roguelikes impenetrable because of the subtle but important differences in keyboard shortcuts which means I can't easily shift between games. But I had no problems at all with Cardinal Quest, I could start playing straight away and enjoy the progression of my little avatar (Down to level 8 first time).

With this and the success of Dungeons of Dredmor, I wonder how much the lack of attention to user interface typical of hobbyist and indie programmers has been holding roguelikes back. It's not just that of course: the verb-object model of using items - which has important properties for emergence - and the large number of items in a typical roguelike are also important, but most of those could be overcome by a smart redesign. I'm thinking about going through this process myself.

Old school

I'm starting to think about adding hirelings (aka henchmen) to Unangband, inspired in part by the number of old school D&D blogs which I'm reading. Unangband already has a relatively sophisticated friendly AI, which is used for your familiar, charmed and summoned monsters, monsters you bribe successfully or who surrender to you, as well as the several zones which feature a friendly army spawning alongside you (such as the Battle of Five Armies) - but most of these are specific to spell casters, so it'd be good to give non-spell casting players the opportunity to play the game with friendly monsters alongside them.

There are several issues I'll have to iron out first. The main one is I have to verify that the monster levelling code actually works: that is the adjectives that monsters get ('young, adult, mature, old') as they appear deeper in the dungeon correctly adjusts the monster power to fit the power curve for the depth the monster appears in the dungeon. At the moment, this is a bit of a hack and to clean it up will require some more large scale code changes which I'm a little hesitant in making, seeing as I've still not finished the last set of large scale changes required for items.

There's also the problem of moving your allies between levels, but that's mostly a technical problem and one I need to solve anyway.

The other issue is how do I naturally have non-spell casting characters have an easier time of recruiting and retaining hirelings and henchmen than spell casters? There's no point adding recruitable monsters (and in Angband terminology a monster is anyone who is not the player, so a Novice Priest is a monster) if spell casters have as easy a time with this as non-spell casters.

I suspect I'm going to end up with a hireling morale value - how cheap it is to hire, how loyal are people to you and how long do your henchmen stay with you - that is influenced by three factors: reward, respect and fear.

Reward is straight forward: how much loot (and experience) do you give to your hires?

Respect increases with how much danger you put yourself in, compared to your underlings. Going toe-to-toe in melee will generate the highest respect, which is the first way non-spell casting characters will have an easier time with henchmen and hirelings. But this only benefits melee specialists, not thrown weapons specialists or archers.

Fear inversely effects some interactions: if you are feared, people will obey you more readily, but you lose long term loyalty - which increases the cost of recruiting and reduces the length of the hire.

Fear is going to be slightly trickier to define, but given my requirements above, I'll base fear on the following metric:

Fear is increased when you use ranged magical abilities, as long as the henchmen cannot use the ability themselves, and is not immune to the ability.

So if you cast charm person a lot, you'll drive away henchmen who can be charmed by you; if you want to use a lot of fire magic, hire minions who are immune to fire, and so on. Summoning spells increase fear regardless.

It may make more sense to label this stat superstition - it encapsulates the kind of uncomfortable position most hirelings would find themselves in working for a wizard.

[Edit to add: Archers (and thieves) don't generate fear at all (since they don't use magic), which means that the reward contribution is not downgraded by the negative effects of fear. Essentially they are able to recruit without restriction as long as they generate rewards, where a spell caster has to be careful with their recruits because he/she risks alienating them through fear.]

Drawbacks

I'm fascinated by the idea of stats which have no maxima.

By this I mean that any value along the stat range has advantages and disadvantages. I've done this ever so slightly for the Size stat in Unangband, where increasing Size lowers your Agility, but this is too easily overcome (by having high Strength) and to make it more significant would require a redesign of the whole class and stat system.

A clearer example of this is the Body Type characteristic in Brink. In that game, you can have either a character with high hit points and the widest selection of weapons, but moves slowly and unable to climb obstacles effectively (the Heavy body type) or a character with lower hit points, much more restricted weapons, but high speed and maximum movement choices (the Light body type) or one in between.

Now you can simulate a stat system with no maxima by having a fixed number of stat points you can allocate to various stats, and provide no way of increasing the number of stat points you have. There are three problems with this: two obvious and one subtle.

The first obvious problem is the fallacy of stat equivalence: that is, increasing your strength stat by one point is equal to increasing your intelligence by one. In a system with stats with no maxima, you have to explicitly balance the drawback with the advantage; in a system with a fixed pool of stat points, you loss the ability to have improvements on a bell curve or inverse bell curve, as people will inevitably min-max by dropping points from stats near the middle range to pump one or more stats into the interesting edges of the curve (or vice versa).

The second obvious problem is psychological: people are not good at moving numbers around multiple stats, but when you make explicit trade offs instead of implicit ones, they are much more able to make correct decisions instead of vascillating between multiple seemingly unimportant choices.

A more subtle problem is that you miss out on systems which have interesting but hard to define drawbacks: an example of which is the Luck stat. Having a high luck means you get the widest variation of dice rolls against you (good and bad), having a low luck means you get fixed results every time. Having a low luck and therefore low variation emphasises skill (think TF2 servers with no randcrits and no damage spread), having a high luck means you occasionally overcome overwhelming odds (and therefore have more chance of having fun), but also can perform below par.

Now the question I have, is it possible to design a system in which you have every player characteristic defined by stats with no maxima?

The first example I can think of is Belief. If you have high Belief, you have powerful spell casting abilities, but are also vulnerable to magic being used against you; if you have low Belief, you are highly resistant to magical effects applying against you, but are unable to use magical effects reliably.

Any suggestions for other stats which could operate this way?

All fired up: part two

jdunson brings up a really interesting point in the original All Fired Up post:

Something like an "Aura of Flame" might well be a multiplier; "Increases all flame damage by +200%". Some cases might provide base damage as well, some not.

I had been thinking along similar lines about a number of related effects. Now I have a flexible way of representing multiple scalars (pvals) on an object in Unangband, I'm inspired to immediately extend the types of bonuses that can be represented.

I've already included context specific combat bonuses: to-hit, damage, number of blows/shots, damage multipliers, range; for melee, ranged weapons, throwing, traps, unarmed combat. This addresses the design problem I outlined in Throwabow: if you throw a bow with a high damage bonus, do you inflict the extra damage?

(Aside: I can immediately see from the above, that I need to include context specific damage dice and sides).

What other interesting bonuses are there?

jdunson's 'boost all fire damage by 200%' suggestion is actually more complicated than it initially appears, because of the number of different ways fire damage can occur - as I outline in Different Ways of Killing. There's weapons, spells, magic items (rods, staffs, wands), thrown oil and fiery potions. Do I also boost damage from a flask of oil (or another fire damage source) set in a trap? Does the bonus boost allies fire damage (which in Unangband is treated as equivalent to damage from the player)?

And for effects, such as spells, which persist over time, does the damage boost still apply if the item is removed?

For those bothered by my repeated mention of Team Fortress 2, the way damage effects apply there is another excellent example of unintended consequences of any of the above decisions. At the moment, TF2 has an example of a damage nerf (the Detonator) which is a secondary weapon which only does +35% damage against burning opponents, unlike the weapon it is based on (the Flaregun) which does +200% damage in the same situation. However, if you switch away from the Detonator before the projectile hits, the game no longer applies the nerf, and so you get the full +200% bonus. TF2's history of bug fixes is littered with this kind of interaction (damage bonuses against aerial opponents if they are merely standing on stairs and so on).

So I believe I'm better off by focusing on the context of the damage bonus, and then designing weapons which list the possible related contexts. To take an example: I could add boosts to casting spells by increasing the effective level of the player casting the spells, the effective level of the player when learning spells (which makes more spells available), the failure rate of spells and the casting cost of spells. In addition to a general boost, I could also add spell book specific boosts. A sword of fire would then list each of the above boosts which regards to the fire spell books, along with the relative minimum and maximum values; and when randomly generating a sword of fire item, specific values are chosen.

This does become a problem for the player to compare weapons - which is already a major issue, but hopefully the bonuses are going to be concrete enough to make a comparison (Do I want to be able to cast fireballs, or get an extra +x1 damage multiplier?).

Dear Dan

You've got everyone around here hot under the collar with your think piece on game criticism - not because it is inaccurate, but because you've stumbled across a truth that most people don't like to talk about ("most game criticism isn't very good"). The problem is that you've completely misattributed the cause ("game criticism isn't written by game developers").

Roger Ebert is a great film critic not because as you point out he made films. He's a great film critic because he's been able to devote a large proportion of his life to learning, thinking and writing about film. He's been able to do that, because there is enough of a financial reward for him to do so - there's enough money to be made being a film critic - not just for Roger Ebert, but for hundreds of wannabe film critics around at the start of his career who could justify devoting their every waking moment to film criticism.

There is simply not enough time and reward for being a game critic for us to have the same quality of game criticism at the moment. Partly this is because (computer) game design is in its relative infancy, but mostly because of unique challenges of making money writing criticism, especially in the game industry, at this point in time.

You may have noticed that the mainstream press is having a hard time remaining financially viable in the age of the Internet. Academia has also been under sustained assault for some 30 years with funding (in the United States) at a low point since the 1970s. These two avenues are the traditional methods for critics to learn their skills while being able to put food on the table - and neither of which are in the healthiest state at the moment.

Not only this, but the specialist gaming press is under direct attack by the largest game publishers. And, unlike film, the challenge of game reviews require that games be reviewed as a product, as well as a piece of art - Mr Ebert is unlikely to have to respool a film when he goes to watch it - which means that the game press is dependent on game publishers in a way that film, art, literature and so on are not. Not to mention the logistics of reviewing a product in a timely fashion which could potentially be played for hundreds of hours.

You may think I'm conflating reviews with criticism. I'm not. But one way you start developing critical skills is by reviewing games, lots of games, and the specialist game press is the only avenue which will pay you a living wage to do so - and potentially not for very much longer.

The economic reality of trying to be a game critic is also why a large number of the recent leading lights in game criticism have decided to change the field they write in or started working for the tabloids of the game industry or been co-opted by the industry as developers, publicists, designers.

So what's wrong with your vision of game developers being the only people to write about games?

I'll take one example: the Playdom piece you linked to about redesigning a social game makes a reference in passing to 'whales' or high spending customers. Let's make the hypothetical assumption for the moment that whales are in fact problem gam(bl)ers. I'm picking this example because I've written to you before on the cross over of gaming and gambling addiction. Not that there is anything in the article to suggest this is the case.

A game developer will never reveal that whales are problem gamers, because he is bound by confidentiality agreements between him and his customers as well as commercial interests to keep exploiting - that is making money - for the company, and should this inconvenient fact be revealed, he is opening the company up to the possibility of litigation or legislation.

A game journalist may act on an anonymous tip off however, and end up writing a piece on games which makes the analogy between watching a 'whale' playing Farmville and visiting a local casino and sitting next to the customers at a slot machines.

An academic may get funding for a study which begins to establish a link between playing social games and problem gambling, which warrants further study.

The actions of the journalist and the academic may result in real change: for instance, the FBI deciding there is no difference between putting $10 on a hand of cards, and buying a virtual chest; while a game critic merely makes a persuasive case for change. But a game critic has a chance of changing someone's view of the world, whereas the type of writing you're asking for can only change someone's view of how they design games.

I do hope there is a positive outcome from what you've written: the game critical community not just looking towards developers to make gaming's Citizen Kane, but figuring out themselves how to make gaming's Roger Ebert. But there is a lot of work to be done to make such a beast, and you can help more by pressuring publishers to give free and unhindered access to games journalists, than criticising game critics for not being you.

Can you copyright a game?

This has come up several times in recent months, with instances such as an iOS clone of Desktop Dungeons and the Sega clone of Splosion Man, and represents in my opinion an unfortunate part of maturation of our industry.

The latest contribution to this small but growing debate is a podcast at Three Moves Ahead discussing another instance of an iOS game cloning a game available on another platform. You can skip the podcast and read Bill Abner’s original No High Scores story, and the interview which is referred to frequently in the episode. While the discussion is interesting, I kept thinking they are missing the one central question: Are the rules to a game copyrightable at all? Or is it like a recipe, or fashion, which cannot be copyrighted? See e.g. http://www.copyright.gov/fls/fl122.html

As a game designer, I’d prefer the situation where a ‘game’ is not copyrightable, because the level of protection is already sufficient for the art, computer code and fiction incorporated into the game, and trade mark protection for the name and mark on the game.

The total economic contribution by movies, literature and music is dwarfed by contribution by food and fashion.

Designing a Magic System Redux - Part Four (Pick any two)

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've discussed previously the differences between skills and classes, and some of the general disadvantages of each approach. I've also gone into detail about how to design a magic system, and how it may be worthwhile looking at differing systems of progression, without going into detail about the implementation details.

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.

Designing a Magic System Redux - Part Two (Status Effects continued)

You should read part one of this article, and are strongly encouraged to read the original Designing a Magic System series of articles if you have not already done so.

There is an asymmetry in the design of status effects in Angband: they differ (sometimes significantly) in implementation between the player and monsters. But I've aspired in Unangband to reduce the asymmetry between the two where possible so I'll begin discussing the impact status effects they have on the player and briefly note into the differences between the player and the monster at the end of the article.

There is also a difference between the original Angband, and Unangband implementation of status effects, where Unangband has more possible states, but compensates by weakening the impact of the original Angband effects. The primary approach I've taken is to make it harder to add additional time to a status effect once the player is already affected by it - to avoid continuous locks. I've also modified the effect where noted below with the intention of making it easier for the player to continue to act when partially impaired without requiring they immediately reach for a reset of the effect.

Blindness was the example I looked at in the first part of this article: a player who is blind has a significant penalty to hit when attacking and cannot read scrolls or cast spells - presumably being unable to read the words from the spell book. In addition, the player stops getting screen updates - so that they are not able to see the current location of enemies or changes in surrounding terrain. My intention in Unangband is to weaken the blindness effect slightly, so that you can cast a spell once, from memory, while you are blind, before forgetting it. This is a shout out to my AD&D 2nd edition roots, as well as a way of allowing the player to sneak around in the dark and still cast spells.

Amnesia in Angband has been changed to a timed effect, based on Unangband's implementation, so that you suffer a penalty to your chance to cast spells. Unangband also prevents you from activating artifacts and other items - it makes you temporarily forget you have identified them - and when blind, will stop you from casting spells at all. (At the moment Unangband stops you from casting at all while merely amnesiac, but I'm changing to closer match Angband in the next version).

Confusion in Angband prevents you from spell casting, as well as causing you to move and shoot in a random direction instead of the intended direction. I weakened this effect in Unangband so that you can cast spells while confused - because the random target selection effect when combined with the ability to hurt yourself with spells makes for an interesting risk vs. reward trade off - and also made confusion only having a percentage chance of taking effect which increases as you become more confused.

Fear prevents you from fighting monsters in melee - you refuse to attack anything that you bump into. This is meant to encourage the player to flee, but it instead merely forces you to switch to missile weapons or spells, which there is no penalty to use even at point blank range. To compensate for this, I'm adding an additional terror effect, which acts as an 'overflow' to fear. Once you become sufficiently afraid, any fear will overflow into the terror status. While you are terrified, you cannot use any ability which requires aiming - including spells, missile or thrown weapons. You are still able to use other abilities, amongst them the various teleport effects you should be considering to escape with.

I've taken advantage of multiple meanings, to provide an alternative overflow from fear: that of petrification. Petrification status prevents you from moving (although you may teleport still), and has no other effect - although most direct petrification attacks are highly damaging as well. It is possible in Unangband to become petrified with fear, in the same way that terror overflows - and the two different types of overflow are exclusive: you'll either become terrified or petrified if you are made highly afraid, not both.

Paralyzation is the most uninteresting status effect: you simply cannot do anything while paralyzed, and so it is incredibly hard to balance and puts the player at the highest risk of getting a lock. Unangband has a second, more interesting variation: stasis - which paralyzes you, but also makes you invulnerable to damage, which is a side effect of time attacks. Stun deserves mention here because it incrementally penalizes you to the point of knocking you out, an identical result as paralyzation, but the initial penalty is very slight. Both paralyzation and stun are less interesting than the status effects I've already mentioned, because you either perfectly resistant or are in incredible danger should you encounter a monster (or worse group of monsters) which inflict this effect, with very little margin in between. To mitigate paralyzation, I use the slow effect as an intermediate step, with you being slowed before you are paralyzed the majority of the time.

Using the above combination of effects, you can chart the impact on the player's abilities as follows:
You might be tempted to add, for example, a Nausea effect to the above chart, which prevents you from using potions. But I'd discourage this: potions are best kept as the get out clause reset for any effect. It is still possible to partially incapacitate yourself through bloating by stuffing yourself with food and drink, for which a potion of Salt Water is a useful antidote.

You'll also notice Daze in the chart, which I haven't provided an explanation for yet. Daze will be new to Unangband in the next release: it prevents the caster from casting spells on himself and is the direct inverse of Terror, but for only spell casting and (perhaps) magical devices. Daze is interesting because it forces you to use spell attacks which are hampered, or my preferred terminology, made more interesting by blindness and confusion. To complement this, both Confusion and Blindness overflow into Daze, and there is no direct way of a player being dazed by an attack.

Of the effects in the above chart, only petrification, fear, blindness and amnesia of themselves totally incapacitate some ability of the player. The remainder only incapacitate in combination, or as a result of another status effect being repeatedly applied to the point where it 'overflows' into a more dangerous status (Terror and Daze cannot be directly applied to the player). The idea here is the player should get some opportunity to use a reset to avoid incapacitation, with a large margin of error before the more dangerous state occurs.

There are in fact 32 status effects which can negatively effect you in Unangband: of those I've not mentioned, the remainder are either debuffs (stat modifiers), change the rules monsters use to track you (aggravation, stench) or damage over time effects (poison, cuts) and so don't need result in the complete incapacitation which causes a lock. There a Soaked effect which prevents you from lighting fires or reloading firearms, and a Berserk effect which allows you to voluntarily give up missile and magic attacks in return for improved melee, healing and immunity to fear but both of these will have minor impact compared to those I've discussed in depth.

There are two exceptions: Sleep and Hallucination.

Sleep is one of those spells from AD&D which I cast into the same problematic category as Magic Missile. It was a 1st level spell which either fails or immediately and completely incapacitates with no in between. Sure, you can increase the level casting requirements and have the victim wake when attacked instead of being able to deliver a coup-de-gras, but the ability to completely disable an opponent and escape means the spell has to be made effectively useless against any opponent you'd want to use it against. Sleep works great in a role playing game which is strong on the capture and interrogate dynamic: not so for computer games.

Angband sidesteps Sleep effects against the player completely in favour of paralyzation, which is less a solution and more a tactic acknowledgment of the scope of the problem. Unangband separates them: and gives the player a cool down before falling asleep, which you can cleverly use to damage yourself to stay awake. Should you keep damaging yourself for the duration of the sleep spell, you'll avoid the effect completely.

Hallucination is a fun trick with ASCII graphics, but has little functional difference, and a lot of overlap with the confusion effect. Unangband already has enough restrictions on spell casting to make it worthwhile having hallucination stop spell use as well. But the Nightmare on Elm St of sleep started to get me thinking about what hallucination should do.

Sorcerers in Unangband don't have the range of options that the other major spell casting classes do. I've tried to remedy this by letting them make magical traps, but this both lessens the utility of actual trap setting, and requires enough horrendous hackery that I'm forced to reconsider. Sorcerers can shape change, and charm, and like druids have a minor in summoning spells, but I've come to realize that status effects should be the sorcerer's forte. But blinding and confusing and dazing monsters leaves two problems for me to wrestle with: firstly ensuring that the time required to get a lock on a monster is approximately the same as killing it, and making clear the victory conditions for doing so.

I will be reusing the surrender code to allow monsters to gracefully give up to the sorcerer: but it is more difficult to decide when this should occur. With hit points, we have a clear definition: when the monster is near death. With status effects, I have to define more clearly how to get a lock.

Take the following chart:

This is the status effects I've described previously, excluding effects that disable all a monster's abilities, with arrows used to indicate where one status effect overflows to another, and where abilities accumulate together to provide a 'higher level' result. I've added one additional overflow: confusion also can also overflow to hallucination - which will be important later.

If a monster is both frightened and petrified, it is considered in a melee attack lock. It cannot provide any kind of melee threat to the player, and if it is only capable of melee, it provides no further threat to the player until it recovers from either effect. Similarly, terror provides a ranged attack lock by itself, where ranged attacks are either shooting or breath weapons, and either amnesia and blindness, or terror and dazed effects provide a spell casting lock. A monster will surrender if it has all its abilities (melee, ranged, spell casting) locked for sufficient time and it has no allies in line of sight which are also not incapacitated. If a monster doesn't have one set of abilities it is is easier to lock.

In this way, aiming for a status lock is a broad attack in that you have to apply multiple different effects to a single monster for it to be defeated, whereas damaging attacks are deep in that once you find the vulnerability, you repeatedly exploit it with the same attack.

Also note that if the monster is immune to a particular status effect it is also harder to get into a lock: for instance monsters which are immune to fear cannot be melee or ranged locked unless it is possible to directly apply petrification or terror. Ideally there should be multiple paths to achieve each lock, so that a monster which is immune to a single type of status lock can still be affected by applying another combination of status effects. I am tempted to make the hallucination effect also prevent ranged attacks - another alternative would be to make confusion plus blindness effectively act as a ranged attack lock, because a blind and confused monster is unlikely to be able to use any ranged attack effectively.

But even if I make hallucination prevent ranged attacks, it still feels like the unwanted step child of status effects. Luckily, I've come up with a fevered dream of a solution that should give Sorcerer's yet another way of attacking monsters with status effects.

What is missing from Unangband is the ability to create illusions - something a Sorcerer class should excel at. There's a number of ways to implement illusions: you can have monsters which disappear when attacked, mirror images of the Sorcerer which disappear when attacked... all in all, a little ineffectual.

But what if you allowed illusions to cause real damage while the target was affected by particular status effects: I'm thinking specifically of while sleeping. That way you could have illusions interact with real monster resistances so that if you tried to burn a monster with illusory fire which is normally immune to that effect, it notices and wakes up, whereas you could damage it while asleep and have it remain asleep if it succumbs to the illusion. The incentive here is for the Sorcerer to attack monsters as they asleep, but have to periodically force them back to sleep as they are awoken by the illusory effects you cast at them. Pure damage could be represented by the Sorcerer's existing mental attack abilities, which would cause double damage to sleeping monsters whereas the various illusory elemental attacks would require the illusionist play by the same rules as regular spell casters.

And in this scheme, the hallucinating status effect would similarly allow you to affect monsters with illusions while they are awake. The advantage to hallucination is the sleep effect has a time delay before the monster succumbs, whereas hallucinations take effect instantly.

This is followed by part three which looks at magic items in more detail.

Design A Magic System Redux - Part One (Status Effects)

In the original Designing a Magic System series of articles, I briefly looked at status effects as a way of separately out various incapacitation effects from hit points. Antoine's suggestion of an Enchanter class in Angband has forced me to take a closer look: both to justify my intuition that an Enchanter class would be inherently uninteresting, and set myself the challenge of trying to make this class, or the Sorcerer equivalent in Unangband, an interesting play style. Luckily I'm in the midst of implementing a whole host of new status effects in Unangband, so I'll be able to benefit from this design exercise as well as give you some insight into the decisions I've made.

My original thesis in Designing a Magic System was hit points are a good design compromise between a tug of war between two sides, which could result in games which never resulted in a victory condition, and incapacitating damage which would result in a negative feedback loop where the player could lose the game without being dead.

In this model, status effects become an idealized way of representing various types of incapacitation without being directly linked to hit points. Status effects are almost always timed, to allow the ability limited by the status effect to recover naturally should the player survive long enough, and can be recovered from using a variety of resets. It is important when designing status effects that it is not possible to get a lock on the player, but you can intentionally design traps, which are best suited to multi-player games, to allow a player to get a significant advantage by applying a lock, but at increased risk should the opponent predict that they are attempting this technique.

(If you are not familiar with locks and traps, I recommend that you refer to the original articles).

The canonical example of a status effect is the interrupt - this interrupts whatever the other player is doing and forces them to start again. If the interrupt takes less time than whichever action the other player is attempting, you can keep your opponent constantly interrupted - and if you start your interrupt action before they do, you can get a lock on the other player by interrupting their attempts to interrupt you. If the game has an action which takes less time than an interrupt, but does much less damage than the standard action, you can create a trap: the other player may attempt a standard attack for a lot of damage, but be at risk of your interrupts, or use the weak attack to avoid being interrupted, which exposes them to your standard attack. The trap in this example is only interesting if the other player is a human opponent: because it forces you to build a model of what the other player is thinking - in effect, to second guess them.

The interrupt as a status effect can be problematic for two reasons: the interrupt can be constantly applied if the duration of the interrupt is longer than the time required to apply it, and if there is no way the opponent can get a win if you choose to always interrupt. I've referred to both of these as locks, but these are actually different but related behaviours. (Note in this example, the duration of the interrupt is actually the duration of whichever action your opponent was attempting, plus the duration the interrupt prevents further activity for.)

Even if you are careful to ensure the interrupt action takes longer than the time it interrupts the other player, if you team up with other players, it may be possible to get a lock on a single player through judicious timing of interrupts. (Or conversely, multiple enemies could get a lock on you).

But imagine an interrupt which only affects some of the possible actions the other player could choose. An example in Angband is blindness. Blindness has a partial effect on the player's melee and shooting skills, completely prevents spell casting and reading scrolls, but has no impact on the player's ability to quaff potions, or use rods, staffs or wands. As a designer, you can minimise the risk of constant blindness by designing items which can reset the blindness effect and ensuring that they are usable via a action which blindness does not prevent - as a player, you can minimize the risk by ensuring that you carry these items. The counter-example to be avoided: a helmet of blindness which can only be removed by reading a scroll of remove curse. This would give the player into permanent blindness once they accidentally wear this item - not catastrophic, but a significant impact on the overall game.

(For the Unangband equivalents, you could extend this table to include all the possible status effects to get a feel for what different types of partial incapacitation could do.)

By using partially incapacitating status effects, and allowing resets, we can side step the risk of unintentional locks because the player can always reset themselves out of a lock, or choose an action which is unaffected by the lock that allows them to progress towards winning. (Using rods, staffs and wands are permitted while blind for this very reason).

There is still the risk of cumulative locks as follows: imagine there are some number of partially incapacitating effects, each of which affects the player's ability to do certain things, but when some of these effects are applied together the player is totally incapacitated. You can design your way out of this problem by ensuring that there is always something the player can do - but I think there is a more interesting alternative.

I've been using the term path to victory somewhat loosely: but let's be more rigorous about it. The path to victory is the total distance (number of actions or time) that the player needs to win the game. The shortest path to victory is the player doing the optimal action at every point and the opponent picking the most suboptimal action: the game is unbalanced if both the player and opponent choose their most optimal action and either is guaranteed victory. Unbalanced games are fine against multiple opponents (Angband being a classic example of this).

For this argument, assume the path to victory is always progressed by doing damage to the opponent's hit points. In this instance, the most logical way to win is by using your most damaging attack. A counter strategy to this is to use status effects against you which prevent you using your most optimally damaging attack, and force you to use a more suboptimal attack. Ideally the first status effect to apply would be the one that causes the most difference between the two: but it may also make sense to use a status effect which lasts longer and gives your opponent a bigger window for counter attack.

The path to victory is blocked completely if the opponent is able to use a combination of attacks which prevent you doing any damage at all to them. We call this a lock.

The above is pretty self-explanatory and you can see various techniques for reducing the risk of a lock (always allow a damaging attack and a reset to be available, reduce the duration of the combined status effects so that the time to implement them all exceeds that figure etc).

Here's my theory: the risk of a lock becomes a non-issue, when the distance to achieve a lock (time or actions) is the same as the length of your path to victory. That is, if the effort required to get a lock on an opponent equals or exceeds the effort required for to win against that opponent, from a design point of view you don't have to worry about the risk of a lock being applied. In essence, getting the lock is just as difficult as winning.

(In fact, you can have a more generous margin, because it may not be initially clear whether direct damage or a lock is the correct approach to take.)

Antoine's Enchanter (and Unangband's Sorcerer) then becomes a class which can lock opponents through a combination of status effects with about as much effort as another magic using class would take to kill them.

And in part two, I'll look at which status effects that Unangband has to support this.

True dat

“When you were born you shit yourself all the time, couldn’t talk and your hands were too small to shoryuken. in other words you really sucked at being a person, but thats ok, when you start out at anything you will suck. the same is true for making games.“

- Sophie Houlden via Pentaduct

Level 40

I was somewhat surprised by a recent post by LostTemplar on angband.oook.cz:

When I played UN it seemed to me that it is too hard in the beginning and way too easy in late game.

This has to be fixed immediately. I can't have players calling Unangband easy...

A big part of the problem, as Mr Templar points out, is that high level Unangband players end up with an obscene amount of hit points. This is a result of making the size stat determine hit dice, which means even a mage can have a large hit dice. I've tried to balance this by having size penalize agility if your size exceeds your strength, but since every item which adds size also adds the same amount of strength, it is easy to ignore this limitation.

If I remove the size = hit dice benefit, there is little incentive to have a high size, and the size bonus feels about right for most of the game. It's only at high levels (and high stats) where the bonuses becomes obscene.

Which leads me to conclude that I should reduce the level cap for Unangband from 50. This way, the per level bonuses for hit points can remain significant as size and constitution increase, while not having to worry so much about the results at the top end.

I'm immediately attracted to the idea of limiting player advancement to level 40. The reason is that almost all mage spells are under level 40, so I won't have to redesign to many spells to fit the lower level limit. In fact, I shouldn't have to design any*, because spell specialists can cast spells 20% higher than their level, so that they can effectively cast up to level 48 spells. Given I have a to do item to add higher levels spells which only specialists can cast, dropping the level limit to 40 is an automatic win for this reason. This should start to address some of Templar's concerns about imbalanced spells as well.

There are two downsides to this approach: tradition, and level advancement as carrot. Tradition means that long time Angband and Unangband players will wonder what is going on when they get to level 40 and no higher - which will mean that I'll get pestered with questions. Level advancement as carrot means that there'll be less short term goals available to higher level players which they can grind towards. I'm unsure whether this is a good or bad thing.

An alternative is to play with the way that hit points advance. I've done this for other stat advancement: in particular the number of spells learned by low intelligence players is capped before they get to maximum level. I could take this approach. It's very much in the spirit of AD&D second edition where you no longer got to roll hit dice after a certain level. Size contributing hit points up only until level 20 would be one such example. This would make extra size add extra hit points, but not too many extra hit points - +20 hit points per increase in size above 18/110. Constitution by way of contrast gives +50 hit points per +1 CON at level 50 for similarly high constitutions.

* Except Fireball III which is level 49.

The Blockenheal

I note in passing that Valve have returned their Overhealer design to the TF2 beta. The Overhealer is a Medigun that allows the overheal effect to persist. Previous iterations have allowed overhealing up to +100% of hit points - which allowed, among other obscenities, 600 hp Heavies which could ignore a 500 hp backstab - while the latest version merely allows a persistent +50% healing.

The downside is -50% healing rate, instead of previous versions which had a greatly slowed Ubercharge rate.

The Overhealer is an interesting weapon design for a class that has been underserviced by unlocks since the initial release. (The Spy is the only other class which has only 3 unlocks at present - the 4th will possibly be a flame proof suit which replaces the Revolver). During normal play, where the Medic is positioned slightly behind the front line of battle, the Overhealer will unlikely provide much difference to his alternative weapons. At this point, the Medic has a hard time healing characters quickly enough for persistent healing to take effect.

The Overhealer might make a difference between respawns, particularly if the Medic respawns with 2 or more others. That way, the race to the front should allow the medic to get several classes over healed.

But the most interesting time to use the Overhealer is during set up. At the moment, the out of the gate response to a medic is almost always an invulnerability Ubercharge whereas the Kritzkrieg tends to be used during unstructured play.

But the Overhealer is an ideal alternative during set up because it becomes possible for the Medic to overheal the entire team, providing an interesting alternative to an Uber rush.

When considered in this light, giving the Overhealer an invulnerability uber as well doesn't make a huge amount of sense - because the Medic gets both the overheal benefit to the entire team, and the benefit of this initial Ubercharge. I suspect Valve has been tuning the Overhealer rates primarily for this set up time, to either prevent the Medic healing the entire team, or getting the Ubercharge straight away.

The Blockenheal avoids this problem by giving the Overhealer an alternative Ubercharge effect. When charged, right-clicking with the Blockenheal immediately overheals the target and the Medic to 200% of their maximum health, regardless of how much damage they have sustained. This appears as a zap of electricity which shoots up the medigun beam to the target.

For the next 8 seconds after this instant heal effect, the Blockenheal heals at +200% rate - that is three times as fast - up to 200% overheal. Players healed beyond 150% health have noticeably larger overhealed particles surrounding them. The healing above 150% decays at the normal Overheal decay rate after the Blockenheal uber finishes.

The Blockenheal recharges at +100% the speed of the Medigun - that is twice as fast. More importantly, the Blockenheal starts out charged, so that the Medic has the ability to be a useful choice during the dying seconds of the match, without being an overpowered one. The Blockenheal normally heals targets at the same speed as the Medigun and Kritzkrieg.

The Blockenheal allows the ridiculous ways of breaking the game by having 200% health, while requiring the Medic keep a watchful eye on the class he is supporting. The Blockenheal uber doesn't provide the same level of punch that the Kritzkrieg or Medigun does, but benefits more players around the Medic than the Uber or Kritzkrieg is capable of helping. The instant heal effect can also be used defensively, to protect a Heavy from an incoming spy, crocket or distant sniper, or if the Medic becomes isolated.