Poll results for 'What changes do you like in Unangband 0.6.4?'; new poll

The results for what changes do you like in Unangband 0.6.4? Thanks to the 28 people who voted.

Improved dungeon connectivity	8 (28%)
New room types: burrows	4 (14%)
New room types: caverns	5 (17%)
New room types: polygons	5 (17%)
Familiars	5 (17%)
Offering stuff to monsters	0 (0%)
Stealing stuff from monsters	2 (7%)
Monsters surrendering	3 (10%)
Magic book reorganisation	2 (7%)
Less bugs	9 (32%)
Improved documentation	11 (39%)
Improved spell regions	3 (10%)
Sneaking	2 (7%)
Neutral monster AI	2 (7%)
Interaction with allies	4 (14%)
New spells	5 (17%)
New monsters	4 (14%)
Other	2 (7%)
Haven't had time to play	6 (21%)
Unsure; there's so much stuff	3 (10%)
Unsure; still getting a feel for things	1 (3%)

The new poll follows on from the Level 40 post I just made.

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.

Review: Dark Messiah Might & Magic

This game is like every fun Dungeons & Dragons campaign you played as a teenager - a tenuous plot which takes you from set piece to great set piece. It is a fantasy Half-Life 2: cleverly designed physics, beautiful visual design and animation, well-thought out abilities which combine with classic RPG tropes (zombies, dragons, goblins) to make you feel like a fantasy hero. It also succeeds as one of the few fantasy games to make every opponent a worthy challenge.

It will take you a little while to get the feel for the game: don't worry so much about making every stealth kill, because the joyous melee combat engine will win you over. Some mechanics are also not made initially clear - both oil and barrels require you have a separate source of fire to be useful, you can throw your dagger at a fleeing opponent or when you have adrenaline for an instant kill - but where it betters Half-Life 2 is that solving the physics problem won't win you the fight alone. And yes, there are points where it feels like you can kick your way through, but don't ignore the fact most attacks will knock your enemies backwards and take pleasure from the clash of blades, flight of arrows or burning agony of your enemies.

Highly underrated on release because of some poor reviews, along with teething problems with bugs which have since been ironed out. Ignore the apparently atrocious Xbox 360 release, crank the video settings up to the max which should be fine for most modern graphics cards and enjoy the ride.

You should get this now on sale on Steam. (Unless you are afraid of spiders).

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.

Morality in beta

A lot of games by independent developers go through extended beta periods - Mount & Blade is a good example. Many roguelikes take this to the extremes: Unangband has been in beta for over 10 years (Unless you consider most of that period to be alpha).

During that period it is inevitable that players will encounter bugs while playing the game. But with a roguelike, especially one as deep as Unangband, it is not often clear while you are caught up in the moment of play whether the behaviour of a particular element in the game is a bug. It could instead be an exploit that has been permitted or sanctioned by the developer, or unintended consequences which may be patched in a later version of the game.

Ashkir, while playing Unangband, has experienced one such unintended consequence which he has framed explicitly in moral terms. His familiar, which is a customisable summons which develops throughout the game alongside the one subclass of magic user able to summon it, was able to avoid being killed by a unique monster because it is also a unique, and at the moment in Unangband, uniques can only be killed by the player.

As I mention in the thread, I didn't pick this up during testing because I inevitably accidentally would kill the familiar early on in the game, and as a result never noticed this issue. This is important, because once a familiar is dead, it won't come back - a partial permadeath. While this may seem draconian, it met the requirements I initially set for the Find Familiar design.

The Master magic school has a wide variety of summons spells but needed an introductory spell that would allow Master characters to learn about managing their summoned monsters very early on in the game without unbalancing the class by allowing them to spam summons to abuse the game. Find Familiar is therefore a low level spell which allows you to only summon one monster, and implemented as a 'throwaway hack' - something fun I could code relatively quickly and without having to worry about the impact on much of the game. The improving abilities are intended as a bonus for those players who do manage to keep their familiar's alive - and as a way of anticipating the feature request that would have inevitably been made by the player base.

