CONSIDER - Config for "Turn based combat"

[Volte6]

Currently combat is round based, which plays out automatically as rounds progress.

This task is to investigate ways to support a "Turn based" combat system where all decisions are locked in before the next round of combat takes place.

Considerations:

• Infinite lock waiting for a player too decide. Should time out and continue?
• Players or mobs entering/exiting combat will affect things. Consider a "combat bubble" to track who is in a given combat.

[MorquinDevlar]

You might also want to consider a twitch based version, where NPC attack follow the turn based as now, but player inputs are not automatic. Some players prefer the interactiveness of twitch based combat.

You might also consider a hybrid where some attack are automatic and others require interaction from the player.

[JeremyDOwens]

A simple step toward enabling this might be focusing on the "combat bubble". What do you think about introducing the concept of a phase? The primary phase is the world as exists now, but any number of additional phase instances with various rules can exist at the same time.

A simple prototype could include an admin command that allows the character to shift into a different phase (with a unique identifier). This prototype phase would simply make the character visible (with a modifier e.g. "shrouded in mist") but disable the ability to interact with things in a different phase, or be interacted with.

[Volte6]

I need help understanding the purpose and role phases play... are they "combat phases"? or individual phases (the mist example sounds like a phase of matter, and a character shifting into mist sounds like its character specific).

Or is it just a term that describes how a given combat bubble's state exists?

[JeremyDOwens]

Mostly just a term to describe the combat bubble state, but something that can be reused in the future. I see it as being character (or object) specific initially. It's kinda like... alternate dimension, but I don't think it's something that needs to be instantiated concretely in that sense. It would manifest in terms of interactivity restrictions and mutators to signal to other people not in that phase that the person in the room isn't "all there". I think that phases are not instantiated as objects themselves, just a flag on a character or object. Lack of flag means.. primary phase. Which would dramatically simplify the addition and ensure backward compatibility.

If two characters (or objects?) are in the same phase and the same room they can directly interact with each other, otherwise not.
If a character is in a different phase, it will be assigned a mutator for the duration which affects how it is observed by others in the room in the primary, or another phase.

There are alternatives, but I think step 1 is solving the two requirements above. There needs to be a mechanism for a character (user or mob) to enter into a state in which its interactivity is limited to others participating in the event, be they other characters or objects. Additionally, that state must be communicated to those not in said state.

[JeremyDOwens]

This game: https://www.wakfu.com/en/mmorpg (assuming it's still like last time I played it) has a really interesting mechanic where turn-based tactics battles occur alongside open world exploration with multiple players. Combat is visible but... phased out.

[Volte6]

I see... actually that's not a bad idea.

I think the combat bubble in general is a very open ended concept... currently combat has no bubble, and everything is a free for all. once we have a combat bubble, we can build/maintain a look up of active combats and process combat that way.

The rules for entering/exiting combat can probably be maintained as they are with the combat bubble concept - a combat bubble does not have to be a single room.

There is still something to be said for players entering areas of combat, particularly with mobs, and somehow being accounted for. If the mobs are "in their own combat", do new players entering the room get a pass and walk by without issue? That makes things a little exploitable, especially for areas gated by mobs, so needs to be considered.

Mobs could be duplicated and combat takes place in a bubble that's a copy only, but reconciling that with the real world gets tricky...

If introducing turn-by-turn actions, this shines a light on a need for better combat AI:

For combat decision making (mobs), we may want some sort of state machine type of structure that represents the tree of decisions a mob may make during combat. A dumb example would be simply iterating through different decisions without thoguht (attack, attack, heal self, attack, attack, heal self...) but a more complex version may include conditionals.

This could just be a script, for sure... but there's also something interesting about keeping it generic enough that we could attach this state machine (or combat behavior script) to any mob by an ID... so basic mobs may have a "Generic" combat state machine, whereas a more complex mob may cast spells, attack, call for assistance, run away, assist friends...

Or it can just be an optionally defined handler in any given mobs script "onCombatChoice()", and if not defined, fails over to basic behavior such as attack only.