Generalised adjacency/ZoC effects

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderator: Forum Moderators

Forum rules
Before posting a new idea, you must read the following:
Post Reply
CyberJack
Posts: 161
Joined: November 25th, 2004, 2:50 pm
Location: UK

Generalised adjacency/ZoC effects

Post by 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 :twisted:
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
Posts: 88
Joined: July 19th, 2004, 7:33 pm
Location: Cambridge, MA
Contact:

Post by 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
Posts: 5242
Joined: May 12th, 2004, 12:35 am
Location: Alexandria, VA

Post by scott »

It basically opens the door to any type of mage you could dream of. Wow.
Hope springs eternal.
Wesnoth acronym guide.
Woodwizzle
Posts: 719
Joined: December 9th, 2003, 9:31 pm
Contact:

Post by 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
Posts: 1200
Joined: November 17th, 2003, 4:26 am
Location: Right behind Gwiti, coding

Post by Circon »

Modular code. Good. Thanks for volunteering to code this feature.
User avatar
turin
Lord of the East
Posts: 11662
Joined: January 11th, 2004, 7:17 pm
Location: Texas
Contact:

Post by 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.
For I am Turin Turambar - Master of Doom, by doom mastered. On permanent Wesbreak. Will not respond to private messages. Sorry!
And I hate stupid people.
The World of Orbivm
scott
Posts: 5242
Joined: May 12th, 2004, 12:35 am
Location: Alexandria, VA

Post by 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
Hope springs eternal.
Wesnoth acronym guide.
Kamahawk
Posts: 583
Joined: November 9th, 2003, 11:26 pm
Location: Foggy California

Post by Kamahawk »

Personaly I think this is a great idea.
My contributions to the Wesnoth Project over time are inversly proportional to the number of registered forum users!
Piet Hein wrote:Knowing what thou knowest not is in a sence Omniscience
CyberJack
Posts: 161
Joined: November 25th, 2004, 2:50 pm
Location: UK

Post by CyberJack »

scott wrote: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
Posts: 1109
Joined: August 28th, 2004, 10:02 pm

Post by silene »

CyberJack wrote: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.
CyberJack wrote: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
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:

Post by 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
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
Post Reply