That does seem like a good idea from a bookkeeping perspective. My big concern would be handling message order, though. Presumably you'd do all effect messaging at a specific point during the world state update loop, and I suspect that would result in things like "You equip the Cloak of Acidproofing. The Kobold shaman is no longer slowed. Your items are shielded from acid!"
Targeting is an inherited trait that can be overridden. I tried to demonstrate that in my examples but I may have done a bad job. In short, an effect template can specify targeting, but so can an effect or even the object invoking the effect. That should reduce the degree of duplication.
Actually what I should probably do is just make effects be templates. So you can write an "incomplete" effect that leaves key attributes out, and then inherit from it and fill in the missing bits. Or grab pieces of your favorite effects and combine them. Whatever.
To state something more explicitly that I should have said earlier: each entity will have its "base stats", which are basically its permanent Mods; the "cached state" is the addition of all indefinite and temporary Mods to that permanent set. Not generating the cached set means that every time I want to determine if a fact is true of a given entity, I have to iterate over all of the Mods applied to that entity.
I do agree that there's a lot of potential for bookkeeping errors here, but I think it's possible to set up a system where they just don't happen, and the benefit will be that working with that system will be far more pleasant.
Okay, let's look at how resists work in specific. You can have:
* Permanent resistance. You're a fire elemental or demon or something; it's just a part of who you are. You get a permanent effect registered in your entity record.
* Indefinite resistance. You're wearing a Shield of Resist Fire. That shield has an onWield effect that applies resist fire to you.
* Temporary resistance. You drank a potion of Resist Fire. Its onUse effect set a 30-turn timer that gives you resist fire for the duration.
As far as defining things in the edit files, they'd all use the same basic effect ("apply resist fire"), but with different durations. Because of the hierarchical / inheritance-based approach to effect records, you can use as much or as little from an effect template as you like.
Now, things get hairy here mostly because Angband has a special hack where permanent + temporary resistance is its own thing that gives added protection. I'll have to figure out how that works at some point. It may well be that temporary fire resistance will be its own thing that just happens to do the same thing that permanent/indefinite resistance does, only stacking.
I definitely get where you're coming from here. It's all too easy to go from data-driven programming to "data is the programming". My goal here is to make a system that cleanly covers everything we can currently do with items, both in Vanilla and in variants. However, a lot of that "everything" is going to be Python -- basically everything that either a) is referred to in a "proc" field, or b) cares about the values that Mods set on an entity, will be Python.
In other words, the records in the edit files are just setting things up. They composite rules together, but those rules are all implemented only in the code. If you want new rules, you write new code.
Heh. Pyrel is currently at 1946 lines of Python, and if I do it properly it ought to be a reasonably pleasant introduction to the language. I've always wanted my projects to serve as good examples, as much as possible.
Assuming that Pyrel does get finished, I'm assuming it will act as either Angband 4.0 or its own "variant" (depending on how much gameplay diverges; the hope is, not much). I very much doubt it'd be worthwhile to try porting over extant Angband variants to it, unless it enabled things that you really really wanted to do that current Angband simply isn't up to.
Is targeting an intrinsic part of an effect? For instance, taking 3d6 fire damage might be a particular effect. It sounds like in your system the effect that targets one monster, versus a beam, versus a ball, versus "all evil creatures" would all be different effects.
Actually what I should probably do is just make effects be templates. So you can write an "incomplete" effect that leaves key attributes out, and then inherit from it and fill in the missing bits. Or grab pieces of your favorite effects and combine them. Whatever.
For the proof of concept I suggest you don't do any caching for now. In the long run you may want to but in the short term it will create lots of correctness bugs (IMO). And you may need less caching than you think.
I do agree that there's a lot of potential for bookkeeping errors here, but I think it's possible to set up a system where they just don't happen, and the benefit will be that working with that system will be far more pleasant.
I guess I find this to be shoehorning a lot of different concepts (and game logic) into one system. Is permanent resistance unrelated to temporary resistance at the effects level? Do they get to share names? What would the temporary resist's name be?
* Permanent resistance. You're a fire elemental or demon or something; it's just a part of who you are. You get a permanent effect registered in your entity record.
* Indefinite resistance. You're wearing a Shield of Resist Fire. That shield has an onWield effect that applies resist fire to you.
* Temporary resistance. You drank a potion of Resist Fire. Its onUse effect set a 30-turn timer that gives you resist fire for the duration.
As far as defining things in the edit files, they'd all use the same basic effect ("apply resist fire"), but with different durations. Because of the hierarchical / inheritance-based approach to effect records, you can use as much or as little from an effect template as you like.
Now, things get hairy here mostly because Angband has a special hack where permanent + temporary resistance is its own thing that gives added protection. I'll have to figure out how that works at some point. It may well be that temporary fire resistance will be its own thing that just happens to do the same thing that permanent/indefinite resistance does, only stacking.
Sorry for being critical. Overall I am really excited about your work, I just feel like you're going down the same path that a lot of the Java/XML people did in the 90's and early 00's (trying to move program logic into data files). If the effects data files are going to be really heavyweight I'd want to be able to use more of a language to express them (sort of the way you could imagine a lisp programmer doing it) and otherwise I'd want to maybe build a bunch of simpler concepts that compose more naturally.
In other words, the records in the edit files are just setting things up. They composite rules together, but those rules are all implemented only in the code. If you want new rules, you write new code.
Heh. Pyrel is currently at 1946 lines of Python, and if I do it properly it ought to be a reasonably pleasant introduction to the language. I've always wanted my projects to serve as good examples, as much as possible.
Assuming that Pyrel does get finished, I'm assuming it will act as either Angband 4.0 or its own "variant" (depending on how much gameplay diverges; the hope is, not much). I very much doubt it'd be worthwhile to try porting over extant Angband variants to it, unless it enabled things that you really really wanted to do that current Angband simply isn't up to.
Comment