February 2020 W4: Combat Preparation

The original intention of Week 4 was to implement at the very least the functionality for attacking with melee weapons. Unfortunately, that ended up taking a back seat to some much needed refactors due to added functionality to character skills.

Refactoring Skills

Originally, skills were stored within a C# Dictionary containing the skill name as an enum, and the skill's data as its key. This worked fine while the skills could comfortably sit on a single line, and didn't cause any ridiculous level of clutter, though it wasn't quite compact either.

New skill functionality

The functionality that expanded the data structure for skills was in essence a way for character stats (Attributes) to relate directly to how a skill effects an items individual stats.

There was no previous system in place to relate attributes to skills or item stats, so the introduction of this system not only opened up a lot of versatility in balancing, but also introduced an entirely new concept to how skills function.

The first iteration of this system was somewhat straightforwardly relating ItemStat enum values to certain character attributes with coefficients to balance. This solution however precludes using attributes to modify the outcome of non-item oriented skills such as dodge, or sneak. The second iteration moved to strings with arbitrary names based on what they impacted. This does mean that when linked, the strings have to be either recalled or checked to make sure they don't cause an error at run time, but it's a relatively small price to pay for versatility.

Moving skills to JSON loading

As the result of having such large data objects inside skills was either extremely large or very unwieldy and difficult to maintain, I ended up spending a while moving the whole system over to JSON. The skills are still indexed by an immutable enum, though I will likely change this to a string at some point. The only issue being that all the references will need to be changed as well, and then checked through, which I'm not particularly keen on doing in the middle of feature implementation.
The skill definitions are now quite large when making use of the impacts

Skill impact coefficients

Above is a snippet of a skill declaration in JSON containing a single impact object. The impact contains a name for what it impacts ("Damage"), as well as an array of all the character attributes that can affect it ("Strength", and "Dexterity"), and their values.

The values work fairly simply, at level 0, the modifier will be the NegativeMax, and at 100 it will be the PositiveMax. The modifier will be at 1.0 (No impact) when the skill level meets the treshold as a percent.
The strength damage impact above plotted on a graph
This feature means that attribute impacts can be individually tweaked for each value and skill independently. This is possibly more complex than necessary, but it allows for a lot of fine balancing. This is of course all liable to change or removal at any point.

Subtype modifiers

Shown in the second image of the JSON are two new lines that previously weren't a part of the skill definitions: "Subtypes" and "SecondaryTypeCoefficient".

Subtype

The subtype is an array of item subtypes, which currently handles two entries. These subtypes are the two affected by this skill. The first being the primary subtype that the skill deals with (sword for 'swords') and the second being the 'secondary', which is a complimentary but not necessarily heavily impacted subtype.

This means that if you're using a weapon with the dagger subtype, your swords skill will also contribute towards the final stats.

Coefficient

The coefficient acts on the second item in the subtype array. This is the multiplier for how much impact the second subtype will get. So in the previous example of using a dagger, your swords skill will only contribute 20% of what a primary subtype would get. This both means that both the potential penalties and bonuses are reduced to 20% of their value.

Other progress

Aside from the refactor, a MoveWithin(target, distance) function has been implemented, as well as a refactor allowing Move and MoveWithin to follow a target entity rather than go to a location. A fair amount of progress has also been made towards getting melee attacks fully functional.

The first week of march will be dedicated to the basic implementation of combat, and if I'm lucky an attempt at animating the attacks/blocks via inverse kinematics. Showing equipment on the character while equipped is also on the to-do list for combat.

Comments

Post a Comment

Popular posts from this blog

Development So Far

Image
Technical Planning Even after all the pre-development theory, I still felt like I had more planning to go. The technical planning was admittedly far less robust than the designing, consisting only of a single Draw.io flowchart with some terms that had more meaning to me than anyone else. Frankly, the use of such terms may have been a mistake. A class hierachy plan If it's not apparent, the above image is a flowchart denoting a class hierarchy and their functions in terms of interfaces. The interface names, while relatively self-descriptive, are also quite mundane and could potentially be easily forgotten. I rarely refer to the flowchart at the current moment, as my attention is consumed by the minutia of features rather than the overarching class system, however this flowchart proved incredibly useful in starting the project off on the right foot. Having an organised class hierarchy has saved me a fairly significant amount of work as far as refactoring and duplicated c
Read more

November 2019 W3: [Test_Graphics] Shader and Graphics Research

Image
I apologise for the late arrival of this blog post, the end of last week was a little bit hectic for me, and left me without time to write this up. Week 3 was all about research and learning the topics surrounding graphics and aesthetics for me. This meant lots of new information about shaders, mesh generation, volumetrics, post processing, and render pipelines. It was sometimes a little bit overwhelming, but overall a great learning experience. I feel pretty confident in saying now that I've got a basic and functional understanding of shaders and how they work, though there's always significant room for improvement. Also with this blog post comes a project name change. There are various reasons behind the decision to switch names, but (as you would know if you're here) the game now goes by the name "Project Astraeus", which I'm actually quite partial to. The Results In line with the topic of this week, the results themselves are quite shiny. I
Read more

March 2020 W1: Melee Combat

Image
While the combat is far from finished, this week has brought some significant progress, and set the baseline for how getting and using stats is handled. Implementation of more combat features over the next couple weeks should be significantly simpler. Combat progress The primary progress made this week was the implementation of basic melee combat, and its integration with the medical system. The code still needs to be refactored to be more generic, and a little cleaner for use in other types of attacks, but it's written and functional, which is the hardest part. The animation ends earlier than it should for some reason, but it's there There are still parts of what I'd consider the 'basic' implementation that have yet to be added in. An animation for blocking does not exist yet, and the automatic behaviour to fight back isn't finished. The final vision is to have a combat system that is reactive between two combatants, meaning that they would each
Read more