January 2020 W2: New Year, New Feature

It's been, in the most literal sense, a couple months since I've last posted here. It was a struggle to get anything done amidst the jovial, familial atmosphere of December, as I'm sure most people can relate. These last couple weeks since the new year have been spent getting back into a working routine, and I can safely say I'm all snug back in my routine.

The medical system has sort of been a feature floating around since the last dev log, with occasional backend work being done when I managed to find the time. However, this week has seen some appreciable progress in getting it into a working state.

Injuries

The injury system I finally hammered out is something of a hybrid between a fully fledged limb-by-limb health system, and a more traditional global 'HP' pool for an actor. The character does have a single HP pool, which when depleted results in becoming unconcious, and eventually dying; however, as the preceeding heading suggests there is a limb damage mechanic in the form of injuries.

Injuries are 'long' term or 'semi-permanent' (Removable only by medical intervention) status effects that reduce the functional capacity of a body part. I've only got a small pool of debug injuries in place at the moment, but among them are 'broken' and 'destroyed', which modify limb functionality by 0.2 and 0 respectively.

The intent of this system is to give some 'personality' to characters via persisting injuries, as well as simulate losing effectiveness during combat as they take more and more damage. Injuries are dealt only on 'critical' strikes with weapons, are based on the damage type of the weapon, and their severity is determined by previous accumulating injuries as well as the damage of the attack.

Conditions

I consider conditions to be a subset of injuries. Conditions are relatively ephemeral issues, lasting anywhere from a few seconds to an hour or two. These are generally lower severity issues with consistent, active effects which generally self resolve with no side effects. Conditions include bleeding and poison, which deal damage over time and may reduce the actor's abilities; stunned, which reduces the actor's stats temporarily either slowing or disabling them; and more specific condiitons such as blinded, which is fairly self-explanatory.

John

Meet John, the past, present, and future test dummy for all medical experiments.
I thought it pertinent to introduce you, as he will be hanging around 'helping' me 'voluntarily' with testing the concepts of the medical system. Fear not, he receives free medical care... Eventually! John has already suffered several broken arms, as well as having his arm completely destroyed.
Injury with tooltip
The injuries are currently shown as red circles with white outlines under the inventory, equipment, and stats buttons.
I'm nearly compelled to spend some time rebuilding the HUD...

Content Creation

One of the more technically interesting parts of these features is actually their content implementation. All the content, including the current dev content, is defined in json files within an accessible directory. It allows for really simple content modification, addition, and removal as well as just being enjoyable to learn, and rather aesthetically pleasing.

JSON data for injuries
As a start, the system can load and read an arbitrary number of JSON files, as long as they're in the correct directory. In future, I'd like it to be able to read entirely separate folder hierarchies to make modification and sharing even easier. For the moment, however, I am satisfied with its functionality.

At the top of the image, you can also see the JSON files for race declaration. The current system allows for a race with an arbitrary collection of limbs and body parts, with no, singular, or multiple functions. I can imagine some fairly neat content in the future with a flexible system like this.

Closing thoughts

The only other notable feature developed in the time between logs is a rudimentary dev console for helping me test things without messing with code. This way I can mutilate John's body far more easily and in many more ways than I could before.

Next week I'll be looking to finalise the injuries, as well as work in conditions. That'll conclude the first 'half' of the medical system, before I move onto creating a method to repair bodily damage, which will include standard medical care as well as limb replacement. I'll be looking to, at some point, create a system for visualising injuries, both on the character model and in the GUI.

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

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