Unsurprisingly, people became incredibly attached to their familiars, to the point where the most common feature request made is the ability to name them. Ashkir has taken this one step further and built his entire play style around the familiar abilities. But I am intrigued about the depth of his reaction to finding out his familiar can't die, for several reasons.

Firstly, is the fact that an unkillable assistant is such a common feature of computer games that has become a trope of the genre. Your pet in Torchlight is the example closest to the genre - it flees instead of dying, because having your pet die would completely unbalance the in-game economy.

Secondly, is that he has been completely abusing another significant bug in the familiar game design without the slightest moral qualm:

'Most importantly I made his attacks drain health so as he hits creatures the life drained is added to my own hit points. This is incredibly useful and gives a Necro a huge advantage as they have a spell that drains their own life to give themselves back spell points, giving me an almost limitless supply of power."

The problem with this statement is that I never intended for the familiar's drain health ability to heal the spell caster - it should merely heal the familiar. This unintended consequence occurs because of the way that your allies attacks are treated as your attacks for the purpose of getting experience.

Thirdly, is the fact that if I gave him what he wants, a completely dead familiar, he in all likelihood would stop playing the game:

I've had a great time with this @ and will definately go back to him later but I'd rather not do it while the bug is present or without using the familiar as it's a massive part of the Necro's play style.

(My emphasis added).

I've presented him with exactly that Solomon's choice simply to see if he takes it up.

There's a lot here worth discussing further. What do you think? (And Ashkir, feel free to correct anything I've assumed here, in the comments, or on the thread you started).

Respect

I've just finished listening to a detailed discussion on the Another Castle podcast about Shiren the Wanderer (with the always excellent Anna Anthropy aka auntie pixelante; who'd be on my top 5 game designers worth reading along with David Sirlin, Clint Hocking, the sadly no longer writing Ted Vessenes and only infrequently blogging Soren Johnson) and I was reminded, again, about the incredible amount of respect people have for the roguelike genre.

It feels like everytime a roguelike peeks above the parapets into more mainstream gaming circles, the comment threads are filled with people relating their positive experiences of Nethack, Zangband, Shiren or some other great example of the genre. And game designers especially seem to love roguelikes, for ways they push game design in directions few others seem willing to explore.

Sure, there is the odd person who dismisses the clunky graphics or user interface problems, but they are in the minority.

I hope as a roguelike developer I'm producing something worthy of that level of respect.

Game Design Podcast recommendations

I have a not insignificant commute every day (1.5 - 2 hours each way, longer if I drive) and was wondering if you, the Internet, have any recommendations for game design podcasts that I may have missed.

I'm specifically looking for game design, or interviews with game designers, or journalists who have in-depth knowledge of a particular game genre.

Currently on my podcast rotation:

Highly recommended:
Another Castle (just discovered which has prompted me to ask the question)
Brainy Gamer
Three Moves Ahead

General games gossip, and worth it for entertainment value:
Gamers with Jobs
One Life Left

Still in the early days of listening so can't make a recommendation yet:
Second Person Shooter (promising)
Hey Ash Watcha Podcastin' (not so)

Not really worth it despite the caliber of the journalists involved:
Rock Paper Shotgun (still on rotation)
Kotaku (taken off rotation)

Light entertainment about stuff that's not as serious as games:
The Economist
TED

Thoughts?

I'm portable

Klaus Breuer has kindly converted a couple of the articles I've written to PDF format using Latex (plus some light edits which I should include in the originals). If you've ever wanted to read me offline, you're more than welcome to download them from here.

Proceduralism: Part Two (Taxonomies)

