-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initiative Tracker Character States #23
Comments
Some important conditions to consider for basic combat: Number of attacks of opportunity remaining could also exist as a property or condition of EncounterParticipants, reset on the participant's turn to a value 'max attacks of opportunity', taken/calculated from the character's combat stats. 'Flatfooted', a condition applied to all characters in an encounter which denies them their DEX bonus to AC and disqualifies the taking of attacks of opportunity (unless they have Combat Reflexes feat). Persisting until their first turn (duration = 1 round). The initiative tracker could/should apply this automatically to all characters. A "can't be caught flatfooted" option/flag could be added to the Character class, freeing the character from being given this condition by default. 'Surprised', in which certain characters might miss their first turn of the encounter - despite rolling a higher initiative than their opponents - if the encounter has caught them by surprise (e.g. as in an ambush). Other conditions, such as 'dazed', also prevent a character from taking actions on their turn. If initiative order is 'cycled', and the next character is one is affected by such a condition then a dialogue could be displayed asking whether the Initiative Tracker should simply cycle on to the next character, or stop at that point anyway. This might seem like overkill (as players wanting to cycle-past a character can simply press the cycle button again), however it may be a useful reminder to players/GMs that a character shouldn't be acting that round. Sidenote: Condition durations may be tricky, as some are not based on the affected character's turn-taking, but rather on turn-taking of the causal character. E.g. a cleric using 'gentle rest' on an enemy leaves them staggered for 1 round, which is until the beginning of cleric's next turn, denying the enemy their DEX bonus to AC during that time. The removal of the 'staggered' effect therefore must not occur on/after the enemy's turn, as characters taking their turn after this, but before the cleric's second turn, should be allowed to capitalise on the enemy's lowered AC. Because of this, conditions may need to have a notion of 'ownership', with the causal player (e.g. the example cleric) maintaining a reference to the recipient's condition so that the cleric object can 'clean up' expired conditions they caused. |
Conditions affecting 'to hit' and 'AC':http://www.d20pfsrd.com/gamemastering/combat#TOC-Combat-Modifiers Full list of conditions: Note about separately expiring conditions: This likely calls for EncounterParticipant class to contain a variable for each stat/attribute which could be modified. When a condition is applied, or expired, it updates its relevant variable accordingly. In the meantime, calculations do not need to worry about what conditions are applied to a character but instead can rely on them all having been factored in to the variable already. Attaching these modifier variables to EncounterParticipant bloats what is otherwise a very lightweight object, and only really makes sense if all associated conditions will definitely expire at the end of the encounter (or rather, the the ensuing time prior to the following encounter). Perhaps all conditions should be associated with CampaignCharacter? Or maybe a better model to use would be to have a separate table of 'Conditions', containing 'recipientCharacterId', 'causalCharacterId', 'effect' and 'duration'. Resetting an encounter could (optionally) remove all short-term conditions from participants. This model would then require calculations to query active effects frequently, which would be very inefficient. Some thought should also go in to magic weapon effects (both permanent effects on weapons as well as temporary effects, such as spells cast on a weapon) |
As I just mentioned in issue #20, the proposed tidying of character and party demarcation will allow for the EncounterParticipant object to track temporary states for the character.
Examples given were "prone", "blinded", or "dead", each of which have an effect on what options a character has, and need to be kept in mind.
The ability to associate with each condition a number of rounds it will last for would be extremely useful. The initiative tracker cycling button (issue #19) would allow the 'number of remaining rounds' for each state/condition to be reduced by one each time the relevant character is cycled-past.
The Initiative Tracker view could display some/all active states/conditions next to character names using icons.
Manual editing of states/conditions would also be important (to add, remove, prolong etc). To this end, select a character on the initiative tracker should not transition to a view in which character details can be edited (as is currently the case, prior to the model restructuring). Instead, an encounter member view should be presented, with brief details about the character (name, class, party name) and a list of states that are currently active, with their duration (if applicable). This view should offer the ability to remove all states/conditions, or allow individual states/conditions to be selected and removed.
The main Initiative Tracker view may also benefit from an 'apply states/condtions' type button, which could present the user with a state/condition drop-down list, and checkboxes for each character in the encounter. This alleviate the considerable game slow-down that would be involved with entering the state individually.
Resetting an encounter can reset/remove all states/conditions.
An extension of conditions could be to apply them based on a roll (e.g. Rolls Will save for selected characters and applies 'Fear' condition if they fail), however this isn't worth worrying about until a basic states/conditions system is in place.
The text was updated successfully, but these errors were encountered: