Archive

Posts Tagged ‘unangband’

Unangband 0.6.4 windows debug build

July 24th, 2010 Andrew Doull No comments

Source: Unangband: The Unnamed Angband

I've released a debug build of the Windows version for those people experiencing the crash on level up bug which I've not been able to duplicate.

You can download this debug build from here and update the bug details here if you experience the crash with this build.

This also includes a fix for the invulnerable familiar bug discussed here.

Throwabow

July 23rd, 2010 Andrew Doull No comments

Source: Ascii Dreams

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?


A big commitment

July 19th, 2010 Andrew Doull No comments

Source: Ascii Dreams

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.


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

June 26th, 2010 Andrew Doull No comments

Source: Ascii Dreams

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

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

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


Level 40

June 26th, 2010 Andrew Doull No comments

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.


Morality in beta

June 11th, 2010 Andrew Doull No comments

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


Morality in beta

June 11th, 2010 Andrew Doull No comments

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


Dungeons and Room Types

April 14th, 2010 Dave No comments

Source: Kharne

My next blatant theft of a feature from another roguelike will probably be the room names from Unangband. I've deliberately not looked at the code for this on that game, but am designing my own system. I have the implementation worked out in my head for this already, but as ever I need more lubrication for my creative juices!

So let's imagine, say, a circular room in an undead themed level. What could it be called?
  • The most straightforward would be random selection from a list generic names such as "The Slaughterhouse", "The Crypt", "The Necopolis". This would have to be a large list to avoid reusing names.
  • This could be enhanced by adding one of more random adjectives before and after the name, e.g. "The Hidden Slaughterhouse", "The Crypt of Despair", "The Crypt of Hidden Dreams".
  • And then we can consider the role of uniques. If we generate a unique in the level inside a room, name the room after the unique: "The Crypt of Barney", for example.
  • Now, additionally, depending on the name, selected, we could reverse the traditional way of generating dungeons and let the name drive the dungeon features. For example, consider a room called "The Hidden Slaughterhouse" - use of the term "Hidden" would mean the entrances to this room are sealed up with diggable walls (or doors) - and use of the term "Slaughterhouse" would mean that there would be loads of corpses generated in the room, as well as certain types of monsters.
  • There could also be passive effects tied to the room, for example, with "The Hidden Slaughterhouse" there could be a smell that makes the character nauseous whilst inside it.
Yes, I know I'm probably going through the same thought process that Andrew Doull went through about ten years ago, but I'm increasingly convinced random generic dungeons can't cut it any more in roguelikes.

So yet again, its time to ask: thoughts? ideas? Comments are most welcome.

Unangband 0.6.4 released

April 5th, 2010 Andrew Doull No comments

Source: Ascii Dreams

This is the "Once your variant gets a nowhere town, it will never leave" release aka "Wasn't this supposed to be out months ago?"

You can download the source code from http://prdownload.berlios.de/unangband/unangband-064-src.zip. You can download a precompiled Windows build from http://prdownload.berlios.de/unangband/unangband-064-win.zip, a pre-compiled Mac OS/X build from http://prdownload.berlios.de/unangband/Unangband-0.6.4-osx.dmg. A Linux version should be following shortly. [Edit: Now available at http://prdownload.berlios.de/unangband/unangband-064.tar.gz - thanks to Mike].

For more details, please see the official website.

I've not spent nearly enough time quashing bugs, but real life has left me pretty drained at the end of the working day. I'm sure my motivation levels will pick up soon enough - just need a little holiday from staring at the source code.


Unangband 0.6.4 released

April 5th, 2010 Andrew Doull No comments

Source: Unangband: The Unnamed Angband

This is the "Once your variant gets a nowhere town, it will never leave" release aka "Wasn't this supposed to be out months ago?"

You can download the source code from http://prdownload.berlios.de/unangband/unangband-064-src.zip. You can download a precompiled Windows build from http://prdownload.berlios.de/unangband/unangband-064-win.zip, a pre-compiled Mac OS/X build from http://prdownload.berlios.de/unangband/Unangband-0.6.4-osx.dmg. A Linux version should be following shortly. [Edit: Now available at http://prdownload.berlios.de/unangband/unangband-064.tar.gz - thanks to Mike].

Special thanks to all those who reported bugs and especially those who fixed them for this release. My apologies if I didn't get to your bug this time around.

### Game Play ###

- Add low level spell to allow Masters to light rooms.

- Ensure minimum blood debt.

- Reduce summoning debt for some monster types.

- Allow travelling while poison is slowed.

- Allow line of sight/panel/level based spells to affect objects and
grids separately from monsters.

- Improve sensing of non-cursed items using techniques which sense cursed state.

- Improve sensing to note that an item is not cursed when you wield it and it is not cursed, if it was unusual or nonmagical (The other cases were correctly handled prior to this).

- If you sense what bag an item belongs in without identifying the item,
all subsequently created items are similarly sensed

- Make Cure Poison mushrooms cure poison instead of slowing it.

