Elderlore

Source: Ascii Dreams

“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

Source: Ascii Dreams

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.

Source: Ascii Dreams

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.

Source: Ascii Dreams

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).

Source: Ascii Dreams

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).

Source: Ascii Dreams

I have this bitter, metallic taste in my mouth, like I've just bitten down on my tongue after being slapped in the face... or drinking meths.

I'm angry. They've nerfed the Pyro and now expect me to be happy with this buff?

Let me back up a bit.

For those of you not aware, there has been some light and fury about the recent changes to the Pyro class in Team Fortress 2. Valve has chosen to decrease the direct damage and after burn effects (damage over time) effects of their primary weapon - the Flamethrower - in return for improving the effects and frequency of use of its alternate fire - which allows you to push enemy players and reflect projectiles using a puff of air (Some irrate players now want the class to be called the Aero). This was released in a patch to the game about a week ago, without comment as to why, as part of a number of changes in this constantly evolving game.

Team Fortress 2 is perhaps unique in commercial games - outside of the MMORPG genre - in that it has received constant tweaks since release in game balance. This isn't just a matter of releasing new content (multiplayer maps), but significant changes to the overall balance of classes - and with the class updates - significant changes to the way some classes play. It is a bold experiment, permitted by the digital distribution technology Steam, and a pioneering glimpse at a way some games can continue to be relevent years after release.

Team Fortress 2 is not the first game to receive a dedicated following - Starcraft, Super Street Fighter 2 Turbo, and Valve's own Counterstrike are the first three examples that spring to mind. What two of these games - Starcraft and Street Fighter - have in common is longevity has been maintained through the incredible balance between the moving parts in the system.

Unfortunately balance isn't something you can just design in: it is very much a matter of incredible luck as it is about deliberate design. If you consider all of the computer games ever made, there is only an extremely limited number which are still being played more than 15 years on from their inception (this holds less true now with change with the recent trend in retrogaming). And it is entirely possible that game designers may not even understand what it is that made their game successful. See this analysis on some of the micro issues in Starcraft 2 to get a feel for the level of accidental design detail that contributes towards game balance.

But there are some principles of game design that hold true when it comes to balance - worth reiterating here:

1. Always balance upwards

The most powerful character in a game is probably almost the most fun - especially when you are playing that character and your opponent isn't. As a result, you should use this as a yard stick for where you buff your other choices up to. But be careful not to overshoot when improving them, because:

2. It is much harder to scale down and take away than to scale up and add

Much like cooking, it is much harder to take away ingredients to a game than it is to add them. Particuarly once a game is released, human nature is ingrained against removing functionality and decreasing ability. Programmers have written code, art assets have been designed, people have played with the ability at a particular level. There is nothing like the cry of nerf to rally the forums. But if you are going to take away functionality, be sure to:

3. Change one variable rather than scaling across the board

If you think about balancing a game by playing it, you are really conducting a series of experiments and seeing the results. And science works best when you can vary one value and leave the other variables as fixed as possible. So if you have a character which does three things too well, leave two of them at the level that is overpowered, and reduce the third and then see if that leaves the character balanced against the other choices. Of course, this is easiest when you:

4. Keep your variables independent

The Mutalisk in Starcraft was incredibly hard to balance because it uses the same attack to attack both air and ground units. During testing and post-release patching, if it was too effective against air units, reducing the attack strength would make it ineffective against ground units. And vice versa. Creating two separate attacks would have allowed the game designers to better balance this unit - at the cost of increased art and animation assets required to do so.

5. Statistics and mathematical analysis is incredibly important

