January 2020 W3: Degrading Conditions & Modding

Week 3 marks the completion of the core injury and condition systems. They are now in a functional state simply awaiting content and further light tweaking. The medical system still needs tending, surgery, limb removal, and cybernetics added to the mix which I will continue hacking away at over the next 1-2 weeks.

A significant realisation I've come to is that I've been approaching character action development incorrectly. It occured to me that I should have been building the functionality for characters interacting with systems (eg. workshops for crafting) as I built the systems, not in one big later pass. Thankfully the amount of interactable systems currently completed is relatively low, so I can fairly easily rectify this.

Completed State of Injuries & Conditions

A condition degrading into a less severe condition
Conditions can now be arbitrarily stacked in a 'parent-child-esque' relationship triggered by the duration ending on the parent condition. Any number of children can be assigned to a parent, and the hierarchy can be arbitrarily deep. The primary use for this is allowing for long lasting conditions that don't necessarily have a constant severity, such as allowing heavy bleeding to slow over time. The above gif shows a 2 deep hierarchy going from moderate to light bleeding, each with a 3 second duration for testing purposes.

Overriding Injuries

A character with the maximum number of overriding injuries cannot recieve any more injuries
The injury assignment system is finally at a point where I'd consider it pretty much complete. There are now two types of injuries: overriding and non-overriding. An overriding injury means that no other injury can exist on the same part as it at the same time. This is meant to simulate more severe injuries that essentially make all others redundant; like how you wouldn't care about a gash on your arm if it were already mutilated - it has no real effect.

Gameplay wise, if all parts are filled with overriding injuries (Ie. there are no valid injury assignments remaining) the character will die. That said, it is incredibly unlikely that a character would get to that point. As you can see above, John only managed that after being well into negative HP.

Modding Astraeus

I've mentioned in the last couple blog posts working with JSON to allow more dynamic content loading and creation. I'm quite happy with the systems I've implemented it in, but it's become readily apparent that JSON will not cut it for all types of content. For example, content that requires unique functionality such as adding different types of conditions (eg. stunned/blinded, which have different effects to 'bleeding').

This is why I want to switch to a hybrid system. JSON works well for simple data structures such as injuries, or body definitions (races) but for conditions, (future)psionic abilities, and item definitions, a scripting solution is necessary. I considered integrating a language such as S# (Which already has compatibility with .Net, unsurprisingly) however, interpreted scripting languages come with a performance drawback, and do not provide enough useful functionality to justify that.
Instead, I'm looking towards using runtime loaded user assemblies, allowing users to interface directly with the game's code and add any functionality or content they have the ability to program.

I'm absolutely certain this will require reconsideration of my current methodology, but given a successful funding round at some point in the future, I think it's certainly on the cards.

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