Latest revision as of 12:56, 30 December 2013

Main ideas

• Use logical expressions to allow construction of complex conditions out of simple ones
• Keep "logical expression" part generic enough to allow its usage in other areas (e.g. requirements for town buildings or any other allow/deny triggers)
• Merge victory conditions with lose conditions - "do not lose hero" can be turned into more generic "control object(hero ID)" and "capture town" into more generic "control object(town ID)"
• Json format so it can be used in future with map editor/json map format

Format considerarions

Why I prefer this format (see next section) over others:

• I'm using prefix notation here to reduce probability of errors and to avoid thinking about operations priority which may be needed in case of mixing "or" with "and" in one expression:

"victory" :
[
    "conditionA",
    "and"         // this can be evaluated first
    "conditionB"
    "or"          // or this one
    "conditionC"
]

• Json Vectors are used almost everywhere since json does not allows values with equal keys. Something like this is more logical but is not a valid json code:

"victory" :
{
    "allOf" :
    {
        "control" : { "position" : [0, 0, 0] }, // don't lose hero 1
        "control" : { "position" : [1, 1, 1] }, // don't lost hero 2
    }
}

Standard conditions:

"victory" :
[
    "standardWin"
],
"lose" :
[
    "daysWithoutTown", { "value" : 7 }
]

Current format

See Map format

Possible improvements to triggered events

• Expand effects to cover all possibilities of Seer Huts/Town events/Timed map events
• Add fields like "affected players" and "cooldown duration" similar to timed map events
• Use it to "patch" map to fix remaining campaign issues like Mantis 1635
• Possibility of multiple effects triggered by the same event
• Some way to implement "7 days without town" as "7 days since event "no owned towns" triggered"

List of victory/loss objectives

See List of all event conditions

Other areas for logic expressions

Mod dependencies

Not really necessary right now but it is possible to use them to specify more complex set of dependencies, e.g.

"requirements" :
[
    "allOf",
    [ "modA" ],  // "normal" dependencies - this mod requires mod A
    [
        "modB",  // dependencies with specific version limitations
        { "minimum" : "1.0.1", "maximum" : "1.2.9" }
    ],
    [
        "anyOf"  // at least one mod out of this list should be installed
        [ "modC" ],
        [ "modD" ]
    ],
    [
        "noneOf",  // essentially list of conflicts - none of these mods should be present
        [ "modE" ]
    ]
]

Building requirements

Already implemented in code

Something that was requested quite often, usually as part of alternative creatures in towns feature. Should be simple to implement compared to "main" area - campaigns. Will probably try to do this area first due to its small scale (less chance to mess up bigger systems).

Format is pretty much same as in previous cases:

"requirements" :
[
    "allOf", // Normal H3 "build all" mode
    [ "mageGuild1" ],
    [
        "noneOf",  // available only if dwelling 5 "A" was not built
        [ "dwelling5A" ],
        [ "dwelling5AUpgrade" ]
    ],
    [
        "anyOf", // at least one must be built
        [ "tavern" ],
        [ "blacksmith" ]
    ]
]