February 2020 W3: Injury & Condition Icons

This is an exciting blog post, as it marks the end of the first pass for the medical system. There are still some major, but secondary systems missing from it such as bionics, implants, and surgery, but the backend for implementation of these features exists for a later second pass.

The purpose of the first pass was always to get a system into place that could deal with damage and attacking in a way that will at least be comparable to the final product, and I'd say with the injuries and conditions complete, I have achieved that goal.

UI Changes

The big changes this week were regarding the UI, and display of conditions and injuries. Consumable items (Such as med kits) also got a UI element displaying their remaining uses.
'Final' Medical UI

The UI has been expanded and re-arranged among other changes, as previously the icons were 16*16 pixels, which wasn't nearly enough for their icons to be properly visible. They've been upped to 32*32 for the moment, though I may potentially increase them to 48 in future.

An icon's background colour is determined by where it sits between the minimum severity of all injuries, and the maximum. The lowest severity injury will display as the orange in the above image, while the maximum will display in the red. Anything inbetween will sit along the gradient. Conditions use the same gradient for their colour, however it is based off of the duration times the severity (Essentially the total possible 'damage' or 'impact' of the condition).

The small grey icon at the top of the injury is the tending indicator. When tended, it'll show a cross ranging from red to green indicating quality.
The medkit makes it check for if it's empty on the next attempt at tending. Whoops!

The injuries are displayed in a line on the top, while the local conditions are a line on the bottom. The far right is reserved for 'global' conditions, which I'll discuss below.

Conditions Overhaul

The way conditions work both programmatically and mechanically has been completely overhauled this week. Conditions are now split into two distinct categories: 'Local', and 'Global'.
The JSON data for declaring an injury. Note the updated "Conditions" field

Local Conditions

Local conditions are considered to belong to a specific injury and body part. These kinds of conditions include things like numbed, or bleeding. The duration of these conditions is directly tied to the parent injury, as a percentage of the injury's base duration. I believe this makes more sense, as now a condition will resolve quicker if the parent injury is healing quicker.

In terms of the 'degrading injuries' feature introduced earlier, this has taken a neater form in parented conditions by ID. Each condition given to an injury is assigned an ID, and has a ParentID field. If the ParentID field matches another ID on the injury, the condition will be dependent on its Parent being successful. This means that if a parent ID fails to fire due to a < 100% chance, its children will also not fire. The starting point for each duration can also be changed, and it is therefore trivial to align a 'heavy bleeding' condition with a 'lightly bleeding' condition that directly follows.

Global Conditions

Global conditions belong to the entire character, and have no reference to a specific injury or body part. These conditions would include 'poisoned', 'stunned', 'blinded', and any other variety of holistic effects.

The duration of these conditions is in seconds, rather than proportional to anything else. Parent IDs and start time currently have no impact on these conditions, however if necessary it'd be relatively trivial to enhance them with this functionality.

Moving Forward

Next week, I'll be integrated the equipment, skills, stats, and medical system into attacking/defending. This will be the first real combination of all the previously developed systems, so I'm keeping my fingers crossed that the way I've built Astraeus so far makes this relatively easy.

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

February 2020 W4: Combat Preparation

Image
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 conce
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