If you consider playing as a series of experiments, then the other tools of scientific analysis: statistics and mathematical modelling are obviously critical to get an understanding of how the game works. Unangband balances its monsters by modelling a simulation of 10 rounds of combat and seeing how much damage the monster inflicts. This model is as simple as taking the highest of (chance of attack * damage inflicted * 'typical player resistance * 10) of each attack the monster is capable of but works remarkably effectively. And I don't have to get this exactly right because Unangband, like many games:

6. Provide plenty of resets

A reset is a way of either player recovering from a situation by using up an exhaustable resource. Guilty Gear has an incredible cast of characters with bizarre attacks but also has a number of ways of recovering from the effects and traps of any of these attacks. The resets act as a negative feedback mechanism to dampen the risk of any positive feedback interactions between abilities getting out of control. I've written more about resets and traps in my series on designing a magic system.

7. Intuition and fun are the most important mechanism for balance

Balancing a game is like finding the most effective pay out on an almost infinitely long multi-armed slot machine. You have so many variables to consider that a complete mathematical analysis of most games is impossible. Luckily there is one computer capable of solving these kinds of problems, and that's the one between your ears. But experience is a requirement here. You need to play lots of other games - especially games with depth to them - to appreciate how to balance your own.

8. Ignore (almost) all player feedback when it comes to 'too powerful' abilities

There are an incredible number of people who are prepared to label an ability in a game as being too powerful or cheap, without understanding the ramifications of that ability at high level play. So as a rule you should ignore them. The exceptions are those players who are at the top of their game. You are then permitted to listen respectfully, and then ignore their feedback unless there is other evidence to back up their anecdotes.

9. Your players will figure out the numbers so make the maths available to them

One of the most useful things the phenomenon of crowd sourcing has produced are endless wikis for games of detailled statistics of in game play. If your game becomes popular, the players will figure out the numbers, so you should make them available. Surprisingly, this happens infrequently outside of the strategy game genre - where tables of numbers are a typical characteristic of in game documentation.

So how do the above principles help when it comes to discussing the Pyro changes that Valve have made?

The Pyro class was one of the earliest to receive a class update from Valve - only the Medic preceeded it. But balancing the Pyro was immediately problematic. Within a few weeks of the class update, the new primary weapon the Backburner got its first nerf. Previously it had provided +50 health (and glorious were the days on the servers when the Pyro update came out). Then Valve added back some of the damage drop off that they had removed with the Pyro update to the Pyro's flamethrower.

Since then, the other updates have added various ways of putting out the Pyro's afterburn effect: the Sniper's Jarate, the Pyro's airpuff, the Heavy's sandvich, the Spy's dead ringer (although the cloaked spy can be immediately set on fire again). These have been both thematic improvements and Valve providing a number of reset options to the afterburn effect.

Discussion on the Pyro prior to the most recent changes on the forums has revolved around 2 main areas of contention: the Pyro still being underpowered, and the criticism of the W+M1 still of play of so-called noobs - those people who play a Pyro by running forward with the flamethrowing and not otherwise thinking. Neither of these suggest serious balance issues, and the criticism of 'cheapness' can especially be ignored.

Valve themselves have acknowledged issues with the Pyro at 'high-level' play. But Valve's statements to this effect have been contradictory in the past and may not necessarily point to the heart of the problem - they initially stated that the Pyro was intended for close combat, but the flamethrower has always had weak close in damage - now doubly so.

So is there any balance problems for the Pyro that we can establish empirically without anecdotal evidence or hersay? Looking at the information made available by Valve and third parties, I can see at least one imbalance, and one paradox, worth discussing further.

Firstly the choice between the Flamethrower and Backburner is heavily skewed in favour of the flamethrower. In fact, no other class has such a split between primary weapons (It is worth stressing that all the statistics on the main page are from players who only have both choices available). And how to rebalance? Balance up, of course. This suggests the backburner may need to be improved against the flamethrower some how.

More interestingly, the choice between Shotgun and Flaregun is almost a perfect split. So Valve's buff to allow the Flaregun to do minicrits against opponents on fire has been received well, which we'll use here as a proxy for the two choices being balanced against each other.

Finally the melee weapon selection is biased heavily against the default axe, and towards the Axtinguisher. With the Homewrecker, there is the possibility of novelty or bragging rights factor that may influence the frequency it appears in the short term. Again, we should balance the default Fireaxe up if there is a balance problem - but we don't have the statistics to suggest that this is the case.

From checking the preferred weapons we can see that no other class favours one weapon choice any less for the primary and melee weapons - the Soldier's Equalizer is a straight upgrade to the Pickaxe and so there is no reason to ever not use it if it is available. So we have a clear imbalance between some of the choices that the Pyro has available. This does not necessarily mean that there is not a situational advantage to the weapons which are least selected, but the situation advantage must occur rarely. As always, the suggestion is to balance the unfavoured choices up so that they become more preferred. But this is not itself an indication of whether the Pyro is a balanced class, and so we do not have evidence yet that the class has been nerfed.

Looking at the class distribution choices, the Pyro falls towards the bottom of the range of those chosen. But interestingly, despite being relatively unpopular, the flamethrower damage percentage of total damage inflicted is the second highest behind the grenade launcher. And it has the second average longest range of any weapon (including the Sniper Rifle) except for the minigun. But we know that the flamethrower damage output is incredibly low. There is definitely a paradox here, and one caused by the aggregation of flamethrower damage, and afterburn damage in the same statistics.

And this is the main problem with the publically available statistics. There's not enough detail to have a viable discussion about the Pyro 'nerf'. In fact, the statistics Valve releases aggregate all the weapon statistics together, so it is not even possible to say which weapon choice does more damage (You can see this from the Sniper SMG - actually the Jarate - being the fourth highest source of damage, and the Fireaxe - actually the Axtinguisher - having such a high critical rate). It is not clear from the statistics page but this appears to be a limitation of the way TF2 collects stats.

Without Valve coming out and providing more detailled information about the decision making in making the Pyro changes, the outrage of the forums will continue to boil and players will continue to come up with suggested buffs and nerfs without a deeper understanding of the process that went into making these decisions. Mathematical modelling of the Pyro damage drop off isn't enough to explain the paradox of the flamethrower having the second highest percentage damage output.

So my request is not to buff the Pyro back - it's to improve the communication process and statistics collection. That way we can have a much more useful discussion about the changes to one of my favourite classes.

For the record though: I'd like to see the Pyro back to what they were on the release day of their class update... just for a week, or as a mod. But my biggest problem isn't a Pyro's damage output, it is their longevity. They need something to survive a few seconds longer: perhaps the Backburner should trade increased protection against bullets for increased knockback (allowing an onrushing Pyro to be pushed back by a Heavy's gun) and the Homewrecker should reduce knockback when wielded.

