Changes between Version 6 and Version 7 of NewEgos


Ignore:
Timestamp:
10/13/11 09:33:10 (8 years ago)
Author:
magnate
Comment:

Reorganised the next steps stuff

Legend:

Unmodified
Added
Removed
Modified
  • NewEgos

    v6 v7  
    44 
    55== Introduction == 
    6  
    76This work was based on some ideas vaguely expressed in http://angband-dev.blogspot.com/2011/09/so-what-exactly-is-ego-item-anyway.html 
    87 
     
    109 
    1110== What hasn't changed == 
    12  
    13 All the old objects and ego items, are still generatable almost exactly as they used to look. Slay weapons, branded weapons, Defender/HA/Gondolin/Westernesse weapons, Elvenkind armours and boots, Robes of Permanence, etc. At the moment (subject to any rebalancing we may wish to do) they are still generated with the same flags and on the same object types as they used to. (So only Maces can get the Of Disruption suffix, only Scythes can get Of Slicing, only robes can get Of Permanence etc.) 
     11All the old objects and ego items are still generatable almost exactly as they used to look. Slay weapons, branded weapons, Defender/HA/Gondolin/Westernesse weapons, Elvenkind armours and boots, Robes of Permanence, etc. At the moment (subject to any rebalancing we may wish to do) they are still generated with the same flags and on the same object types as they used to. (So only Maces can get the Of Disruption suffix, only Scythes can get Of Slicing, only robes can get Of Permanence etc.) 
    1412 
    1513== What has changed == 
    16  
    17 I say "almost" because there are two noticeable differences. Some of the high-end items will have all four IGNORE_ flags where they only used to have one or two (e.g. Gondolin). More significantly, most items will have lower to-hit/to-dam values than under the old system - though this can now be addressed purely through editing ego_item.txt and ego_themes.txt 
     14I say "almost" because there are two noticeable differences. Some of the high-end items will have all four IGNORE_ flags where they only used to have one or two (e.g. Gondolin). More significantly, most items will have lower to-hit/to-dam values than under the old system - though this can now be balanced purely through editing ego_item.txt and ego_themes.txt 
    1815 
    1916=== The ego_item type === 
    20  
    2117Ah yes, themes. Let's get down to the code. The ego_item type still exists, and they're still stored in the global e_info[] array, but they're not called egos any more, they're called affixes (because you can have MAX_AFFIXES of them). There are some (IMO) useful changes to the type: 
    2218* The C: line now takes seven parameters rather than three. As well as to_h/to_d/to_a, you can now modify base AC, weight, dice and sides. The first two of these are percentage mods (and are signed so can be negative), the last two are just extra dice and sides (but can also be negative). Full credit to Eytan Zweig for inspiring these. 
     
    3329Ok, so those are affixes. I stripped out all the compound egos, with multiple attributes, and boiled affixes right down, so that each only provides one or two things. Resist affixes still give the IGNORE_ flag, and the five x3 brands still give both RESIST_ and IGNORE_ flags, but otherwise most affixes only provide one flag. I've added the !EyAngband prefixes, which modify the base properties of armour and weapons (AC, hit/dam, dice/sides) - I left out only the inappropriate race-specific ones (Ey has lots of weird races), and guesstimated on some. (N.B. I was concentrating on implementation, not on balance, so there is a ton of room for tweaking the values of any of the Ey affixes, and any others.) I also stripped out base objects which are obviously other base objects with affixes: Lead-Filled Mace, Mithril !Chain/Plate, Adamantite Plate, Mace of Disruption, Scythe of Slicing. These are all now affixes (but see below for more to do on this). 
    3430 
     31N.B. There is no base item called "Blade", so the "of Chaos" affix can be applied to the top three swords (Katana, Zweihander and Executioner IIRC). Though there's no reason not to allow Daggers of Chaos, if we want to. 
     32 
    3533=== make_object and make_artifact === 
    36  
    3734Having improved the type and reduced the egos down to simple affixes, I set about changing object generation. First I rewrote kind_is_good to look for OF_GOOD, so that powerful items like DSMs are automatically considered "good" and never "average". This doesn't actually have much impact on the obj_alloc_great table though, since all armour and weapon types were already in it (but see below for more thoughts on this).  
    3835 
    3936Then I sorted out artifact generation, combining special and normal artifacts. This distinction only ever existed because all normal artifacts were only ever generated after the object kind was chosen, and specials were attempted before. Now make_object tries for an artifact first, and make_artifact now creates an allocation table of all possible artifacts (i.e. not yet created, in-depth, out-of-depth checks etc.) before choosing one. If the kind is already chosen (e.g. from specified monster drops) then the allocation table looks a lot smaller because it only contains artifacts legal for that kind.  
    4037 
    41 Please note: artifact generation will need quite a bit of testing, because not only did I unify the generation functions (which will fundamentally change how many are generated), but I also recalibrated the alloc_prob scale to 1000 rather than 1000, and reflected the fact that these are now checked independently of base items. So Bladeturner's old rarity accounted for the fact that its base item was very rare: now it has to be even rarer. I implemented multiple A: lines for artifacts, so we now have finer control over their findability (because they can have different rarities at different depths). 
     38Please note: artifact generation will need quite a bit of balancing, because not only did I unify the generation functions (which will fundamentally change how many are generated), but I also recalibrated the alloc_prob scale to 1000 rather than 1000, and reflected the fact that these are now checked independently of base items. So Bladeturner's old rarity accounted for the fact that its base item was very rare: now it has to be even rarer. I implemented multiple A: lines for artifacts, so we now have finer control over their findability (because they can have different rarities at different depths). 
    4239 
    4340=== Choosing and applying affixes === 
    44  
    4541So, if we're not an artifact we now set the number and quality of an object's affixes in apply_magic. Note that the call to apply_magic from make_object deliberately sets allow_artifacts to FALSE, because we've already tried for an artifact there. But if it's called directly (for a specified item), then we still get a shot at becoming an artifact. 
    4642 
    47 One important change is that *all* items can now get "good" affixes. This is because apply_magic_weapon/armour() have been removed, and plusses now come from first-grade affixes (Quality, Sharp, Brutal etc.). Forced-great items automatically get access to great affixes, and good items do so 25% of the time. There's also a depth-dependent chance for increment, so uber affixes are (i) only available on good or great drops and (ii) much less likely early on.  
     43One important change is that *all* items can now get "good" affixes. This is because apply_magic_weapon/armour() have been removed, and plusses now come from first-grade affixes (Quality, Sharp, Brutal etc.), but you can now get minor abilities like Feather Falling on what would previously have been just "good" items. Forced-great items automatically get access to great affixes, and good items do so 25% of the time. There's also a depth-dependent chance for increment, so uber affixes are (i) only available on good or great drops and (ii) much less likely early on.  
    4844 
    4945The number of affixes is a function of depth (0 to (1 + lev / 25)), plus one or two if good, or three or four if great (minus one if we have OF_GOOD). These numbers can be rebalanced, of course. There might not actually be many "great" drops, so we might want to be more generous to normal or good items, and tone down the great items to only a couple of extra affixes. But note that "normal" drops get much more interesting with depth, so this may not be necessary. 
    5046 
    51 I haven't done a lot of renaming yet, but I've renamed make_ego_item to obj_add_affix because it wasn't called from anywhere else except apply_magic. It checks that we're not trying to add an affix to an artifact, a themed item, or an item with max affixes already. It also does that weird GREAT_EGO level boost, for a one-in-20 chance of a potentially huge level boost (though that doesn't boost the affix level). Importantly, we copy the object, so we don't have to worry about affixes creating broken items - if that happens we just roll back and don't add anything. 
     47I haven't done a lot of renaming yet, but I've renamed make_ego_item to obj_add_affix because it wasn't called from anywhere else except apply_magic. It checks that we're not trying to add an affix to an artifact, a themed item, or an item with max affixes already. It also does that weird GREAT_EGO level boost, for a one-in-20 chance of a potentially huge level boost (though that doesn't boost the affix level yet - if it did, this would create interesting possibilities for randarts, noted below). Importantly, we copy the object, so we don't have to worry about affixes creating broken items - if that happens we just roll back and don't add anything. 
    5248 
    5349We choose which affix to apply in obj_find_affix, which is ego_find_random renamed and rewritten to allow for the new T: lines above. Like make_artifact, it builds an allocation table from the affixes which are legal for this item at this depth and affix level.   
     
    5854 
    5955=== Themes === 
    60  
    6156Without themes, we can have very powerful items, but they're like randarts - random collections of attributes. Themes allow us to decide, during an item's creation, that it's going down a particular path. So I wrote ego_themes.txt, which sets out what these themes are. At the moment they're all recognisable, because they're the high-end/compound egos I removed from ego_item.txt earlier on. 
    6257 
     
    7368If we have three of the resists, we have weight of 21, which is multiplied by 84/34 to give 51% chance of acquiring the theme.  
    7469 
    75 If we have all four resists, we have 28, multiplied by 112/34 to give a 92% chance.  
     70If we have all four resists, we have 28, multiplied by 112/34 to give a 92% chance. (If we tweaked the weightings of Durable and Reinforced down to 2 and 1 respectively, this would be over 100%, which is probably what we want.) 
    7671 
    7772By contrast, if the two affixes we have are Reinforced and Durable, we have weight of 6, which is multiplied by 24/34 to give a 4% chance of acquiring the theme. Both of them and one resist makes 19% - less useful than having two of the resists.  
     
    8176Blessed weapons have three affixes, but one of them has a weighting of zero (of Dweomercraft, the one which provides the random ability - also on Gondolin and *Slay* Evil weapons, Lothlorien bows etc.). This means it doesn't contribute to the weighting, but it is applied in obj_apply_theme after the theme is chosen. This function simply cycles through all the affixes in the theme and applies all the ones that aren't already on the item. Since you can specify the same affix more than once in a theme (e.g. for extra combat bonuses, or extra random flags), we allow the second and subsequent ones to be applied.  
    8277 
    83 Note that obj_apply theme doesn't actually set the o_ptr->affix for the affixes it applies. This is deliberate: many themes have more than MAX_AFFIXES. Also, once we acquire a theme we're unable to modify the item further (like an artifact), so it doesn't really matter too much. Note also that branding spells *will* (currently) work on non-themed items, providing they have < MAX_AFFIXES. I like this, but others might not. 
     78Note that obj_apply theme doesn't actually set the o_ptr->affix for the affixes it applies. This is deliberate: many themes have more than MAX_AFFIXES. Also, once we acquire a theme we're unable to modify the item further (like an artifact), so it doesn't really matter too much. Note also that branding spells *will* (currently) work on non-themed items, providing they have < MAX_AFFIXES. I like this, but others might not (more below). 
    8479 
    8580=== ID, naming and saving === 
    86  
    8781ID-by-use works reasonably well for affixes, though I had to write object_affix_is_known to check from first principles whether we know all about an affix. The IDENT_ flags don't work because we don't know how many affixes we're trying to know, and I decided against recording o_ptr->known_affixes in favour of working it out on the fly. object_theme_is_known is just a wrapper which makes sure that we know all the affixes in a theme. This is pretty basic but actually seems to work ok - both magical ID and ID-by-use seem to work ok, and the ego knowledge menu shows affixes once they're known (it doesn't talk about the new mods to weight/base AC/dice/sides, but otherwise works ok).  
    8882 
    89 Finally, with noz's help, we sorted out the prefix and suffix names of the object, which are the theme or the best affixes in the absence of a theme (so you can get Emerald weapons of Gondolin, or Broken ones, etc.). There is still some thinking to do here in relation to ID and naming, some of which was discussed on IRC (d_m/fizzix suggested "synthetic" affixes which change the name but no properties - this seems like a good solution, but it would be a shame to lose all the occurrences of the affix names). 
     83Finally, with noz's help, we sorted out the prefix and suffix names of the object, which are the theme or the best affixes in the absence of a theme (so you can get Emerald weapons of Gondolin, or Broken ones, etc.). There is still some thinking to do here in relation to ID and naming, some of which was discussed on IRC (d_m/fizzix suggested "synthetic" affixes which change the name but no properties - this seems like a good solution, but it would be a shame to lose all the flavour of the affix names). 
    9084 
    91 The savefile now stores the indeces of the theme (in the old o_ptr->ego->eidx slot) and the affixes. I also took a cue from Gabe and we now record all of MAX_PVALS, MAX_AFFIXES, OF_SIZE and OF_BYTES in the savefile, so if they change we don't have to write a new function. Oh, and we also store o_ptr->extent, which is food/fuel/charges/gold/chest level, fixing #1540. 
     85The savefile now stores the indeces of the theme (in the old o_ptr->ego->eidx slot) and the affixes. I also took a cue from Gabe and we now record all of MAX_PVALS, MAX_AFFIXES, OF_SIZE and OF_BYTES in the savefile, so if they change we don't have to write a new function. Oh, and we also store o_ptr->extent, which is food/fuel/charges/gold/chest level, fixing #1540. Ego items in old savefiles will retain all their actual properties (flags, plusses etc.), but will lose their names. I'm happy to write a converter to restore these names if people think it's important, but it looks like we might be heading for major savefile breakage for 4.0 anyway. 
    9286 
    93 === Bugs, issues and to-do === 
     87== Next steps post-merge == 
     88=== Code cleanup === 
     89I need to get rid of remaining references to o_ptr->ego and remove it from the object_type struct. Also renaming ego_stuff to affix_stuff would be helpful - I've been a bit lazy about this, in case the whole thing was rejected. I also need to write accessors or #defines for things like AFFIX_IS_PREFIX and so on. 
    9490 
    95 I need to get rid of remaining references to o_ptr->ego and remove it from the object_type struct. Also renaming ego_stuff to affix_stuff would be helpful - I've been a bit lazy about this, in case the whole thing was rejected. 
     91I'm also wondering whether it's possible/desirable to de-globalise the themes[] and e_info[] arrays, and make them local to obj-make (or wherever). I don't know enough about C to know how important or difficult this would be. Similarly, there are lots of comments in the code about making arrays read-only (e.g. #1202) - again, I'm not sure I really understand this issue properly. 
    9692 
    97 The knowledge menus need sorting: first they need to show details of the new mods from affixes (base AC / weight / dice / sides - random flags should already work). Then we need a new "theme knowledge" menu about themes - I don't think I have the skill to do this, yet. Also, theme->everseen is not currently set anywhere. Come to think of it, neither is affix->everseen, so I'm not sure how the knowledge menu is still working for affixes! 
     93We need to confirm that we're happy with Durable, and don't want four separate affixes for the IGNORE_ flags. No reason this can't be done, just seems overkill to me. It does stop us reproducing certain egos exactly though. 
    9894 
    99 We need to agree a strategy for naming items with multiple affixes. Personally I favour adopting the position that an object's displayed name does not give you complete information about all its properties, but others may disagree. Also, affixes can be applied more than once (meaningless for flag affixes, but important for hit/dam/ac etc.). I like the idea of Sharp, *Sharp* and **Sharp** or something, to denote multiple applications of an affix. 
    100  
    101 We also need to agree a strategy for the names of base objects for armour. Weapons are now all sorted (there are no prefix-like adjectives in weapon names, and no "of"s). But we are significantly limited in the kinds of affixes we can invent for Leather items, for example. And Mithril is already an affix for body armour (from Ey), but we still have Mithril shields/boots/gauntlets etc. IMO it should be an affix available for all armour pieces, but that means re-thinking the names of most base armour items. We could make Ethereal an affix, and Alchemist's. We could remove Elven Cloaks too. 
    102  
    103 My original intention was that themes were more random, i.e. that not all affixes in a theme would be applied every time. I didn't implement themes like this because I didn't want the outcry of "my Gondolin weapon doesn't have RES_DARK" etc. But I still think it would be good to have more variation.  
    104  
    105 IMO we should no longer show the base AC or dice of an object, because these are no longer so static - lots of the Ey prefixes change one or the other. This fits nicely with reducing the amount of info available and forcing people to walk over a fetch stuff. 
    106  
    107 We also need to refine the IDing of affixes and themes, but this needs discussion after both Eddie's patch improvements and rune-based ID. I have defined IDENT_PREFIX and IDENT_SUFFIX, but these aren't used yet (we use obj_affix_known instead). 
     95=== Knowledge and ID === 
     96The knowledge menus need sorting: first they need to show details of the new mods from affixes (base AC / weight / dice / sides - random flags should already work). Then we need a new "theme knowledge" menu about themes - I don't think I have the skill to do this, yet. Also, theme->everseen is not currently set anywhere. Come to think of it, neither is affix->everseen, so I'm not sure how the knowledge menu is still working for affixes! (Also, fizzix reports that the object knowledge menu crashes now - fixing this is a priority.) 
    10897 
    10998We need description/flavour text for affixes and themes. (There was very little for any existing ego types anyway, so this has long been the case.) 
    11099 
    111 We need to confirm that we're happy with Durable, and don't want four separate affixes for the IGNORE_ flags. No reason this can't be done, just seems overkill to me. It does stop us reproducing certain egos exactly though. 
     100IMO we should no longer show the base AC or dice of an object, because these are no longer so static - lots of the Ey prefixes change one or the other. This fits nicely with reducing the amount of info available and forcing people to walk over a fetch stuff. Interested in people's thoughts on this (and see also #1551). 
    112101 
    113 Finally, of course, there's a ton of balancing tweaking to be done. Some affixes are available on items which weren't before (e.g. of Warding), and others aren't (e.g. of Dweomercraft), purely because of what I was testing when I added them. Mithril shields don't seem to be able to acquire any affixes at all! Doing this balancing means adjusting the stats code to record affixes and themes (it already records all the info). 
     102We also need to refine the IDing of affixes and themes, but this needs discussion after both Eddie's patch improvements and rune-based ID. I have defined IDENT_PREFIX and IDENT_SUFFIX, but these aren't used yet (we use obj_affix_known instead). One question is whether we should display the best *known* prefix or suffix, rather than not display any unless the best is known. It would seem odd for an item to change its name as you discovered more about it, but maybe that's preferable to the current behaviour. 
    114103 
     104=== Naming and base items === 
     105We need to agree a strategy for naming items with multiple affixes. Personally I favour adopting the position that an object's displayed name does not give you complete information about all its properties, but others may disagree. Also, affixes can be applied more than once (meaningless for flag affixes, but important for hit/dam/ac etc.). I like the idea of Sharp, *Sharp* and {{{**Sharp**}}} or something, to denote multiple applications of an affix. 
     106 
     107We also need to agree a strategy for the names of base objects for armour slots. Weapons are now all sorted (there are no prefix-like adjectives in weapon names, and no "of"s). But we are significantly limited in the kinds of affixes we can invent for Leather items, for example, because material adjectives would make no sense. And Mithril is already an affix for body armour (from Ey), but we still have Mithril shields/boots/gauntlets etc. IMO it should be an affix available for all armour pieces, but that means re-thinking the names of most base armour items. We could make Ethereal an affix, and Alchemist's. We could remove Elven Cloaks too and use Eleven as a cloak affix and not a weapon one. The whole issue of "Elvenkind" stuff needs some thought - at the moment it appears on all of base items (cloaks), affixes (swords, bows) and themes (body armour, boots - both different).  
     108 
     109=== Randarts and randomness === 
     110I haven't thought too much about randarts while I've been focused on this work, but it occurs to me that the GREAT_EGO check would be an interesting mechanism for generating randarts (since it could lift the affix level from "uber" to "artifact"). These would then be in addition to standarts, rather than instead of them - something a lot of players have asked for (and happens in many other variants and roguelikes). This could be combined with my other approach of randomising some but not all attributes of standarts - the two are not mutually exclusive. 
     111 
     112My original intention was that themes were more random, i.e. that not all affixes in a theme would be applied every time. I didn't implement themes like this because I didn't want the outcry of "my Gondolin weapon doesn't have RES_DARK" etc. But I still think it would be good to have more variation. If we want to use themes to guide randart generation, this would become more important. One way is to add a third field to the A: lines in ego_themes.txt and specify the percent chance of adding that affix during obj_apply_theme. We could keep the wolves at bay by ensuring that these were all 100 for the traditional ego types.  
     113 
     114=== Object modification === 
     115This branch opens up a lot of possibilities w.r.t. alchemy, forging etc. (See also #1550). Nothing to worry about immediately, except whether to retain  or remove the branding spells/prayers. Arguably the prayer (for branding melee weapons) is now actually useful where it wasn't before. It's probably too powerful because you could eventually add all three brands to an object that already had decent affixes - so I'm inclined to add a check to make sure that the object doesn't already have a brand. The ammo branding spell was already too good, and is probably even more so now (but we could always temper it by making it reduce o_ptr->number by 50%, or something like that). 
     116 
     117My view remains that we should allow spells and effects to modify objects, and just be careful to limit their power. (We could use a limit lower than MAX_AFFIXES, for instance.) 
     118 
     119=== Balancing === 
     120Finally, of course, there's a ton of balancing tweaking to be done. Some affixes are available on items which weren't before (e.g. of Warding), and others aren't (e.g. of Dweomercraft), purely because of what I was testing when I added them. Doing this balancing means adjusting the stats code to record affix and theme indeces (it already records all the actual item info). I am quite happy for people to crawl all over ego_items.txt and ego_themes.txt and adjust all the T: lines, as I have not spent long checking what affixes are available on which items at which depth and affix level: mithril shields don't seem to be able to acquire any affixes at all!  
     121 
     122But please note that I *have* spent quite a long time ensuring that the themes are generatable with roughly the same relative rarity as their predecessor ego types, and any changes to the affix weightings on the A: lines need careful thought. 
     123 
     124I also think that we need to check the balance between obj_alloc (the allocation table for all objects) and obj_alloc_great (the one for "good" or "great" objects). Some potions/scrolls with the OF_GOOD flag may now be too common, and some others perhaps ought to get it (and some devices). 
     125 
     126=== Other issues === 
    115127A bunch of things occurred to me while doing all this stuff (I'll make tickets) 
    116128* the slay cache can now go, as we're not constrained to a small number of slay combinations which are worth caching