Combat enhancements: Difference between revisions

From PSwiki
Jump to navigation Jump to search
Landson (talk | contribs)
No edit summary
Landson (talk | contribs)
Line 141: Line 141:
*And it would also handle area of effect script, though since area of effect is a much more standard thing, it will not work like the other scripts, instead it will just pull and set data values that will (in a later part) be used by combatManager to determine who takes damage.
*And it would also handle area of effect script, though since area of effect is a much more standard thing, it will not work like the other scripts, instead it will just pull and set data values that will (in a later part) be used by combatManager to determine who takes damage.


==== Overall class level Design ====
==== Class level Design ====
[[File:AttackClassDesign.jpg]]
[[File:AttackClassDesign.jpg]]

Revision as of 13:26, 6 May 2011

GSoC 2011 > Combat Enhancement



The idea here is to give combat a little more flavor and variety than what is currently available. I feel combat should have multiple types and varieties of attacks. The most important part of combat in PlaneShift though is the roleplay. PlaneShift is unlike other MMORPG's in the fact that it is not a grind power fest, it is about immersing yourself in the game and being your character. So instead of the typical twitch style combat, I feel it is important to make the combat a roleplay experience in and of itself.

Combat Design

Current Design

PlaneShift today allows the players to engage combat with magic, with melee (like swords, axes, .. ) and with range combat (like bows). Players have the possibility to choose stances: full defense, defense, normal, attack, berserk, to tell the engine how much of their skills they want to use for defense or for attack. The monsters today always use normal mode. There is a table which determines the effects of each type of weapon vs. each type of armor. For example a knife will make more damage against a leather armor (which can be cut) than against a chain mail. All stats, equipment, skills, item stats and quality are considered in the combat sequence. The actual formulas are pretty complex, and give some realism to combat. Player can use 2 weapons, or a weapon and a shield. Players can use items to boost their stats/skills and fight better.

NPCs/Monsters can be:

  • invulnerable (in this case you cannot even attack them)
  • peaceful but able to fight back. They will not attack by themselves unless provoked.
  • attack on sight. They will attack as soon as you approach them.

When you attack a monster you enter in his hate list, and he will chase you and attack you. Combat is executed automatically by the server, the player can switch equipment, cast spells and move/run. If the player stands still in front of the monster, combat proceeds automatically until one of the two dies. Progression is done through increasing your skills, stats and gaining new equipment. This allows you to fight better and face harder monsters.

Goals

An Attack Style System

  • Attacks can only be executed in certain stances
  • Attacks that can only be executed by holding certain weapons
  • Certain armors maybe hindering power of certain attacks?

Queuing System

  • Attacks can be added to a queue through a hotbar
  • The attack queue would be shown in a UI element
  • if nothing is in the queue then the "normal" attack is used

Differentiate between range and melee

  • add a quiver equipment slot
  • Maybe the closer you are to the monster, the more damage the hit does; this gives range a unique mechanic in that your using it to be farther away and be safe, but getting closer will allow more damage, so you have to find the sweet point where you are far enough away to be safe, but close enough to do enough damage.

Special Effects

  • the idea here is to make some attacks have less power but have a chance at a special effect that will affect the outcome of a battle
  • one potential idea is poisoning....if your character is more of a villain, or a rogue type of character, they may prefer attacks that poison
  • temporary paralysis?
  • extra damage to certain creatures
  • ignore a percentage of armor
  • Boost current stats
  • always attack a certain target location
  • Do extra decay to an enemy weapon
  • This list would be a good start, as I said it would be easily extensible so more can easily be added.

Misc.

  • make single wielding and dual wielding matter, for instance a dual wielding attack may do half the damage per hit, or maybe even less but give a better chance at a special effect?

Technical Details

Goals and Deadlines

Part 1

Starts:.... Deadline: June 20th

  • Create the attack database and include a few example elements.
  • Design and implement a new combat manager(This will be a base, not the finished product, it will be changed and added to through out the rest of the process).
  • Implement the queueing system
  • Include the queue in the psCharacter, so that each character has it's own queue, required as part of combatManager.
  • Make CacheManager Load Attacks up from the database at startup
  • adjust the combat damage MathScript to allow for Multipliers
  • Create psAttack to as a data structure to hold the attacks in cache as well as in the queue, and to be used in combatManager.

By The End of Part 1, I expect combat to be useable much as it is today, it will be more of a base system without any real new features. But it is meant to be extendable to make rest of development easier.

Part 2