For those of you interested in a more indepth discussion of balance in games, I recommend David Sirlin's excellent four part guide on game balance, as well as his website in general.

I've also written a follow up part two to this article.

Source: Ascii Dreams

In the course of designing a pen and paper RPG (ongoing for a few years now), I have sketched out the following damage scale:

1 A blow capable of temporarily incapacitating; a solid punch to the jaw or floating ribs, a gunshot wound (any location), a solid blow to any limb or the body from a melee weapon; first degree burns; tear gas
2 A blow rendering unconsciousness or blood loss causing unconsciousness; either a gunshot wound to the head (nonfatal) or a solid blow to the head from a melee weapon; strangulation (2 minutes); second degree burns; nonfatal exposure to chemical weapons
3 A fatal blow or blood loss resulting in death; or strangulation (10+ minutes); third degree burns; nerve gas
4 A fatal blow which severs the head or cuts the torso in half; fire or acid which chars the flesh of a corpse leaving no skin or hair
5 Repeated blows or explosives which reduces the body to lumps of flesh; this level of damage could be caused by an enraged mob to a helpless individual over the course of 10 or 15 minutes; fire or acid capable of consuming flesh but not destroying the bone
6 Mincer or grinder which reduces the body to a flesh paste; or in the path of detonation of a shaped charge; fire hot enough to reduces the body to ash or acid to dissolve it to soupy remnants
7 Thermonuclear explosion; chemical processing of body using for example concentrated acid; or specialized equipment capable of evaporating flesh
8 Disassembly by nanoscale machinery; exposure to surface of the sun
9 Disassembly to atomic components; exposure to core of a neutron star
10 Exposure to singularity; exotic methods of reducing to component quarks or strings

Care to guess what the game is about?

Source: Ascii Dreams

I seem to have Civilisation on the brain at the moment; and with the recent 0.6.4 release of Unangband out the door have been spending some time looking at the Freeciv project. If you're looking for roguelike game design, you might want to stick around though, because I'm going to be discussing data file design in some detail.

