ShapeShifting power Discussion

[igorko]

Related issue #265

Things to be discussed:

• Should we unlock Shapeshifter power, if hero doesn't meet power requirements?
• Should we turn back into human on some action? Or just wait until time ends?
• Shapeshifter animation looks not very good
• Granting to player additional stats on transform, depending on destination creature.

[igorko]

Enemy powers have no requirements, but they can use the same powers as hero too. The easiest way is to duplicate shared powers to "nonrequirement versions" and assign them to enemies.

As for additional stats easiest will be just to use creature stats (resists, avoidance, accuracy, chance_xx, etc), than revert back.

[clintbellanger]

Another quirk about monster powers and hero powers is the way that requires_los works.

requires_los = "Requires Line Of Sight". This is mostly for ranged powers. Wherever you click/target, do you need to be able to see that point on the map (no walls blocking) to use this power?

This ends up having two different meanings for players and enemies:

• If the player shoots a bow, it doesn't require line of sight
• If a creature shoots a bow, it does require line of sight

The creature is always targeting directly on the player, so the line of sight requirement is obvious: don't try to shoot the hero if you can't see him.

But it's more about the user interface for the player. The player does not have to click directly on a creature to shoot at it. The player can just click anywhere, and the hero will shoot in that direction.

Imagine the hero wants to shoot a skeleton. Behind the skeleton is a wall. Behind the wall is an empty room. Imagine the player clicks somewhere in the empty room. The hero does not have line of sight to that empty room (wall in the way), but he is really lining up a shot to hit the skeleton. It would be very annoying if the hero refused to shoot his bow because he couldn't see that empty room. So for the hero, we remove the Line Of Sight requirement on shooting a bow. The player can shoot any direction he wants. We know the arrow will die when it hits a wall, so it's not a big deal.

Now with shapeshifting, the player can use enemy powers. But we don't want to limit bow shooting to LOS clicks as mentioned above.

What probably needs to happen: separate this one "requires_los" into two different variables that reflect the above meanings.

[clintbellanger]

I think shapeshifting should have a time out duration. Some shapeshifts should allow manual canceling back to regular form.

Example: make a "revert to normal form" power. When the player voluntarily shapeshifts, put that power in the slot for key #0. Say the player wants to take on a form for combat, but needs to revert when he goes back to town (to talk to anyone).

But sometimes we don't want to allow the player to revert. Imagine we make a critter creature (e.g. a mouse) that scurries around maps but does not attack. Then imagine we create a Hexer creature that has the power to turn the hero into this mouse for 5 seconds. The hero wouldn't be able to attack, so he becomes very vulnerable until the shapeshifting wears off. In this case we don't want the ability to cancel the shape shift early.

I say we make shapeshifting a new base power type. It can have a boolean like "allow_revert" that determines whether the "revert to normal form" power is added to the action bar.

Incidentally this means we can think about how to structure shapeshifting so that it can be cast on self or on targets.

[pennomi]

I'm in favor of unlocking all of the shapeshifter powers, even if the hero doesn't meet power requirements.

There should be an option in the power config that displays a "revert" power in the action bar. On that same note, shapeshifting powers should be able to last any length of time, even permanently. (You'll want to allow revert on permanent ones, of course.)

I'm not sure what it will take to get the animations working properly.

I don't think all stats should be copied over, but some that probably should be are: elemental resists and flying/incorporeal. Probably the other stats should still be the player's.

[pennomi]

Clint, I disagree about shapeshifting being a new power type. Imagine a missile that changes something on hit, or an area of effect power that turns all affected creatures into something.

On the other hand, I suppose we could use the "on_hit" trigger for those types of powers as well, chaining a missile with a shapeshift.

[clintbellanger]

Note that many powers' damage output is based on the equipped weapon.

That could be problematic if a player doesn't have a bow equipped, but transforms into a creature holding a bow and using a power that requires bows.

It could also be problematic if a player doesn't have a melee weapon equipped (default 1-4 damage), but transforms into a creature with only melee abilities. Imagine transforming into this great big minotaur and doing terrible damage.

Maybe the creature's damage amount should be copied over to the player temporarily? Maybe only if it's greater than what the player currently has?

Maybe turn on the player's "wielding_offense" temporarily if the creature is using a bow etc.

[clintbellanger]

pennomi, that's true. Shapeshifting could be handled as a standard side effect with the ones listed here. https://github.com/clintbellanger/flare/blob/master/src/PowerManager.cpp#L684

Which, btw, I need to think of a better function name that encompasses what that function does. All the status effects that happen that aren't hazards/animations. Well, self-shifting can happen there, but targeted shifting maybe needs to be in a hazard.

[igorko]

pennomi, i think shapeshifting power can last permanently only if it's "cursed". This is nice idea for some quest, when you will need to find scroll to transform back. In all other cases it should depend on time: you pay some amount of mana for transformation, so it lasts only accordingly to spent mana

[pennomi]

igorko, Exactly what my thoughts are. :) Either way, the engine should support all options, so whoever's creating the game can decide that.

