[Mod Schema] Adventure map objects

Is There is no schema for adventureMapObjects. Were there some discussions about it already?

What should such schema contain? Can be made generic to suit everything from a tree to a creature_bank for EG?

Some bits of this feature are on wiki. Check for “object format” page or something like that.
IIRC some discussions on this topic were on forum as well.

In general - right now no-one works on this and proper support will need some kind of scripting (or engine refactoring)

I have an idea about how this could work.

Each adventure object triggers an, or a series of “events”. These events can be for example:

  • Giving experience, primary skill points, secondary skills, luck/morale, movement/spell points, etc.
  • An artifact or resource reward.
  • A battle.
  • A requirement to hand over resources.
  • Opportunity to hire creatures.
    Events would be configured with JSON. Sometimes, a subsequent event will require that you “complete” the previous event in a specific way (for example, a reward event can require you to win a battle). Some events comes with a yes/no option. Some events can have random elements, with configurable probabilities.

This way, I believe most of the SoD adventure objects can be implemented (and modified). It would also be possible to make new interesting combinations, such as an object where you have to win a battle to gain a primary skill point.

If the developers think this is a good way to go about, I am willing to implement it some time in the future.

Not a bad idea.

You may want to check these links:
wiki.vcmi.eu/index.php?title=Object_Format (including talk page)

Some points to consider:

  1. In H3 there is separation between “object type” and “object instance”. E.g. Obelisks with terrain-specific images. How such relation can be represented in json?

  2. Perhaps some way to simplify creating of new objects that are based on already existing instead of copy-pasting everything? Including way to edit H3 objects via mods. This may need some sort of inheritance between objects.

  3. Look through object list and see if such idea is applicable to all/most of objects. Especially GUI reaction. Those that I can remember right now:

  • shipyard and dwellings may have same “events” but have quite distinct UI.
  • sanctuary: have effect when hero leaves object
  • flaggable objects that have permanent effect (use bonus system here?)
  • linked objects like teleports or keymasters + border guards.
  1. Bonus - consider how this can be used for town buildings that have same functionality as object (dwellings, shipyard, university, etc)

I won’t mind against such approach but you’d better wait for someone else from devs.

The general software engineering problem is to cover all possible building functions. Think about the following:

  • Markets, including Black Market, Trading Post, Altar of Sacrifice and other buildings that share same interface
  • Unique buildings, like Hill Fort, Den of Thieves etc.
  • Pyramid which subclasses Bank, but gives different reward. In general, handling of new Banks requires their config stored somewhere. This config, however, could and probably should be stored in json with no problems.
  • Border Gates that interfere with pathfinder

Honestly, I don’t believe it makes any sense to allow all of above in config. This would be better handled by scripts and json config should cover only standard, generic poperites, like graphics and occupied tiles. Everything else should be managed by deriving (or combining) base classes.

Also, one thing I wish to have is to split multiple-object classes from switches into separate subclasses of main class. Check CGBonusingObject::onHeroVisit class for example of solutions which is neither flexible nor readable (is much better than it used to, however).

Another problems to consider are handling new object by AI and RMG, possibly also editor in the future. Some combination of visitor pattern and traits seem necessary to handle all of them.

You’re probably right about that a scripting approach would be better. I had imagined to have trading post and such as a special kind of event, but that would limit such features to those currently in existence (a new kind of trading object made through mods wouldn’t be possible). But the real problem would be objects that do stuff when you don’t visit them - such as border gates, dwellings increasing population, and banks restoring guardians. While that could be modeled through configs, it would also limit the restocking mechanics a lot.

One of the points of my idea that I forgot to mention was that the AI would know from the config files exactly what each object does. A scripting approach would require explicit AI support in mods, but that cost, provided a useful AI-related API, would not be high.

Why not a mix of both? Some simple objects like garden of knowledge or temple may have config-only mechanics, some more complex may have hardcoded mechanics/script and config that contains only hardcoded ID/name of script.

So garden of knowledge may contain something like this:

    "type" : "ONCE_PER_HERO",
    "bonusType" : "knowledge",
    "value" : 1

While objects like black market will contain only ID:

    "type" : "ARTIFACT_TRADER"

Now add some way to chain such bonuses and you can get system flexible enough to model majority of objects and still AI-friendly.

If there is a script, than there is no AI handling. Look for WOG/ERA for example.
I think that to relate on scripts is to give up on AI.
Don’t think that most of map object created by modders will be complex.
Most of them can be covered by config setting:

  1. guard (may be several stacks)
  2. obstacles on field (may be hard to implement in json)
  3. reward (some resource, some units, some artefacts, some secondary or primary skill).
  4. some creatures selling (maybe 1-4 creatures).

simple creatures banks (I think that simple creatures banks must not be implemented as some new class of objects, but only as new properties in creatures itself.
For example, “dwelling”:“castle1/DwellingOfGoblins.def”, “dwellingGuard”:20

I think now VCMI developers may not try to add something new. It’s now possible only to realize already hardcoded dwellings functionality in jsons (like Ivan said).

WoG is not quite an example of any software engineering at all.

However, WoG is good example of complex map objects introduced with a mod.

So where did you get these ideas?

Most of them are very cheating. And they are not handled by AI.
I’m talking however about the majority of objects, simple enough to be handled by configs.
Seems that scripting will not emerge to 1.0, so I propose simplest wat to implement dwellings modding: to use already hardcoded mechanics, just translate it to configs.
WOG dwellings are implemented in VCMI? So their mechanics also will be available.

You propose? From what I see here only King_Crusher actually proposed to do something.

What’s the point of posting “I want this feature” in every modding-related thread? All developers already have more than enough things to do. Posts like this won’t change anything apart from spending our free time.

It won’t emerge to 0.94. This all that can be said for sure at this point.

“So where did you get these ideas?”

Only implemented objects from wog are those that have H3 counterparts - dwellings and probably creature banks. There is no mechanics to make available.

It’s not about “want this feature”, where I said “feature of dwellings needed”? It’s a thread discussing way of developing. I proposed way of developing - make already made things available as mods.
King_Crusher proposed scripts. Are they already there? No. What’s the difference from “I want this feature”?

You’re missing the point…
All your “propositions” sound like “I want this feature. Make it for me!” especially after getting response “Not now”. Or at least this is how your posts sounds like from my point of view.
While both propositions from King_Crusher end with words “I am willing to implement it some time in the future.”

Your “idea” to move mechanics to config was already proposed in 3rd post of this thread:
And implementing even this feature is far from trivial so your argument against scripts is invalid.

Anyway - let’s get back to topic and try to post only if it add something of value to discussion.

OK, let’s end this on my words “I am willing to implement it some time in the future”.

What’s about creature dwellings pointing in creature configs?

That sounds like a good idea. A benefit is be that series of events wouldn’t be needed - there could for example be an ID called “BANK”, where you would have to configure a batttle and a reward, and the game would handle everything else, including the Yes/No option where it asks you to battle.

I think event chaining is still needed to avoid over-complex “events”.
Compare garden of knowledge/star axis with school of magic. Both give you +1 to primary skill but school of magic gives you choice and you need to pay for training.
Implementing second one as chain would be more logical.

Or crypt - visiting already cleared crypt decreases morale. I don’t think that bank config should have “decreases morale on visiting looted bank” parameter.

Stables - they have two functions: movement buff + free upgrade for cavaliers. Why not split them into 2 independent events?