- Rebalance some master summoning spells to be more useful at lower levels, as well as balance some of the resulting summons.

- Differentiate spells which summon a monster, versus those which create or animate a monster. The latter do not incur mana or blood debt and do not leave your service.

- Hatched eggs or rebuilt golems no longer leave your service.

- Lemures are now truly larval.

- Prevent regions 'double-hitting' a grid during the same attack.

- Make some plants strangle.

- Prevent monsters fighting each other from using attacks which would heal their intended target (Reported by vrbones).

- Make player traps more useful: murder holes use up ammunition less frequently; spring-loaded traps never use up ammunition; allow magic items with higher multipliers when set in traps; give bonus shots and damage multipliers to traps set by the player deeper in the dungeon.

- Add deeper and more deadly murder holes and spring-loaded traps.

- Cure all (debug command) should restore stats before healing.

- Better balance depth of traps based on damage.

- Slight tweak to ensure monkeys only carry pebbles.

- Flask throwing monsters can now carry gunpowder flasks.

- Add seeker shots.

- Allow monsters to surrender.

- Attempt to make mechanisms useful for something.

- Add Reveal Secrets spell.

- Grey monsters are now consistently immune to acid and cold and frequently immune to poison. Grey orcs no longer blink (bug 16745).

- Add identify and recharge item I services to the Magic Shop. These were almost always added by the presence of various Wizard books in those shops, and so unfairly penalized non-Wizard school casters. (Bug 16739, suggested by thorgot). Doubled cost of identify service to compensate.

- Give take item to unseen servants to make them more servant like.

- You now learn monster hit points and armour class based on the number of times you damage the monster, and the number of times you attack the monster with attacks which can miss, instead of the number of times you kill them.

- Make magic mapping dection area consistant with all other detection areas.

### User Interface ###

- Warn the player if their summoning spell doesn't produce a monster.

- Summoned monsters are always visible the first round they are summoned.

- Changed sunken city to sunken cities (Suggested by Arralen).

- Add reserve mana to character display. (Thanks to bigalphillips for this and other fixes).

- Rewrite level up screen to show how increasing a stat will affect your characters abilities. (Thanks to bigalphillips)

- Move Gain Familiar Ability menu over to fit longer entries on a 80x24 screen.

- Minor command documentation changes

### Bug Fixes ###

- Prevent monsters being entombed by traps or regions.

- Fix style description on character sheet.

- Fix display not refreshing after a quake.

- Fix psionic blast message.

- Fix for monsters not incurring summoning debt.

- Distinguish between spells which summon multiples of 1 of a monster vs spells which can summon group monsters.

- Fix for Bug #16933 Libraries need owners

- Fix for 016789 Targeting that does not target ...

- Fix for bug #16792 {Magic} items are called egos or artifacts, but not always (Reported by bigalphillips).

- Fix for Bug #16799 Monster is afraid after already dying (Reported by bigalphillips).

- Fix monster spell and blow descriptions.

- Remove invalid assertion that would cause game to crash.

- Fix description of monsters guarding locations.

- Was biasing stairs in wrong direction.

- Fix for bug Bug #16746 Lines of doors and shops appear in dungeon (Thanks to Big Al for triage and careful analysis).

- Fix for bug 016731 Sanity check birth_gollum.

- Fix for bug 016730 Don't award disarming experience for traps you can't hit

- Fix for potion of experience description.

- Fix parsing of dungeon zone names (reported by Arralen).

- Fix up bag of holdings in dumps. (#16791)

- Fix up various documentation inconsistancies and typos.

- Fix descriptions of bags of holding in death dumps.

- Fix for Bug #16732 stealing doesn't display items you can steal.

- Fix for bug #16780 failed to move 1, 0 messages (Reported by bigalphilips).

- Fix up some typos in character dumps. (#16734)

- Fix spell power calculations (especially for Apprentice Mages). #16735.

- Fix gollum mode birth option. (#16733)

- Fix bug where tangleroot/briarpatch would damage monsters not near water or plants (Reported by satyr).

- Fix bug where detect objects would detect the terrain which contained an object (Reported by arralen).

- Fix pickup messages for items in magic bags. (#13835)

- Fix for bug 16743 Lightning Spark description (Reported by Bandobras).

- Fix for bug 16758 Sting spell never learned, uses energy or mana (Foolishly reported by Pete Mack, also konijn and others)

- Fix for bug 016749 specialist items in off-hand slot can be destroyed by acid

- Fix for bug 016748 specialist can't wield to off-hand slot if a shield is worn.

- Add parentheses to fix punctuation problems. (#16760)

- Stop the player from landing on the downstairs of the Mirkwood Cellers (towns now use MORE and LESS flags).

- First pass at updating monster descriptions to include damage for spells and breaths. There's a couple of extraneous 'to's but looks good otherwise.

- Fix lighting of lanterns with no fuel message.

- Fix up spellbook descriptions for magic specialists.