Starts: .... Deadline: July 20th (Slightly more tentative)

  • Implement the current list of special effects, try to find ways to make them generic and as easy to create as adding to the script(currently due to the way they are, it will require adding to other parts of the code for each effect)
  • Implement Area of Effect
  • flesh out the perquisite script.
  • Start to (possibly) collaborate with Zhan to create the UI elements
  • Create a player command system to allow users to choose attacks, this will allow the new attack system to be used in some way until the UI elements are complete.
  • Create the range/melee differentiation, possibly the distance factor as mentioned above.
  • Work on testing different possibilities of how decay could be changed to work with the new dual wielding system.
  • add some different attacks to the database, for testing over the next couple weeks after this part

By the end of this part I would like to have a fully functional combat system, not yet any UI elements, but working through commands.

Part 3

Starts: .... Deadline: August 10th

  • Would like to be done with UI Elements, however this is largley tenative on collaboration with Zhan or other's within the UI department. at bare minimum though I would like to have a hotbar element, as well as a element that shows items in the queue. At most I would like to possibly have a widget that shows a list of all possible attacks you meet the perquisites to use.


Part 4

Starts : August 10th Deadline: August 20th

  • This stage will be used soley for testing purposes, there will be no new features added.
  • This is where values will be adjusted to make sure everything stays balanced, as well as trying out as many attack types as possible to find possibly bugs and fix them.

Technical Designs

Currently Designing Part: 1

Combat Flow

Some Notes on Planned Changes :

  • Keep in mind this would be the first part of the full design. as stated in the above goals, I am breaking this job up into more workable parts, this part won't contain many changes that are actually noticeable in combat(other than maybe a change in the way dual weapons are handled). This part is simply meant to make the code to where it can more easily extend to what I'm wanting it to do (as well as add things such as the database and queueing system, below).
  • I am wanting to make dual wielding more of a specialist mechanic, I want it to have a place in role play as well as make combat more fun. At the moment I really feel like it simply is the most efficient way of fighting. See above on how I want to do this, but in this part I will make changes to set up dual wielding. It will likely be the only change that is noticeable while playing in this patch.
  • As stated in the chart, in this part energy calculations and it's role will remain the same, completely untouched. This may change later down the road, I'm still trying to decide how to make more powerful attacks cost more while maintaining the roleplay atmosphere. Making energy and integral part of the new attack system could be an answer.
  • I really want to separate range and melee logic in this part. This will not make a noticeable difference yet because they will be identical, however in a later part when I look at how to differentiate them it will make my job easier.
  • Decay will remain untouched for now, but will have to be looked at and changed later to make up for the fact that dual wielding will not behave the same.
  • attack calculation and application will remain mostly untouched in part 1, however they will be heavily looked at and changed later.

Fields in Attack Database

  • ID
  • Name: name of attack that should be shown in game.
  • Multiplier: some attacks may do more or less damage than the base attack this multiplier should will be factored in with the final damage to get the attack's final damage, base attack would obviously be 1.
  • Animation name: may not be useful right away, but I plan to implement a way for each attack to have it's own animation associated with it.
  • Prerequisites : anything that the attack requires, could be a certain number of progression points, could be specific training,wielding a certain weapon, or even a certain completed quest. This will likely be an xml script to allow for easier extensibility.
  • Special effects: Defines the attacks special effects as discussed above, also likely to be an xml script to allow for extensibility in the future.
  • Area of Effect: Another XML Script, It would define if the attack is aoe or single target, if it is in fact aoe it would define directions effected, likely only the main four to start(front, left, right, back, or all around), and it would determine the size of the are effect.

The Attack Queuing System

  • The Queuing system will not technically be a queue by definition a queue, it'll work a lot more like a linked list with limited functionality
  • Functionality will include, adding to the end, deleting any position except the head, deleting all attacks with the same specified name within the queue, limiting the size of the queue to a specified number, popping from the front, and it will pull Attack data from the cache based on attack name or ID number.
  • Will require 2 classes, as any linked list would: the linked list class and the node class.
  • The players queue will be held in the pscharacter class.

psAttack

  • This will more or less just be a simple data structure holding the various pieces of data that make up an attack.
  • It will be structured much like psQuest is currently.
  • It will also have a prequisite script much like psQuest does now with psQuestPrereqOP.
  • There will also be a special effects script. This may not be fully fleshed out in Part 1.
  • And it would also handle area of effect script, though since area of effect is a much more standard thing, it will not work like the other scripts, instead it will just pull and set data values that will (in a later part) be used by combatManager to determine who takes damage.

Class level Design