The Angband competition is featuring an Unangband Dwarf Priest for its 117th iteration.
Wednesday, 25 January 2012
Friday, 23 December 2011
Help wanted (svn2git)
berlios.de is shutting down at the end of the year, which means I need to migrate to alternative hosting like github.
Unfortunately, I don't have a computer with an OS capable of running git* (I've got Vista, and OSX 10.4), which means I can't run svn2git to convert the repository across. So I was wondering if anyone wants to volunteer to do the conversion to save me having to spend a day or two downloading then building a virtual Linux box then going through the package shuffle. From my brief understanding of git, I believe I can then clone your git repository (put it on github) and make the clone the 'official' version.
Warning: Unangband's SVN repository is 'quite large'. The Github online SVN conversion tool notes that the conversion process may time out for large repositories. When I've attempted to use this tool, it appears to take too long (at least an hour) simply trying to get the list of subversion authors.
* I'm using egit which is the Eclipse implementation running on top of jgit. If anyone has done a jgit based svn2git conversion, please let me know.
[Edit: Thanks for the quick responses. I've got someone running an svn2git conversion now...]
Posted by
Andrew Doull
at
10:59
13
comments
Labels: development updates, help wanted, unangband
Friday, 23 September 2011
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.
Posted by
Andrew Doull
at
08:07
1 comments
Labels: game design, links, unangband
Monday, 19 September 2011
Unangband 0.6.4b released
This is a back port of a number of features from the SVN version which probably deserve some air time prior to me releasing a broken 0.6.5. You can download the source code from http://prdownload.berlios.de/unangband/unangband-064b-src.zip and a precompiled Windows build from http://prdownload.berlios.de/unangband/unangband-064b-win.zip.
For the full change log, see the official web page.
Posted by
Andrew Doull
at
23:00
1 comments
Thursday, 4 August 2011
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.]
Posted by
Andrew Doull
at
14:27
5
comments
Labels: game design, unangband
Wednesday, 13 July 2011
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?).
Posted by
Andrew Doull
at
10:59
5
comments
Labels: development updates, game design, unangband
Friday, 8 July 2011
All fired up
A character is wielding a flaming sword (x3 fire damage), flaming gauntlets (x3 fire damage) and enchanted with an aura of fire (x3 fire damage).
Should he be doing:
1) x27 fire damage
2) x7 fire damage
3) +600% fire damage
4) x3 fire damage
This is an important decision that I have to make in the next version of Unangband, and it's vexing me, so I'd like your advice.
Option 1 is clearly overpowered, but one way of thinking about the problem. Options 2 and 3 are two different ways of explaining the same approach: x3 fire damage is short hand for 3 times damage against creatures not immune to fire, which could also be seen as +200% fire damage.
Option 2 is the less intuitive (how does x3 + x3 + x3 equal x7?) but option 3, which rewrites the original problem as "A character is wielding a flaming sword (+200% fire damage), flaming gauntlets (+200% fire damage) and enchanted with an aura of fire (+200% fire damage)." invites the player to think about weapons which might be +150% fire damage, or +87% fire damage. I'm designing Civilisation Revolution, not Civilisation with a V in it, so I like to work with nice whole numbers, not messy fractions.
Option 4 is the vanilla, balanced, safe option, so I have to ignore it.
Thoughts?
Posted by
Andrew Doull
at
17:18
30
comments
Labels: development updates, unangband
Saturday, 18 June 2011
Just like a dirty, cheating player
One of the biggest challenges in Unangband when fighting some of the higher level uniques is their tendency to teleport away then heal themselves up. This extends fights because it forces the player to track the unique down again and continue - and is doubly challenging if the monster also has the ability to recover the mana points that they used up in the process of escaping. What can result is extend stalemates, where the player is unable to damage the unique quickly enough to kill them before they escape again.
There are plenty of opportunities to break these stalemates: deadly traps, cross-fire from other monsters that may be involved in the fight; but these mostly rely on the monster AI not being smart enough to recognise and avoid these additional threats.
The player is equally capable of using teleports and heals, and has the additional ability to flee up or down the stairs at any point (I've considered allowing uniques to do the same) to effectively reset the level. Teleportation can be a risky escape mechanism, because the destination may be more deadly than the current location, and healing may be overwhelmed by more damage the following turn and permadeath ensures that the player is punished for pushing their luck too far. But monster teleportation and healing is less risky, because the unique is in the position of having overall control of the level: there is no other faction he could teleport into which would threaten him, and the player usually lacks the means of ramping up damage even further (because otherwise he'd already be using it).
Allowing the player to summon monsters is one significant way of addressing this, but not every player is a spell caster capable of doing this. Letting warriors and thieves recruit armies or assassins is another possibility, but outside the scope of the game in the short term: and very much against the fiction of Angband which is a one-sided battle where you are the 'weaker' side. Druids are also capable of using spells to 'prepare the ground' and make part of the dungeon far more dangerous for other monsters. And other roguelikes offer anchor magic of various kinds which prevent both the player and nearby monsters teleporting to escape.
A trap that some Angband variants fall into is offering various abilities to drain monster mana, which since mana inevitably is converted into hit points by monsters which can heal, means that these items are effectively doing large amounts of damage - usually much larger than any other attack is capable of.
I think I have the balance of the above mix right for spell casters in Angband, but I'm welcome to more feedback. I'm more worried about whether I've missed anyway of balancing these abilities. I'd love to hear your ideas on other ways to fix this.
And for the record, I've always loved enemies turning around and using healing magics - Tenchu being the first game where an enemy ninja quaffed a potion just like I had been doing - because it makes you realise on many levels just how cheap, portable, instant, heal all magic can be.
Posted by
Andrew Doull
at
10:47
6
comments
Labels: development updates, unangband
Thursday, 16 June 2011
This is why I write games
HallucinationMushroom has won a game of Unangband:
Man, I'm ecstatic! This is a very challenging variant and one I didn't think I'd ever win. I mainly fire up Un for the atmosphere and the first half of the game is my favorite, all the way up to Smaug. It doesn't hurt that my kitchen table roleplaying experiences have almost all been MERP or Rolemaster... it's like retreading old, familiar groundYou can read about his troll bard's feat here.
Posted by
Andrew Doull
at
11:44
1 comments
Friday, 3 June 2011
Well spade
It looks like Unangband is getting the HallucinationMushroom treatment. I, for one, am excited.
Posted by
Andrew Doull
at
06:54
2
comments
Sunday, 23 January 2011
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.
Posted by
Andrew Doull
at
11:11
1 comments
Labels: articles, game design, magic, unangband
Friday, 17 December 2010
Poll results for "How do you find high level play in Unangband?"; new poll
This poll has been around a little while - thanks to the 21 of you who voted:
Too easy; make it harder | 0 (0%) |
Just right thanks | 0 (0%) |
Challenging | 3 (14%) |
Frustratingly hard | 0 (0%) |
Grindtastic | 1 (4%) |
Haven't made it to high levels | 12 (57%) |
Haven't played Unangband | 6 (28%) |
Next poll; it's that time of year again.
Posted by
Andrew Doull
at
20:16
0
comments
Monday, 20 September 2010
Roguelike Release Day
I'm going to take advantage of a) the timezone difference in Australia, and b) the generosity of strangers to contribute very little to Roguelike Release Day a day late.
Please consider Hajo's Iso-unangband WIP4 to be the Unangband Roguelike release for this day.
You may want to check out the official page for Roguelike Release Day.
Posted by
Andrew Doull
at
09:06
2
comments
Friday, 10 September 2010
Iso-Unangband
Despite my attempts to dissuade him, Hajo appears to be insisting on doing an isometric graphics version of Unangband. This will be a much improved version of the experimental Windows code I had previously included. You can follow the thread at angband.oook.cz.
Posted by
Andrew Doull
at
14:27
0
comments
Labels: development updates, isometric, unangband
Tuesday, 10 August 2010
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.
Posted by
Andrew Doull
at
21:20
8
comments
Labels: angband, articles, development updates, game design, unangband
Sunday, 8 August 2010
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.
Posted by
Andrew Doull
at
12:51
2
comments
Labels: articles, development updates, game design, magic, unangband
RIP
For a variety of reasons, I am tempted to add the 'towel wrapped around head' character state.
Posted by
Andrew Doull
at
11:59
2
comments
Labels: development updates, unangband
Friday, 23 July 2010
Throwabow
One possible abuse of the ability to use Angband items in multiple ways is the ability to throw ammunition instead of shooting it from a bow or crossbow. Ammunition is light, which means you can carry a lot of it, and throwing it is 'abusive' because the damage bonus that is applied to firing ammunition is also applied to thrown ammunition, without penalty. This is exacerbated in Unangband because the damage bonus was until the latest version counted twice for thrown weapons and not multiplied by missile launchers, which meant that throwing an arrow (+9,+9) may be more effective than firing it from a longbow.
The damage bonus in this example is insensitive to it's context - it is applied equally when the item is thrown, set in a trap, or fired from a missile weapon*. And if you think the ammunition example could in some way be construed as sensible, consider that the damage bonus a bow applies to arrows fired from it, would also be applied if you threw the bow instead.
At the moment, I'm changing this: damage bonuses will be able to be context sensitive - a weapon that adds damage while fighting, won't necessarily benefit throwing or setting in a trap.
But the question I have is should I enforce this change? This is not quite Warren Spector's proximity mine climbing emergence, but it is an interesting and unintended consequence of a design that may be worth keeping.
I have the flexibility to allow missile weapons with incredibly good trap damage but no shooting damage bonus, but it is unlikely that a player would ever choose such a weapon over a missile weapon with superior shooting damage and no benefit in traps. Whereas if the weapon was multi-functional, it is more possible the player will attempt to take advantage of 'free' additional functionality at some point. I can do either approach with the approximately same level of cleanliness in the code: it is a data design issue, rather than code overhead cost.
It'd be interesting to hear your thoughts.
* There is a separate but related question about worn vs. wielded items. If a sword improves your ability to fight with it, does it also improve your ability to fight with another weapon if you hold it in your off-hand or even just strap it to your body? In particular, if you get one more blow per round with it, do you get that blow if it would be from another weapon?
Posted by
Andrew Doull
at
21:38
3
comments
Labels: development updates, unangband
Monday, 19 July 2010
A big commitment
If it looks like things are quiet on the Unangband development front it is because I'm feeling my way through a ridiculously big chunk of code that I probably should have committed part of already.
Unfortunately, it is mostly back end stuff which you'll see very little of in the actual game: redesigning how timed effects work, allowing items to have multiple pvals (called avals), adding approximately 96 additional item flags which are all pretty much already used in game. The pay off will be flexibility to implement everything I've implemented already. Which is how most redesign work ends up 'helping' what you do.
This sort of thing ends up happening when you code on the train without 3G access.
Posted by
Andrew Doull
at
21:01
2
comments
Labels: development updates, unangband
Saturday, 26 June 2010
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.
Posted by
Andrew Doull
at
21:09
0
comments