Stopping village income after 10 villages

[Helmet]

Thanks for explaining $ and the other information, and for reminding me about [inspect]. I used [inspect] to watch the values of variables change as villages were captured, and that was useful.

I don't understand why this line doesn't work: equals=3. It seems pretty cut and dry.

Note: I had changed the max number of villages to 3 to make play-testing easier.

Code: Select all

   [event]
        name=capture
        first_time_only=no		

        [set_variable]
            name=side_$side_number|_villages
            add=1				
        [/set_variable]

        [if]
            [variable]
                name=side_$side_number|_villages
                greater_than=3
            [/variable]

            [then]
                [capture_village]
                    x=$x1
                    y=$y1
                    #  no identified side means village will become neutral
                [/capture_village]
                [variable]
                    name=side_$side_number|_villages
                    equals=3
                [/variable]
                [inspect]
                [/inspect]
            [/then]
        [/if]
    [/event]

I need to add some code to handle this eventuality: an enemy unit enters an opposing village and subtracts it from the village total. That will be the next challenge. Here is the code I expect to use. Somehow.

Code: Select all

#define OWN_VILLAGE X Y SIDE
    # Test if a given side owns the village at the specified location
    [have_location]
        owner_side={SIDE}
        x={X}
        y={Y}
    [/have_location]
#enddef

[beetlenaut]

I don't understand why this line doesn't work: equals=3. It seems pretty cut and dry.

In case you haven't figured it out yet, your equals=3 is in a [variable] instead of [set_variable].

[Helmet]

Gasp! Thanks.

I changed it but equals=3 still doesn't work. The number of captured villages still goes up and up, even though the villages beyond the third are made neutral. There must be yet another mistake.

* * *

Fixed it.

value=3 works.

[Ravana]

For objectives $| is the correct way so that variable is evaluated when viewing objectives not when setting objectives.

[variable] is not recognized subtag of [then].

[Helmet]

Thanks, Ravana.
I'm going to be more careful with subtags.

[lhybrideur]

Just my two cents but I think you need to add "delayed_variable_substitution=yes" in objectives so that the value displayed gets updated

[beetlenaut]

you need to add "delayed_variable_substitution=yes"

Yes, and I think that a person who is new at WML should use that tag in order to make their intent explicit. (In fact, I still prefer it despite not being new.) However, as Ravana pointed out, $| is a shortcut for including that key.

[Helmet]

I'm having a hard time understanding what "delayed_variable_substitution=yes" actually does, in simple terms.

Using $| as a shortcut for including that key is great, but it makes no sense to me. It's yet one more nebulous element of code that I copy from somebody without comprehending it at all.

Bad news: I realized recently that the AI doesn't take all this village code into consideration, so I probably won't use this code after all. Oh well.

That's the downside of tinkering with certain core structures of the game. The human player easily adapts to the altered ruleset, while the AI keeps doing what it always does.

I want the AI to be an artificial version of Gary Kasparov that plays BfW instead of chess. The last thing I want is to make the AI easier to beat.

[beetlenaut]

I'm having a hard time understanding what "delayed_variable_substitution=yes" actually does, in simple terms.

Ah, OK. Variables are switched out for actual numbers when the game is running. The [objectives] tag is in a prestart event, and before the game starts, the variable would probably have a 0 in it, which would normally be set into the objectives. The objectives would not have a variable in them anymore. That's not what you want. You want to delay that substitution until when the objectives are looked at, so it can reflect what will be stored in the variable at that later time.

Bad news: I realized recently that the AI doesn't take all this village code into consideration

But did you tell it to? There are several AI keys that refer to the value of villages, and you can [modify_ai] inside an event. You can turn them all down to 0 when the number of villages equals 10, but you can't expect the AI to figure out that it should do that on its own. I don't know how large a change you will see in the AI behavior, but you can give it a try.

I want the AI to be an artificial version of Gary Kasparov that plays BfW instead of chess.

That's what everybody wants, but it's not possible. A chess AI can check all the possible game states an arbitrary number of moves into the future. A BfW AI can't check any amount into the future because of the randomness. It's a far more complicated problem, and we don't have all the resources of IBM to work on it! The AI has gotten noticeably better since I started playing though.

[Helmet]

Ah, OK. Variables are switched out for actual numbers when the game is running. The [objectives] tag is in a prestart event, and before the game starts, the variable would probably have a 0 in it, which would normally be set into the objectives. The objectives would not have a variable in them anymore. That's not what you want. You want to delay that substitution until when the objectives are looked at, so it can reflect what will be stored in the variable at that later time.

That's pretty much what I originally assumed it did, but I must've made a mistake somewhere when using it and got a result that I didn't expect, so I decided I didn't know what it did after all. Thanks for the explanation, I'm glad it does what it seems like it should do.

But did you tell it to? There are several AI keys that refer to the value of villages, and you can [modify_ai] inside an event. You can turn them all down to 0 when the number of villages equals 10, but you can't expect the AI to figure out that it should do that on its own. I don't know how large a change you will see in the AI behavior, but you can give it a try.

Oh, I didn't realize that AI could do that. That's nifty. I'll look into it.

That's what everybody wants, but it's not possible. A chess AI can check all the possible game states an arbitrary number of moves into the future. A BfW AI can't check any amount into the future because of the randomness. It's a far more complicated problem, and we don't have all the resources of IBM to work on it! The AI has gotten noticeably better since I started playing though.

Absolutely! I've been playing BfW since the early days and I've always liked playing the AI. I agree, the AI is much better nowadays than in the past. This measured improvement over the years is especially impressive when considering all the additional complications that have been added to the game.

The AI is great at thinking 1 move ahead. I can surround a badly wounded unit to keep it alive, and the AI will still manage to kill it. Also, when I slowly and carefully get a friendly unit a few XP away from leveling, it's a virtual death sentence for that unit -- which is awesome.

I wish the AI could surrender, though. I think it would be nice if, at some point during a game it was losing, it might display a message that says something like, "Human adversary, you are crushing me. I resign. Why don't we start over and you give me 100 additional gold next time?"

[Celtic_Minstrel]

To answer your question: Sort of. You could get the village number by using [store_villages] then [foreach] to count the ones with a particular owner, but that's enough code that it would be likely to introduce even more errors.

???

Why do you need [foreach] here?

Code: Select all

[store_villages]
	variable=my_villages
	owner_side=$side_number
[/store_villages]
# Now just read $my_villages.length

(Also, neutral villages have an owner of 0, for the record… so if you really wanted an explicit side in [capture_village], you would use 0. Omitting it may be preferable though. I'm not sure.)