October 2019 W4: Stats and Skills

Oct 28-1 Week 4 Update - Stats and Skills

Of all the weeks, this has I think ended up being the least 'shiny'. It was fundamentally difficult and required some extended visual brainstorming for solutions, and the end results aren't very impressive from a front end perspective. The good news is, this paves the way for an advanced pass over the equipment system, hooking procedurally generated item 'sub-types' such as polearms or swords into the skills system.

Primary Achievement - Stats and Skills

Continuing the long running tradition, The first two gifs I'd like to share directly relate to this week's core feature.
The functional stats UI.
The stats UI is relatively bare bones, but functional. I've already got a short list of quality of life improvements to go in, aside from the eventual design overhaul to make it look better, of course. All the values are hooked into the instantiating character's stats, and will reflect the current values.

It doesn't look like much, certainly, but this UI represents a significant part of this week's effort due to the unforeseen design challenges dealing with the infinite scaling, but uniform sized text I use. This mean that the procedurally (read: code) generated skill lists would usually end up looking rather like this:

A broken UI: Part 1

... Or this:
A broken UI: Part 2
If you don't see what's going on there, the text object expands to take up the whole parent panel, but the text size is constrained to the lowest number in its group. This meant that despite 'Psionics' having heaps of space to expand, it could not because the skills in 'Ranged' were as large as they could possibly get.

This also resulted in the rather grotesque text formatting you see above, which I thankfully resolved.

This second gif requires a little context to make sense. It is showing the functional impact of the athletics skill - that is, you run faster. I ran our friend John around to gain him some XP (At a hyper-increased rate, for testing and display), then ran him alongside Nick to show how his speed has increased from the base speed to a speed modified by his skill.
Run, John, run!

Secondary Achievements

Although these were achieved over the weekend as an extra curricular 'non-programming' activity for learning, they turned out pretty cool and I learned a lot from them, so without further ado:
A basic idle animation!
An updated run animation!
Since the initial run animation was my very first animation experience, I thought it pertinent to try again and learn more of Blender's animation suite. What I learned was that animating is incredibly rewarding, but can be extremely finnicky and frustrating at times due to a mixture of bugs on Blender's behalf, uninformative UI resulting in seemingly random issues, and the very artistic nature of animating, particularly involving the uncanny valley.

Overall, once they were done, I decided that it was an enjoyable and rewarding experience. It also has the added benefit of letting me include shinier things in what otherwise would be a rather overwhelmingly text blog post.

Next week, this work will flow into the aforementioned advanced pass over items and crafting, as well as a move towards beginning the medical system, which is technically scheduled for November week 2, but I will likely at least start it some time in mid-late November week 1.

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