Project Astraeus Development Blog

So strong are my newfound feelings for shaders, and HLSL in general that it's the topic I'm heading this post with. In an attempt to further educate myself and improve my skillset, as well as potentially create useful material for implementing the UI designs into Unity, I began learning HLSL and exactly how to write an actual shader. I specifically didn't want a simple 'hello world' shader, ala how as a twelve year old any programmers among us made python (or your flavour of accessible programming) spit out a singular line of text. I wanted to be able to stand next to my achievement and know that I made that . But like most things you want to stand next to and be proud of, it turned out to be rather different to my expectations. I suppose in a cruel sense of irony, I've essentially parented and raised something - albeit for a condensed duration. And much like raising a child, it was illogical, frustrating, and overall an experience I'll say "I don't

The last week and a half has been a busy, exciting week (and a half!) as I've begun to ramp up working again. Various situations (present company included) drained my motivation to work, and my mental health. Not to worry though, I'm back and ready to keep working! Also, there's a shiny at the bottom if that's what you're after. ;) The State of AI There's my shitty pun for the day... I ended the second half of last week by overhauling completely the way AI is handled in Astraeus. No longer an unexpandable, spiderwebby mess intertwined with random classes, it's now handled in a nice, modular 'state machine'. While technically it's not like the kind of AI decision state machines that the term commonly denotes, it still follows a state machine pattern. AI behaviours are held in modular, compact "AIStates", which can be chained together to create dependent substates (like how you Walk  to your enemy to Attack  them). This is all held in a q

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

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

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 momen

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

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.

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 dam