Flexible Improved Necromancy

International board Development
#1

Currently the effects of the IMPROVED_NECROMANCY bonus are hard-coded to raise walking dead, wights or liches based on necromancy skill level. To improve flexibility I’d propose the following system:

  • Each IMPROVED_NECROMANCY bonus specifies target creature raised (val), and optionally minimum necromancy skill required (subtype) and minimum level of creature stack from which to raise (addInfo).
  • For each killed creature stack, the game will consider all applicable IMPROVED_NECROMANCY bonuses, i.e. where minimum skill and stack level conditions are met.
  • Among potential target creatures, the most powerful one (level & cost) is chosen.

So e.g. the Cloak of the Undead King could be specified as

"bonuses" : [
	{
		"type" : "IMPROVED_NECROMANCY",
		"subtype" : 1, // requires basic necromancy
		"val" : "creature.walkingDead"
	},
	{
		"type" : "IMPROVED_NECROMANCY",
		"subtype" : 2, // requires advanced necromancy
		"val" : "creature.wight"
	},
	{
		"type" : "IMPROVED_NECROMANCY",
		"subtype" : 3, // requires expert necromancy
		"val" : "creature.lich"
	}
]

but (for balance reasons) one could mod these bonuses to restrict these effects by creature stack as well, e.g.

"bonuses" : [
	{
		"type" : "IMPROVED_NECROMANCY",
		"subtype" : 1, // requires basic necromancy
		"addInfo" : 2, // requires stack of level 2+
		"val" : "creature.walkingDead"
	},
	{
		"type" : "IMPROVED_NECROMANCY",
		"subtype" : 2, // requires advanced necromancy
		"addInfo" : 3, // requires stack of level 3+
		"val" : "creature.wight"
	},
	{
		"type" : "IMPROVED_NECROMANCY",
		"subtype" : 3, // requires expert necromancy
		"addInfo" : 5, // requires stack of level 5+
		"val" : "creature.lich"
	}
]

Thoughts?

#2

I`m against using “val” for identifiers, creature id should be subtype

#3

Makes me uneasy as well, but we have 3 values to store and 3 fields. Happy to switch them around some other way, say subtype for target creature and val for required necromancy level.

#4

You could go further on bonus improvements and make “addInfo” arbitrary JSON node

#5

BTW. We already have few places where is not enough Bonus fields like that:

for(const std::shared_ptr<Bonus> sf : *spellsByType)
{
    vstd::amax(spellLevel, sf->additionalInfo % 1000); //pick highest level
    int meleeRanged = sf->additionalInfo / 1000;
    if (meleeRanged == 0 || (meleeRanged == 1 && ranged) || (meleeRanged == 2 && !ranged))
	castMe = true;
}
#6

That may be a cleaner way to go. Though I think having a flat mapping of string->int instead of arbitrary nested type would be sufficient and much simpler.

#7

Too cluttered, although a nice idea in general. Subtype = creature id is good. Necessary necromancy level is a good idea, but better located in the limiters section. So just add a limiter of type SECONDARY_SKILL, with subtype exact skill specifier, and val = skill level (exact level). That would be consistent. And if you add a propagator, this bonus could also be added to a creature as ability (maybe reaper?).

BTW, this limiter could be useful for other bonuses too. I think of extra bonuses for hero specialties based on availability resp. level of secondary skills.

#8

5 year old topic, has long been resolved, see e.g. vcmi-mods/artifacts.json at master · henningkoehlernz/vcmi-mods · GitHub