[You'll probably want to read the original article series that inspired this follow up, then start with part one of this series.]

In attempting to define a taxonomy of procedural generation, I was conscious of the lack of a rigorous vocabulary when talking about procedural content born from the lack of academic investigation of procedural content systems (as distinct from, say, Artificial Intelligence). That is not to say that procedural content generation hasn't been primarily a focus of academia: it is built from mathematical systems which have intrigued academics ever since the Fibonacci sequence, but there has been only a limited exploration of the consequences of these systems, particularly with regards to the game development. This is changing: particularly in the last two years spurred on in a no small part by the efforts of Julian Togelius (not to take lightly the contributions of many others in the field) but also by the validation of games as a field worthy of serious academic investigation.

But taxonomies are difficult beasts to design correctly, because language itself is used in two distinct ways in talking about knowledge and the properties of systems. Language is incredibly powerful tool which we often take for granted, and we often disagree strongly over attempts to provide definitions, which degenerate into arguments about semantic relationships of words to other words. In this sense, words are slippery creatures which we cannot pin down like butterflies to a mounting board.

There is one subset of language is useful: when we talk about the formal properties of a system. When I say that a particular maze is acyclic, I'm not referring to a debatable point which you can disagree on - I'm instead referring to a particular well-defined property of a particular maze which we can provide a number of different but equivalent tests to agree that this property exists for some mazes and does not exist for other mazes. This formal use of languages is equivalent in many ways to mathematical expressions: I've chosen mazes as a specific example both because of the utility of mazes for procedural content generation and the excellent reference on mazes at the Think Labyrinth website.

Using language in this rigorous way has its basis in mathematics, particularly the mathematics of proof, and has grown naturally from there to other scientific disciplines as they have adopted the tools of mathematics in its various forms. But at the same time, the phrasing and idiosyncrisies required of mathematical proof has been adopted as a rhetorical device, and spread much further than the methods of proof it is based on. You should be suspicious of anyone who talks about a definition of something by saying it is this, but not this, and because it is this and this, it must also through induction be this as well: because they are attempting to frame an argument in formal language about a system which is not formally defined, and that is not how people are experimentally shown to give meaning to words.

(How they do give meaning to a word is likely to be something like Prototype Theory).

But while people are not swayed by formal logic, they are swayed by rhetoric, and so my earlier attempt to define a taxonomy for Procedural Content Generation can be seen primarily as series of rhetorical posts, arguing for something (PCG) and against something (little p procedural), and then expanding on what is great about procedural content generation, and setting up various categorisation tropes so that you felt like there existed a field of procedural content generation, stretched back to the history of early gaming (Elite, Rogue and Pascal - the person - if you were especially diligent).

It was, I'll state modestly, relatively successful. Not necessarily directly, but it did force me to actively expand on my initial categorisation efforts into the PCG wiki, which has hopefully created a little more interest in procedural generation, and attempted to provide a working vocabulary for practioners in the field. The one thing I think it has done well is popularized a way of stating what people are working on (Procedural Content Generation) - and the acronym PCG (which undoubtedly has been independently been coined elsewhere).

The taxonomy itself has not been useful. And attempts to categorise games using PCG using it has never got anywhere.

If you look at the PCG wiki algorithms page, instead of the six (or seven) point categories I outlined, you'll instead find a number of headings: concepts, map generation, sequence generation, ontogenetic and teleological, and the categories I proposed buried as relatively unimportant subheadings alongside various other algorithmic techniques and high-level concepts.

Concepts is kinds of a catch all category, which should really be the name of the whole page (instead of algorithms or code), because there is a large amount of talking about concepts on the wiki, and links to people outside the wiki, and precious little in the way of actual algorithms and code. I would love at some point to sit down and write lots of example code, and if you have the time, please do so. But you'll probably succumb to Doull's Corollary.

(For the record, Doull's Law as "Any time saved using procedural content generation techniques will be lost staring at the resulting screen saver." and Doull's Corollary is "Don't ask the procedural generation community for help because they're inspired by procedural generation as a way of avoiding the type of work you're asking them to do.")

Map generation and sequence generation were suggested early on by droid as a way of breaking down a relatively monolith version of this page into two different but related types of algorithms. They are good at doing that, but of themselves are not especially useful as ways of thinking about procedural content generation.

Ontogenetic and teleological on the other hand are incredibly useful concepts which I stole shamelessly from an article by Mick West. (I'd love to know if there are any earlier references to these two terms being used in association with procedural generation). In short, ontogenetic algorithms attempt to duplicate the end result of a physical process without emulating the intermediate steps, and teleological algorithms attempt to simulate the physical processes which result in the desired procedural output. Each approach can be used in combination, but any time you attempt to create something procedurally, you will be guided by one or other approach.

Julian Togelius, first in a post to the Procedural Content Generation group, and then in a paper Search-based Procedural Content Generation written in conjunction with Georgios N. Yannakakis, Kenneth O. Stanley and Cameron Browne outlines some other decisions required in the development of a procedural content generation algorithm: online vs offline, necessary vs optional, random seed vs parameter values, stochiastic vs deterministic generation and constructive vs generate and test. Note that each of these is a continuum rather than a necessarily binary distinction, and they do not attempt to define what is not procedural content, but more what are the decisions around implementing or requirements of a particular PCG algorithm. I highly recommend the paper as an overview of PCG and a view of where academic research in PCG is currently concentrated. It is written at a level you should be able to follow even if you are not especially technical or academic.

There are other distinctions which you could attempt to make between various types of procedural content generation. One example I'll pick is content generation vs content selection - described in an article at Grand Text Auto. You'll see from my comments there that it is a distinction I don't necessarily agree with, although it is another attempt to redefine what I called user mediated content in the original article series.

The take away from this revised overview of PCG taxonomies is that you shouldn't wed yourself to any particular definition of what is or isn't procedural content beyond the point where it assists you in creating a particular procedural generation algorithm. At the time I wrote Death of the Level Designer, there wasn't a particular emphasis in academia on the Procedural Content Generation as a discipline, but since then (and I hasten to add, not because of the article) there is a growing belief that there are specific reasons to investigate PCG as a separate field of study distinct from its parts. You should use resource like the PCG wiki to help get inspiration for how to solve a particular problem, but feel free to look elsewhere (I'm fond at the moment of this implementation of Navier-Stokes equations).

In part three in this series, I'll ask the more fundamental question I've been avoiding so far: if words are slippery enough that we can't define a PCG taxonomy, can we at least define what procedural content generation is?

Roguelike Studios II

Jeff Lait's response to the Roguelike Studios video:

Roguelike Studios

I'm not sure how I missed this:



The town level looks awfully familiar as well...

(And Notepad FTW. I did most of my early development work in notepad... but with more carriage returns.)

[Thanks to Temple of the Roguelike].

A Heated Debate Over Balance: Part Two (Viability and Validity)

In part one of this article series, I outlined some ways of balancing games in reaction to a nerf to Team Fortress 2's Pyro. Since then, the Pyro has been (mostly) unnerfed by tweaking the percentages and duration of various values but the Team Fortress 2 Pyro community remains dissatisfied with class as it currently plays. It's time to revisit this discussion.

In the various Team Fortress 2 articles I've written, I've come up with a variety of weapon unlocks and suggestions for the classes in the game. I've not especially worried about the numbers, on the basis that these values require extensive testing - but I was proud of the variety of different ideas I'd come up in isolation.

But reading the Steam TF2 class and balance forums after these suggestions is a little disheartening. It looks like everyone has lots of ideas to contribute, and they're all prepared to go into lots of detail about these ideas, defending, tweaking and trying to balance them based on the opinions of even more people willing to label them as OP or UP (overpowered or underpowered). My thoughts are bound to get lost in the noise. And there is a lot of noise.

(I'm reminded of a Penny Arcade cartoon about the evils developing an MMORPG.)

It is hard to balance the Pyro because Valve hasn't given enough statistical information about the game as a whole, so any set of numbers anyone comes up with exists in a vacuum. It is incredible difficult to work out if a change is viable as a result. The way I get around this in Unangband is through algorithmic balancing: by running short artificial simulations to attempt to determine the degree of difficulty of a monster, and where to place it in the game. There are a lot of built-in checks and balances to allow this in a roguelike; most of which of these are absent in a multi-player game.

Especially critical for balance purposes is whether a choice is viable at high level play. High level competitive play in Team Fortress 2 is usually 6v6, with two soldiers, 2 scouts, a medic and a demo on each team. This structure has emerged organically from the interactions between the variety of TF2 classes and shows that the choice of class is important, and balanced in a way that is interesting and useful in tournament play. Making a class that was too viable by itself would disrupt the delicate balance that has evolved.

Last night I finally got a Team Fortress 2 drop I had been waiting for: the Scotsmans's Skullcutter. This is a recent addition to the game from a community contribution with the following stats: +20% damage, -15% speed, longer weapon reach.

So how can I determine if this choice presented to me is a viable one? Well, I can reasonably be assured that it is unlikely to be used in high level play: because at that level, a large part of the game is about mobility, and a speed reduction is a significant nerf at that level (although the demoman has other ways of quickly getting around). I can look at the percentage of players choosing to equip the item at tf2stats or try to get a recommendation on the Steam forums either from the Demoman forums or the victims of Demoman forums. I can also compare simulations of combat between the skull cutter equipped demoman against other classes, weighting the probability of getting a crit against the maximum or average hit points of a particular class.

But what a chore.

It was far easier for me to switch to the Demoman class, equip the weapon (along with the Chargin' Targe) and rush out and sever heads. 8 heads in 3 minutes later, I could confidently declare 'The demoaxe is OP' before switching back to whichever class I was intending to play for the evening.

That is because I'm not trying to find out whether the Skullcutter is a viable weapon - because I'm not able to run a controlled statistical trial or simulation. What I am looking for is for anecdotal evidence that the Skullcutter is a valid weapon to use at all. When we talk about interesting choices in games, we are not trying to determine whether the alternatives are equally viable, but whether the alternatives can be easily validated.

What do I mean by this? Let's take the Pyro's Homewrecker. This weapon has it's damage nerfed against players in return for increased damage against enemy buildings, and the ability to knock a Spy's sappers from friendly buildings. The Homewrecker is not an especially viable weapon. The damage nerf is too high and there is limited opportunity to use its special abilities.

But people still use the Homewrecker: 39% of them when given the choice. This is because it is easy to validate when the Homewrecker is useful - by knocking sappers off a friendly building. Everytime you do this, you are unconsciously reinforcing the correctness of the decision to use the Homewrecker. And if you see sapped buildings when you don't have a Homewrecker equipped, you are immediately reminded of the presence of this other choice.

Any time you are forced to make a decision you are immediately also creating a doubt in your mind about whether you have made the right choice, so you are unconsciously attempting to look for evidence to support the decision. People play games not for the choices, but for the validation of those choices.

So we have a contrast of types of decision: viable decisions are only important at high level play, where the percentage amount damage or movement is changed by are critical, but validated decisions are important at all levels of play. Equally, you can present lots of interesting choices which are not viable, but are still valid - the fact there are nine classes in TF2, only five of which are viable, but all nine of which are valid. A lot of balancing work, and statistical analysis, and heated debate is put towards trying to make decisions viable - but it is far more important to make sure decisions are valid.

I've suggested there are two ways that a decision can be validated: you can have either negative or positive reinforcement. The negative enforcement - where you are shown to have made the wrong decision - is weak in the sense that it reminds you of the presence of alternatives, but also creates frustration about the choice you have made. But positive reinforcement, that you have made the right decision, is much stronger because we actively seek it out, and allow our gut instincts in doing so to overcome our rational, viable, decision making processes. And it is particularly the feeling of mastery, where you feel unbeatable against others who have made a poor choice, that is important in multi-player games.

So how does this apply to the Pyro?

Let's take another Team Fortress 2 class which is not viable at high level play: the Spy. The Spy isn't used much competitively because his abilities rely in part on the incompetence of other players: his attacks are situational, he has limited ability to move unexpectedly and limited damage output.

But importantly, the Spy has a lot of opportunity to demonstrate mastery - the backstab being the ultimate expression of dominance over another player. Each successful backstab reinforces the decision taken to be a Spy, as does sneaking around behind enemy lines, avoiding detection while being disguised and sapping buildings. A Cloak & Dagger spy has his decision to equip this item validated every time he hides in a corner and does nothing - surely a contrast in a decision being validated, while being completely nonviable for him and his team. A Dead Ringer spy has his decision to equip this item reinforced every time he (apparently) dies. Beginner spies are drawn to sap buildings like flies to honey simply because they can.

Even the simple act of jumping up and down on the spot can validate the choice to be a Spy if you're disguised as a Scout, and the enemy makes the mistaken assumption you are one. And no other class has a 'validate my Spy-ness' button like the Spy's call for medic while disguised.

Similarly the Engineer is rewarded for their engineer busy work alongside sentry kills and the Sniper for head shots, even though fully charged body shots are a much more viable decision. (The Razorback is another great example of a decision which is not especially viable but is frequently, and usually negatively, validated).

What creates the most heat about the Pyro is the fact the class has so few opportunities for mastery. There are two clear examples:
1. Air blasting an uber charge
2. Setting a Spy on fire

In addition, I regularly experience two additional types, which are situational and can be difficult to achieve:
3. Killing an enemy from behind using the Backburner.
4. Reflecting rockets at medium range against a Soldier.

There are more (Puff & Sting, finishing with an Axtinguisher, Flaregun criticals, corner rushing a sentry nest, the Homewrecker example I gave earlier) but these have the same problems of unreliability and situational complexity.

Equally there are situations that the Pyro primary weapon design implies should give them mastery, but in fact do not, such as setting lots of enemies on fire and ambushing an enemy. Each time the Pyro fails to perform in these situations, the player is negatively reminded of the choices that they could have made (e.g. pick another class) but did not.

The challenge in a Pyro redesign is to validate their decision through feelings of mastery, by appealing to the intuition of the player, without necessarily adjusting the viability of the class. I don't expect the Pyro to be used in high level play, so I'm not focused on increasing the top end skill level. I would suggest a design which does the following:

1. Rewards setting multiple enemies on fire.
2. Reduce the penalty for missing nearby rocket and grenade reflections.
3. Increased survivability in close quarter combat.
4. Reduce the penalty for choosing the Backburner while increasing the skill required.

These are chosen to try to minimise the negatives for a wrong decision, to allow the situations I outlined earlier to emerge more frequently and validate the decision to play a Pyro. I believe these can be achieved without requiring additional art or animation assets, or new features be added to the game, as follows:

1. Rewards setting multiple enemies on fire.

The only benefit the Pyro receives from the after burn is an increased chance of criticals, which ramps up slowly as the after burn DoT accumulates (and is vulnerable to after burn removal from a variety of sources). The minimal change to benefit the Pyro would be to apply the total DoT credit to the critical chance immediately, instead of accumulating the damage as the enemy burns i.e. every enemy the Pyro has on fire counts for +0.6% chance of criticals every second for up to 30 seconds after they were last hit by a flame particle.

As noted, Backburner criticals create a sense of mastery - by crediting the Pyro prematurely for fire damage they will inflict, there is an increased likelihood of experiencing this feeling against a large group of enemies.

2. Reduce the penalty for missing rocket and grenade reflections.

Grenades and rockets both deliver explosive damage, so the simplest solution without affecting the balance of the Pyro against other classes is to give the Pyro innate explosives resistance - an alternative would be to reduce burst damage but which doesn't address instances where the Pyro is directly hit (likely given they are moving into the proximity of the weapon). A the moment two close range rocket or grenade direct hits will kill a Pyro: to boost this to three requires they have at least 224 health, or approximately 1.3 times their current health. A critical rocket does 270 damage, a critical grenade does 280 - 300 damage.

So the Pyro should have 30-60% additional resistance to explosive damage. This can be justified in game by the suit the Pyro wears. At 30% resistance, an overhealed Pyro will be able to resist a single critical rocket or grenade so I'd suggest this as the baseline (compare this to the Targe's 40% resistance).

3. Increase the survivability in close quarters combat.

The biggest risk to the Pyro in close quarters combat is from rockets or grenades which they are unable to reflect in time - all other enemies can be set on fire and then puffed away. The increased resistance to explosive damage should be sufficient to address this.

4. Reduce the penalty for choosing the Backburner while increasing the skill required.

The choice of Backburner is penalized every time the Pyro is presented with the opportunity to do an Air Blast - which is frequently. I suggest the situations where the Backburner gets mastery are so limited (from behind, and sometimes against other Pyros) that the complete elimination of the air blast is too significant. So I'd change the Backburner to have the following changes from the Flamethrower:

+15% damage
Criticals from behind
Reflected projectiles do not minicrit
-50% ammunition capacity

At 100 ammo, the Backburner still has over 8 seconds of burn available, but each air blast uses twice the effective ammunition and so is a significant choice to make.