February 2020 W2: Tending

I apologise for this blog post going up so late, I wasn't at a point where I felt I was happy making a post on the Friday and told myself 'I'll do it Monday afternoon, that way I have an extra day of work to polish!'. Alas, that never panned out, and here we are on Wednesday afternoon.

As a matter of principle I won't be using any gifs from this week (W3) in this post, and I will be only talking about progress I made last week.

Medical Care

The primary feature of the last week, amongst small refactors and minor improvements, was the ability to tend to wounds. As there is no visual indication of the 'Tended' status, I've swapped the functionality to directly heal injuries for the purposes of the below gif.
Excuse the pushing, he's a little overeager
The tending system also brought along with it an item context menu, similar to the current character action context menu, and a generic progress bar.

Async Refactor

Week 2 brought about the question of how to handle AI behaviours programmatically. The existing solution was Unity co-routines, which work fine but lack the level of finesse that I wanted in my code base. Getting async/await to play well with Unity Monobehaviours was a little trickier than using co-routines themselves but was honestly well worth it once finished; the code is cleaner, and more modular.

I ended up using two libraries to expand the async functionality, as well as to better hook in to Unity's inbuilt functionalities: UnityAsync, and AsyncEx. Both have been excellent, and extremely easy to work with.

Tending Behaviour

The normal behaviour of healing wounds (Through using a medical item) is to tend the wound, not necessarily to completely heal it. The effects of tending a wound are based on two things: the wound's maximum tending reductions, and the quality of the tend.

Max Tend Values

Each wound has defined "Max Tend Functionality" and "Max Tend Heal Multiplier" values. The former of the two is the percentage of functionality you can return with a tend of 100% quality. Consider a wound with the following values:

Modifiers: Flight, 0.5, Manipulation, 0.2
Max Tend Functionality: 0.9
Max Tend Heal Multiplier: 5.0

While untended, the wound takes 50% of the flight functionality, and 80% of the manipulation away from the affected body part. When tended, the functionality is restored as follows, where F is functionality, M is the base modifier, and Q is the tend quality.
F = 1 - (1 - M) * (1 - Q) therefore, for the above example...

F_m = 1 - (1 - 0.2) * (1 - 0.9)
F_m = 1 - 0.8 * 0.1
F_m = 1 - 0.08
F_m = 0.92
F_f = 0.95

Essentially,m the MaxTendFunctionality determines how much the injury's effects are mitigated. MaxTendHealMultiplier is pretty much what it says on the tin; it's a straight multiplier to heal speed. In this case, the heal speed goes from 1.0/s to 5.0/s.

Modding In Astraeus

Over the last week, I've taken some time to think about the future of modding in Astraeus. I've come to the conclusion that it will not be included as a prototype feature, and therefore unlikely to make it into the base game barring high success in the funding round. If the game ends up on Kickstarter, it'll likely be a stretch goal.

I am personally incredibly interesting in making it happen, but as it stands it would require a rethink and refactor of how the game is programmed, and how data is stored. With my current financial situation and the necessity for speed in development, this is just not within scope for the moment.

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