Freeciv is a Civilisation clone, written originally as an exercise in client server programming (There's a nice history summary at the bottom of this AI discussion). Its implementation of the various Civilisation games falls somewhere between Civilisation 1 & 2 as Alex Mayfield points out the last time I mentioned my Civilisation Revolution house rules. Luckily for me, much of the unit design is very similar to Civilisation Revolution so it seems quite possible that I may be able to get away with limited amounts of source code changes.

The mod system that Freeciv uses is quite similar to the Angband edit file system - with the exception of the format which is seems influenced by the Windows .ini file format. A mod in Freeciv consists of a number of rulesets which are used to initialize data structures with values and flags which impact the game play for that unit. A typical Freeciv unit may have the following format in the units.ruleset file:

[unit_warriors]
name = _("Warriors")
class = "Land"
tech_req = "None"
obsolete_by = "Pikemen"
graphic = "u.warriors"
graphic_alt = "-"
sound_move = "m_warriors"
sound_move_alt = "m_generic"
sound_fight = "f_warriors"
sound_fight_alt = "f_generic"
build_cost = 10
pop_cost = 0
attack = 1
defense = 1
hitpoints = 10
firepower = 1
move_rate = 1
vision_radius_sq = 2
transport_cap = 0
fuel = 0
uk_happy = 1
uk_shield = 1
uk_food = 0
uk_gold = 0
flags = ""
roles = "DefendOk", "FirstBuild"
helptext = _("\
This unit may be built from the start of the game. It is the\
weakest unit.\
")

Contrast this with an Unangband monster entry, and you'll see there is not a lot of difference, other than the format which defines how the values are read in:

N:24:Small goblin
G:k:y
I:110:8:20:16:10
W:2:1:0:4
M:0:0:1:0
B:HIT:HURT:1d5
F:DROP_60 |
F:OPEN_DOOR |
F:ORC | EVIL | IM_POIS |
F:HAS_SKULL | HAS_SKELETON | HAS_TEETH | HAS_CORPSE | HAS_HEAD | HAS_HAND |
F:HAS_ARM | HAS_LEG | HAS_BLOOD | DROP_MISSILE | DROP_TOOL | DROP_WEAPON |
F:DROP_CLOTHES | DROP_ARMOR | DROP_FOOD | DROP_JUNK |
F:SCENT | DWARF |
D:It is a squat and ugly humanoid figure.

One initial observation is the Unangband file format encodes a lot more information in much less space. We could reduce the total length of the Freeciv warriors entry to about half the current length by adopting a similar context-dependent format, as opposed to the more context-free format that Freeciv uses. We know every Freeciv unit has to have an attack/defense/move/vision/firepower and upkeep values, so there is no need to have each of these defined on a separate line: and the user interface itself can be used as a guide for how we can lay out the values more compactly in the ruleset file format.

This may not sound especially important, but from the perspective of quickly editting multiple entries - for someone trying to mod the game - screen real estate is a valuable commodity.

The second observation is that the Roles in the warriors unit in Freeciv are not intuitive, in the same way the Unangband flags are. You can guess straight away from looking at the goblin entry the ways that HAS_HAND and DROP_WEAPON might be used in the game. DefendOK may make sense, but FirstBuild? In some ways, this may be an issue with the fact we're dealing with an agglomeration of multiple individuals rather than a single entity, but it is worth bearing in mind that defined roles (and flags) may not 'natural' and may be worth redesigning.

There is a significant difference between the way roguelikes and Civilisation games play that is not reflected correctly in the similarity between the two file formats. Roguelikes rely on your ability to learn and understand special abilities and unique effects and which one to use at any point in time. The fact that small goblins are immune to poison makes a significant difference only if you are facing a small goblin, and have a choice between a poisonous and non-poisonous attack. So a binary flag is an appropriate way to reflect the criticality of this decision.

Civilisation games on the other hand, rely on the aggregation of small differences over a large number of units, and so scalar values are much more important than binary flags. The fact that a warrior can defend a city is much less important than the attack and defense values of that warrior: a difference of only 1 in attack strength is the difference between success and failure of a particular combat, but that combat may be played out multiple times in a single game, which converges towards an average result in a way that a roguelike does not. If you want to think about it another way, most roguelikes allow you to reset to your starting position of full health at any point during the game with a single item - Civilisation games don't allow you to reset to your full complement of warrior untis.

So while the Freeciv file format is undoubtedly a natural evolution from moving hard-coded game data to an external file the same way that Angband does, I believe there is significantly more value to be gained by extending the file format of Civilisation in interesting ways.

If you look at my Civilisation house rules, you'll see a lot of rules of the format 'with technology/civic/building', unit X gets Y, where Y is often a modification to an existing scalar value of some kind. Or more importantly, the set of units of type Z get this change, where Z could be all units, mounted units, pre-gunpowder units and so on. It would be extremely useful and flexible if we could encode this into the Freeciv ruleset without having to have flags refer to hard coded bonuses in the game code.

There's a couple of ways of considering how to do this. We could go with a full blown scripting model, where each unit runs a script to determine which modifiers apply to it's basic values, and the avaible technologies, civics, buildings and so on are exposed to the script system to check. However, I'm uncomfortable with a full scripting system, and I think we can do this in a simpler fashion.

Imagine a unit as a collection of scalar values and properties. Some properties are intrinsic to the unit ('on-foot'), some properties are dependent on the civilisation ('the-wheel-technology', 'democracy-government'), some are global ('nuclear-winter','global-warming') and some are positional ('attacking-city', 'defending-forest') or modal ('fortified'). A unit type then defines a set of rules where the unit having the matching property modifies either a scalar value through setting the value, addition, multiplication or scaled by percentage, or through the addition or removal of a property for that unit. We can use properties to also indicate that the unit is a member of another unit type, which also has a set of rules which further define the unit and so on.

We can then determine the unit scalar values by starting with the base unit type, and matching rules from that unit type and the rules from its properties, applying the effects of each rule exactly once.

For instance, one unit type might be as follows:

military-unit = {
can-attack;
can-defend;
fundamentalism-government:+1 attack;
...
}

We can also evaluate scalar values instead of properties.

military-unit = {
...
experience>=3:veteran;
veteran:+50% attack;
veteran: +50% defence;
...
}

One important extension to this is that the units have to be able to affect other unit types. For instance, aircraft cannot be attacked by ground units.

aircraft = {
*ground-unit:-can-attack;
...
}

And we have to be able to override this:

anti-aircraft =
{
*aircraft:ignore;
...
}

where ignore is a reserved value that prevents the associated property from being processed.

I'm still in the early days of sketching this out, but I hope this will be an improvement on the existing Freeciv rulesets. The implementation of this design will, of course, be another complication.

My question for you is whether I'm reinventing the wheel here? I believe this is a design pattern that multiple games must have confronted before, and there should be something that already does this work for me, short of going to a full scripting system like Lua.

Source: Ascii Dreams

For anyone who's up for Civilisation Revolution challenge games, may I suggest the following: No Democracy challenge, playing on Diety. The only restriction is you may not use the Democracy civic - Greeks have to change away from that Civic on their first turn.

The game suddenly becomes a whole lot more balanced and interesting, as I suspected.

Source: Ascii Dreams

I've came up with suggestions some time ago about what alternate weapons the Team Fortress 2 Engineer should have. But since then, Valve have released several subsequent updates which have considerably changed how the Sniper, Soldier and especially the Demoman play and a beautiful crafted fan page has suggested some alternate turret weapons. And, in case you've missed it, the last major update to Team Fortress 2 added a chocolate bar for the Heavy and several melee weapons (One for the Pyro and one shared between the Demoman and Soldier).

So the scope is there for the Engineer to have more than a few additional items added: either as a part of the update, or in further releases.

Looking back at the suggestions I made: the Quik-R-Ratchet, or a variant thereof has already been tested in beta as the PDQ; the Scout order book suggestion existed at one point as a backpack but was not adopted; the I-Spy-Shooter is fine, but not amazing - and having played my first 35 point Spy game yesterday, I now feel qualified to state its hard enough already to sneak up on an engineer that I think there are better alternatives; and the BRB still feels distinct enough to be useful - perhaps also allowing the engineer to teleport even if his exit is sapped.

I'm still not convinced that the engineer needs alternate buildings - the only one from the fan page that feels 'right' is the multi-mode flying turret - and Valve themselves have pretty much ruled out replacing the teleporter or dispenser. Buildings that provide various buffs (kritz, minicrits, invulnerability) make the buffs that other classes provide less special, and similarly turrets that provide alternate attacks lessen the uniqueness of class weapons. And anything that affects the small window of opportunity between backstabbing an engineer and having the turret turn and shoot you while you try to sap it, is going to affect the balance of Spy vs Engineer encounters - which of the ways of taking out turret emplacements is the most interesting and least frustrating for the Engineer.

Here are some more Engineer item suggestions:

Gone Again Guitar: While playing the Gone Again, the engineer and all nearby friendly buildings become invisible and do not have any effect or attack enemy players. The Gone Again plays as a taunt animation for a fixed duration with a cooldown. Why: There needs to be a guitar based weapon for the Engineer, and something which allows the Engineer to build in an open location and then draw in the opposition should be fun. Especially since you'll be able to hear him play, but not know where he necessarily is. Replaces the Shotgun.

Ranch Home Rivetgun: The Rivetgun is a ranged weapon similar to the medic's primary weapon, but with a slower rate of fire, much smaller magazine capacity and more damage per shot (about 25% more DPS than the medic). However, the Rivetgun also repairs friendly buildings it hits - at approximately the same rate as hitting it with a wrench. Why: this allows the engineer to repair their buildings while not necessarily next to them - letting them roam with confidence. Since the repair depends on ammunition, it should be a shorter term improvement, and this is balanced against wrenching because the Rivetgun doesn't resupply buildings or remove saps. Replaces the Shotgun.

The Cowpoke: The Cowpoke is a crossbow with a barbwire drawstring and a red hot poker for a bolt. The Cowpoke has better range than the Sniper's bow, but does less damage, and has a much slower reload. Friendly turrets turn twice as quickly when tracking targets branded by the Cowpoke. The Cowpoke replaces the Shotgun. I had planned on making this a melee weapon but realized that a) hitting a building with a branding iron doesn't make a huge amount of sense and b) making this a ranged weapon encourages the engineer to run forward and tag upcoming targets. Note that this doesn't prevent a Spy from disguising or turning invisible - just when the Spy becomes a valid target they get tracked that much quicker.