Think of a "polymorph trap" that when you step on it, you're cursed temporarily.

Think of something like Majora's Mask where you have to shift forms to solve puzzles. In that case, it would be annoying to have to keep shapeshifting to continue on your way.

But think of a druid power tree which allows temporary shapeshifting powers.

Really, if we make the power system customizable, the possibilities are nearly endless.

[clintbellanger]

Perhaps save files should have a line like shapeshifted=goblin to handle shifts without a timed expiration?

[igorko]

I have implemented manual untransform power and permanent transform option in my WC. Now one question should be answered: With permanent transform we should be able to save transformed hero in savefile. This is not a big problem. But what to do with nonpermanent transform. Should we still block saving the game during such transform? This can be done in three ways:

• If we allow saving hero in nonpermanent transformed state we need to add timer(?) so after game load we will be still transformed for the time is left
• We save transformed hero, but after load he became "untransformed". And he just transforms into creature right after load. This doesn't need to implement timer but needs to readd creature actionbar again after loading.
• We save transformed hero, and loading untransformed hero. But this introduces one bug: we save shapeshifter actionbar. So this needs another code to save initial (it's saved in array) actionbar instead of shapeshifter's, which will be saved by default.

My point is that first idea needs to implements some code and second is just more stupid, third is logical. But nonpermanent power will expire after some time (well, few minutes should be an extreme limit) so i would vote for still blocking saving ability for nonpermanent transformation powers. Anyway we can add "manual_untransform=true" (already implemented) for some very longterm powers.

[clintbellanger]

In the save file, can we say something like:

shapeshifted=enemy_name,duration

example:

shapeshifted=goblin,600

Then, loading the save game is two steps. Loading the base character as usual, then applying the standard transformation using the function already created.

[igorko]

Agree, but doesn't it look for you like overhead? We really should save permanent transforms. But do you really think that saving timedependant transform is needed at all? It's just time effect. You pay mana for transfom, and mana is recovered on game save/load. So for me it just doesn't have any sense. You can always transform again after loading the game, you not loosing anything.

In other hand blocking saving on transformed adds some "adrenaline", that you can't save the game atm.

[clintbellanger]

It's probably fine to let temporary transforms automatically expire, and don't save those at all. So it's okay to remove the duration part.

So the main overhead in the game load function is loading the character sprites. I'm sure we can skip loading the human sprites and just load the creature art if the player has a permanent transform in effect.

[igorko]

Here what i've done http://pastebin.com/7n3rXs38

There are two problems:

• hero is not shapeshifted after load (though transform() is called with right enemy name)
• we miss power definitions (e.g. manual_untransform) because we don't really call activate--transform from PowerManager. So we don't get revert button if it should be present, don't pay mana etc.

Dunno how to optimally fix this logic

[igorko]

Pull request #376 has unlocked using powers. Though i'm not really shure if we need such decision. I took a look at power descriptions: "effect" powers introduce some effects, but the damage of most powers is still based on hero characteristics (correct me if i'm wrong). So we don't improve damage, just adding effects. And i dont see keys to increase some characteristics in power descriptions. So e.g. turning into Minotaur to cause more damage will need to add more keys (combos) to power description, another creature abilities - add more new keys and more and more. Maybe someone has better idea?

[clintbellanger]

I would use temporary values (from the enemy) for melee, ranged, and magic damage when transformed IF the creature's damage is higher than the players. Otherwise I would use the player's default damage.

[igorko]

Looks like you mean int dmg_melee_min; int dmg_melee_max; int dmg_ment_min; int dmg_ment_max; int dmg_ranged_min; int dmg_ranged_max;

Maybe increase only max value?

and as proposed by pennomi attunement_fire attunement_ice

How about the rest? List becames really large but maybe we can get some use of it: int avoidance; int accuracy; // usefull for snipers int crit; int absorb_min; int absorb_max; // usefull for creatures with rough skin

[clintbellanger]

I'd say that for all those stats, if the creature's values are better, use the creature's values.

[pennomi]

Definitely the speed stat should be the creature's speed. I think that adds a lot of flavor to the transformation.

[igorko]

it's already there (except animation_speed, bacause i have no idea what it's used for)

