Tweet
So I'm going to try reimplementing v4's affix/theme system in Pyrel. It will probably take me forever, because my python is pretty basic and Pyrel's design is conceptually much more sophisticated than V's. But I do at least have the advantage of having done it once before, and being pretty clear what I want to achieve. It will be possible to configure affixes and themes for a perfect replication of V's limited ego item set (Antoine take note), while allowing all sorts of other configurations too.
IMO there are three things that need re-thinking about the current v4 system, so I'm setting out my thoughts here to see what everyone else thinks:
1. Affix types. In v4 I started off with two (prefix and suffix), and then fizzix suggested the splitting of prefix into make/material/quality. I think actually these ought to be more explicitly defined:
N:1:make:0:1
N:2:material:0:1
N:3:quality:min:max
N:4:arcane:min:max:mindepth:maxdepth
N:5: psionic:min:max:mindepth:maxdepth
etc. Pyrel doesn't have the limitations of V's parser, so we can in fact have as many min/max/depth tuples as we want (I can imagine limiting arcane or psionic affixes to 1 in the first half of the dungeon but allowing more later on).
2. Affix levels. I don't feel quite so strongly about this because there weren't such obvious issues with it in v4, but I think it might be helpful to put similar configuration around these:
N:1:bad:0:1:0:50
N:2:average:0:3:0:75
N:3:good:0:4:0:100
etc. There's a danger of overcomplication here (you could end up creating affixes that were impossible to apply without realising it), so needs thinking about how worthwhile it is. But it makes it a lot easier to fine-tune item quality levels (assuming I can write the code to handle it properly). Note that I am not yet thinking about randarts and artifact-only affixes: that will come later. First I'm just doing ego items.
3. Item names. This was by far the biggest failing of the affix system, so I'm going to try and have a solution in mind before I start. I think the way to do this is to define affix genera which are index names referred to by affixes. This means adding an extra field to the end of the N: line for each affix, e.g.
N:1:suffix: of Resist Acid: of Resistance
So when you have three or more affixes you can test for how many are of the same genus and use the generic name of the most common. This still won't solve the problem of the name not giving you all the item information, but I don't think anyone ever had a solution to that. It should make item names feel much less arbitrary and more intuitive. There is of course a challenge to come up with genus names that don't overlap with theme names, but that's achievable.
Finally, note that affixes in Pyrel will be able to do a lot more than just modify stats and provide resists/slays/etc. They'll be able to do on-hit procs as well (e.g. an affix for monster confusion on hit), and add directly to skills (MDS etc.). I don't yet think that this requires any fundamental changes to the system (of course it won't be relevant for the pure V implementation), but interested to know if anyone else does.
IMO there are three things that need re-thinking about the current v4 system, so I'm setting out my thoughts here to see what everyone else thinks:
1. Affix types. In v4 I started off with two (prefix and suffix), and then fizzix suggested the splitting of prefix into make/material/quality. I think actually these ought to be more explicitly defined:
N:1:make:0:1
N:2:material:0:1
N:3:quality:min:max
N:4:arcane:min:max:mindepth:maxdepth
N:5: psionic:min:max:mindepth:maxdepth
etc. Pyrel doesn't have the limitations of V's parser, so we can in fact have as many min/max/depth tuples as we want (I can imagine limiting arcane or psionic affixes to 1 in the first half of the dungeon but allowing more later on).
2. Affix levels. I don't feel quite so strongly about this because there weren't such obvious issues with it in v4, but I think it might be helpful to put similar configuration around these:
N:1:bad:0:1:0:50
N:2:average:0:3:0:75
N:3:good:0:4:0:100
etc. There's a danger of overcomplication here (you could end up creating affixes that were impossible to apply without realising it), so needs thinking about how worthwhile it is. But it makes it a lot easier to fine-tune item quality levels (assuming I can write the code to handle it properly). Note that I am not yet thinking about randarts and artifact-only affixes: that will come later. First I'm just doing ego items.
3. Item names. This was by far the biggest failing of the affix system, so I'm going to try and have a solution in mind before I start. I think the way to do this is to define affix genera which are index names referred to by affixes. This means adding an extra field to the end of the N: line for each affix, e.g.
N:1:suffix: of Resist Acid: of Resistance
So when you have three or more affixes you can test for how many are of the same genus and use the generic name of the most common. This still won't solve the problem of the name not giving you all the item information, but I don't think anyone ever had a solution to that. It should make item names feel much less arbitrary and more intuitive. There is of course a challenge to come up with genus names that don't overlap with theme names, but that's achievable.
Finally, note that affixes in Pyrel will be able to do a lot more than just modify stats and provide resists/slays/etc. They'll be able to do on-hit procs as well (e.g. an affix for monster confusion on hit), and add directly to skills (MDS etc.). I don't yet think that this requires any fundamental changes to the system (of course it won't be relevant for the pure V implementation), but interested to know if anyone else does.