Generalised adjacency/ZoC effects

[CyberJack]

I was contemplating a unit with an "anti-illuminates" effect, and thought that it would be quite useful to generalise the existing ZoC effects, such as illuminates and heals, and allow such effects to be describes in WML. For instance, something like this

Code: Select all

[zoc_effect]
    id="illuminates"
    name="illuminates"
    [effect]
        apply_to="timezone"
        time="illuminated_time"
    [/effect]
[/zoc_effect]

would describe the existing "illuminates" ability, while this would give "leadership"

Code: Select all

[zoc_effect]
    id="leadership"
    name="leadership"
    [filter]
        side="own"
        level="lower"
        [effect]
            apply_to="attack"
            increase_damage="25%"
        [/effect]
    [/filter]
[/zoc_effect]

and so up up to the most complex existing ability

Code: Select all

[zoc_effect]
    id="cures"
    name="cures"
    [filter]
        side="own"
        poisoned="false"
        [effect]
            apply_to="hitpoints"
            increase="8"
            total_increase="18"
        [/effect]
    [/filter]
    [filter]
        side="ally"
        poisoned="false"
        [effect]
            apply_to="hitpoints"
            increase="8"
        [/effect]
    [/filter]
    [filter]
        side="own,ally"
        poisoned="true"
        [effect]
            apply_to="status"
            poisoned="false"
        [/effect]
    [/filter]
[/zoc_effect]

Of course, the real benefit comes not from being able to express existing abilities in WML rather than C++, but from the ease with which new abilities could be developed and explored. I've seen a few proposals for new ZoC effects; this would make adding them so much easier. For example, an advocate of a fear (anti-leadership) ability could easily write

Code: Select all

[zoc_effect]
    id="fear"
    name="fear"
    [filter]
        side="enemy"
        level="lower"
        [effect]
            apply_to="attack"
            increase_damage="-25%"
        [/effect]
    [/filter]
[/zoc_effect]

Or to go beyond just reversing existing abilities

Code: Select all

[zoc_effect]
    id="vortex"
    name="vortex"
    [filter]
        side="enemy"
        [effect]
            apply_to="movement"
            increase="-50%"
        [/effect]
        [effect]
            apply_to="attack"
            bonus_attacks="-1"
        [/effect]
    [/filter]
[/zoc_effect]

would give a unit a ZoC with a built-in "slow" effect
And so on through all the other attributes of a neigbouring unit that could be affected by a ZoC field effect.

Wadja think?

CJ.

[MRhe]

I don't know anything about the coding, but the idea sounds good.

Also an area-effect slow ability could be interesting...Sloth Mage?

[scott]

It basically opens the door to any type of mage you could dream of. Wow.

[Woodwizzle]

I like this idea because it can bring a large new variety of "spells" and other abilites. without breaking the current wesnoth philosophy of magic being implicit.

[Circon]

Modular code. Good. Thanks for volunteering to code this feature.

[turin]

I Wholeheartedly Support The Idea And/Or Endeavor.

now i just wish a coder will take a look at it. specialties being expressed in WML seems like a good idea to me.

[scott]

On the other hand....

It's not something the game needs
Adding code means adding bugs

Put it at the top of the post-1.0 list, unless it's easy like the [allow_undo] thing

[Kamahawk]

Personaly I think this is a great idea.

[CyberJack]

On the other hand....

It's not something the game needs
Adding code means adding bugs

Put it at the top of the post-1.0 list, unless it's easy like the [allow_undo] thing

With any luck, this might mean *removing* code , that is, all the dedicated code for implementing each of the ZoC effects.

I'm studying the source now ...

It certainly doesn't look trivial, because area effects come into play at several different times (start-of-own-turn, for healing; during battle, for leadership/illumination, etc). But I haven't figured out enough of it to say just how difficult it might be ...

<aside>
when a unit is healed by an allied healer, does that occur at the start of the healed unit's turn, or the healer's?
</aside>

[silene]

when a unit is healed by an allied healer, does that occur at the start of the healed unit's turn, or the healer's?

healed unit's turn.

But I haven't figured out enough of it to say just how difficult it might be ...

Very. The healing code is already 300-lines long. The lighting code is spread over a lot of files, same for leadership. The AI is bad at handling the effects at the moment, it would be even worse once a non-deterministic (since user modifiable) system is implemented. In order to take care of all the issues, the patch would be well over 1500 lines imo if done correctly. I don't mean it's impossible. Not at all. But you are not the first one to propose this system, and none of your predecessors ever reached the first line of a patch.
If you really want to take care of this project, I suggest you start tackling smaller issues to familiarize yourself with Wesnoth code. For example you could look for bugs in the healing code (is the "(unit_side > side)" condition really sane in actions.cpp:will_heal?) and reorganize it. Also take a look at the AI to see how to handle moving (since attached to units) zone of effects. Once you have clearly restricted the various Wesnoth zone of effects to a few places in the code, by a lot of small patches, it will get a lot easier to make a bigger patch go in (in fact, you would already have earned CVS access by that time).

[Dave]

I concur with silene.

I've actually had this kind of idea for a while now, but have been putting it off, since I think there are far more important things to do.

The main 'very hard' thing about this idea is designing a system that makes it feasible for the AI to use effectively.

And silene is completely right that a 1500 LOC patch has almost no chance of getting past the developers if it comes from someone who hasn't built up credibility with the development team (and by that time they would likely have CVS write access).

David