Also note next stats (discovered while digging creatures descriptions): chance_melee_phys=15 chance_melee_ment=1 chance_ranged_phys=0 chance_ranged_ment=0 melee_range=72 threat_range=512 turn_delay=7 cooldown=25 cooldown_ranged_ment=150

Clint, could you say if we need them ? Some names are fuzzy for newcomer.

[pennomi]

Yeah, you won't need any of those, as far as I know.

animation_speed is necessary, though. It makes sure that fast creatures play their animation faster than equivalent slow ones.

[igorko]

speed and dspeed make animation(or move - is it the same?) faster.

[clintbellanger]

chance_* stats aren't needed. melee_range probably doesn't really matter. threat_range, turn_delay, cooldown* doesn't matter.

animation_speed does matter if we're copying over the creature's speed.

[igorko]

What is difference between (speed, dspeed) and animation_speed? I don't get. For me animation_speed didn't change anything.

[clintbellanger]

speed and dspeed are the movement speed (units per frame). dspeed is diagonal units applied to both axes when moving diagonally.

animation speed is a multiplier (default 100) that speeds up or slows down a base creature's animation. Example: Most goblins have the same animation so we use the same animation file for all goblins. But elite goblins tend to run faster. So we need their animations to play faster also (if their legs don't move faster, it will look like they are gliding along the floor). So we have an animation speed modifier to help fix the animation timing on slower or faster creatures. It's not a perfect system, and we might switch to a different system later.

[igorko]

Pull request #379 (merged) makes transformation system more-or-less complete. Saving the transformed hero is one issue remaining.(Saving is disabled at all so it doesn't introduce bugs). Please take a fresh look on my code and try to fix it (see paste above).

[clintbellanger]

For now, how about we say that saving always saves the hero's untransformed info (the hero's original statblock and pre-transform action bar). And loading always starts the character in default human mode. At least then we have a solid working version that makes sense in most cases.

[igorko]

Well, it can be easily done, but IMHO it will fully discredit the idea of permanent transform... Dunno...

[clintbellanger]

It's a good place to start. We can add transform save/load later.

One reason why we might want to keep permanent transforms across save/load is permanent curses. Although fun, that's not the highest priority right now. For most voluntary situations, the player can simply use the transform power again.

An idea though: when saving permanent transforms in the save file, instead of saving the creature name, save the transform power's ID. Then we can execute that power again, reusing the same transfom code with all the parameters (except the original statblock, if the power had side effects...)

[igorko]

Note to pull request #380. The only "revert" is line "// exit menu toggle" in MenuManager.cpp. In future it can be modified (or not) with:

• && !stats->transformed (for blocking exit menu for all transforms)
• && stats->transform_duration < 1 (for blocking exit menu in nonpermanent transform)

The rest code will be usefull anyway.

[clintbellanger]

Do we want to feature this for v0.16? How should we do that? E.g. add a Rotten Meat item that you can consume to become a Zombie for a couple minutes?

[pennomi]

Heh, I like the idea of the Rotten Meat. Maybe we could use your new scale hero as a "giant" and have a Giant's Belt artifact that can change you into an extremely powerful (melee) creature for a few seconds. It could have a cooldown of a minute or so and last for maybe 5 seconds.

[igorko]

Should we create new issue(marked as Feature) for Adding premanent transformation?

[pennomi]

igorko, yes, I think that would make sense. If possible, I'd like to have that feature before the end of the month for my LPC entry: https://github.com/pennomi/polymorphable

[igorko]

@pennomi All should work now. Please report if any problems will appear.

[igorko]

ShapeShifting works stable now and as no issues were reported, closing this.