Combat System Design

Page last edited 3,690 days ago
From Artisan
Jump to navigation Jump to search

UML Diagram for combat system[edit | edit source]

Combat System on LucidChart

Requirements Revisited[edit | edit source]

From Project Requirements 1.0.0: "We need to be able to show the player's character fighting enemies in an exterior environment. This must feature item(s) created through the Item Creation System."

  • Enemy - rigged character and behavior
  • Animations - player character, enemy, and items
  • Develop unique fighting system
  • Visual Effects
  • It must be rule-based
  • It must be easily understood by the player.
  • It must be fun.

Overview of Design Elements[edit | edit source]

The Combat System will consist of a basic class hierarchy including interacting Fighters (Players or Enemies) that can use the specially made Items (including Weapons) that are unique to our game. see Combat Design on Lucidchart

  • To make the combat system easily understood, we are aiming for a certain degree of realism. To do this, we will avoid arcane or cryptic action-consequence sequences, but instead will have a basic cause-and-effect type of engine that builds off of the attributes of Items and how they are used. In this way, gameplay will be easy to understand and learn but will still be challenging for the player to solve individual combat scenarios (the "puzzle" element).
  • To make it fun ...
  • In an effort to get rid of the boring "hit point" approach, we have devised an injury system (the InjuryMonitor) that takes injurious effects into account, including (but not limited to) attacks from combat, and applies their effects to each Fighter. These effects include varied intuitive ailments, such as a limp from fatigue or recoiling with pain, slowness due to loss of blood, and even death.
  • For purposes of our current development efforts, Melee attack is a green feature while Magic attacks and healing are yellow.

Player[edit | edit source]

Melee Combat[edit | edit source]

We will focus on longsword combat or any sword with the same mechanics as longsword-style combat.

Weapons[edit | edit source]

Gameplay combat is heavily focused on the choice of weapons crafted at the forge. We will focus on different weapon blade styles and material use for the demo. For example, dragon scales can be very hard. One can use a special material to cut through these tough scales. Also, some dragons can heal rapidly. Perhaps a serrated blade lined with a potent venom will slow the healing process and allow the player to defeat the foe.

Attack[edit | edit source]

To simplify animation, the player will perform Elder's Scroll's style attacks. That is, attacks will be done in the diagonal for regular attacks = \/ For powerful attacks, the player can also attack from the sides, but will attack much slower = -><-

Weapons made at the forge will have a variety of damage / attack speed trade-offs. To craft weapons which posses a great abundance of either will be impossible.

The weapon will perform damage only if the combatant hasn't blocked, dodged, or parried the attack. See defense.

Defense[edit | edit source]

For this demo, the player can only parry or dodge melee attacks. A parry can be performed by using the alternate-attack button. A dodge can be performed by moving the player with the movement controls. Some attacks cannot be dodged or parried. For the demo, neither of these attacks will be present.

Ranged Combat[edit | edit source]

Player ranged combat is on hold until after the demo.

HUD[edit | edit source]

What does the HUD look like? What do we see? I am thinking of an elder's scrolls-style experience here.

AI / Enemy[edit | edit source]

Melee Combat[edit | edit source]

For the demo, we are looking for the killing-the-rat-in-the-dungeon-style experience for the time being and build up from there. That is to say, we are going to have bites and scratches as attack.

Attack[edit | edit source]

The enemy can attack using bites and scratches. Bites are much faster, but less effective. They are useful to disrupt a player when trying to attack, but not much else. Scratches are more effective, but can be interrupted by player attacks.

Defense[edit | edit source]

The enemy can defend itself by running away from the combatant or circling around the player. The enemy can "dodge" an attack if it can get sufficiently out of range from the attack radius. The enemy can also "parry" an attack if it's attacks successfully disrupt an attack made by the player.

Design Review / Open Questions[edit | edit source]

  • How does the character recover health and status after he is injured? (yellow; we probably won't show this during the demo. But see David's excellent design document linked also below, for a description of the health recovery system )
  • Definitely there will be critters with poisonous bites... (but again, yellow; probably won't show in demo)
  • Targeting: Context-sensitive attacks? (Critter just lunged at you, putting his neck in a vulnerable position; you can exploit this vulnerability with a special attack)

Quote from Bryce: I think the combat should be more reflective of the items you create: if your items don't fit the bill, you don't win. ... I just don't want to lose sight of the puzzle-game aspect that the item creation introduces. There won't be any pre-scripted answer to any given solution, but the player still needs to invent something, without a provided recipe, for solving the problems they face.

  • The graphics realism was defined pretty well by Bryce when he came down from Logan for our team meeting. However, there are still unanswered questions about how realistic the game itself is going to be, so it's a valid point--how realistic do we want to make the combat system? Ideally there are probably lots of bells and whistles, but for the demo maybe let's focus on just the unique effects of each individually-crafted item?

(SethS): Yeah, we're not concerned about making things photorealistic from a graphics perspective, and so we're also not worried about making animations, etc. physically correct per se - the main thing is to maintain conceptual integrity by having the visual effects and combat interactions etc. consistent with the aesthetic design of the game. This simply entails back-and-forth interaction with the content team and immersion of both teams in both aspects. Unique effects will be added as we have room for them after the basics are implemented.

  • SethS: We'll need to keep it simple, but as far as realism is concerned, I think that winning a given battle needs to depend on both the properties of the item and the way the player uses it. If we accomplish that, that's probably as real as it needs to be. All the other cool effects, bells/whistles and things commonly done in the industry we can safely ignore until we accomplish this first fact.

As far as scoping the combat system, perhaps we should start with one action available to the player: a simple aimed strike of his weapon against the enemy (determined by the direction he is facing), with the effectiveness of the blow in slaying or disabling the enemy being proportional to some properties of the item in combination with a handful of the character's attributes.

See https://docs.google.com/document/d/1vZWeXC7355snBc-hlYUzpFhUdia2JeiR7tbHP8gUGwk/edit?usp=sharing for a description of what we are going to do with the combat system.

We have two URL diagrams, one that is more of a vision and one for the demo: https://www.lucidchart.com/documents/edit/43bd-efdc-53027f4e-993c-68800a008c55