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

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