Stand Tall Spurs: The stand tall spurs allow the Engineer to pick up and move his buildings. If the engineer is hit while moving a building, the building takes damage as well as the engineer. The Stand Tall Spurs replaces the Shotgun - left click to pick up, and then place the building using the original building placement commands. There is a short set up time when the building is placed again (2 seconds) before it comes fully active.

Well-done Arc Welder: The Well-done allows you to buff all nearby buildings temporarily which reduces damage to them by 50% for explosives and 25% for all other damage types, but means you take twice as long to upgrade your buildings. The buff lasts for 15 seconds with a 45 second cool down and appears to be a shower of sparks coming off the affected buildings. Why: an invulnerability buff is tempting, but would completely stop an ubercharge against a building in it's tracks. Whereas a buff may tempt both the attacker and defender to hang around. By biasing the damage reduction against explosives, it reduces the effectiveness of classes the most which don't have to expose them to direct line of fire of the turret to destroy it. Replaces the Wrench.

Good 'ol Grappling Hook: I've waxed lyrical about the next for a grappling hook in Team Fortress 2 long enough - hit a building or map section and you are pulled towards it, hit an enemy player and they are pulled towards you. This would completely unbalance the Engineer, allowing them to aggressively move forward and put turrets in unexpected locations, as well as drag an opponent into their turret's line of fire. I think the craziness would be worth it though - especially after the fun I had with the Demoman replacement weapons. To balance it: the grappling hook prevents you upgrading any building or speeding up construction because it replaces the Wrench. I'd hate to have to contend with a level 3 turret somewhere I hadn't planned on looking.