October 2019 W2: Modular items and crafting

The State of This Blog and Solaris Development

(If you're simply interested in a project update, read from the next large heading.)
It's been a few months since I've written a post here, and for good reason; I had temporarily ceased development of Solaris. There are a few reasons why that occured, but none of them were intentional and they all boil down to one thing: lack of time management. My activities had become more whimsical than planned, which resulted in very little if any dev time, and a very low productivity.

Regardless of this, this post signals the dawn of a new era of consistent progress and updates at the very least to say "Hi, I'm alive, I haven't stopped!".

Solaris Development and Time Management

This week has been the trial for a new lifestyle I'm getting myself into. The lifestyle involves 9-5 work 5 days a week on Solaris, with no interaction with the game or code base (Beyond blog writing, of course!) outside of those hours. This schedule helps immensely in two distinct, but similar ways; the first is that it keeps me making progress and spending consistent, uninterrupted spans of time working on the project, which is now my job. The second benefit is that it also stops me spending too much of my time working, and subsequently becoming burnt out.

By the results of this week, it's been a resounding success! My productivity has been high, my motivation very high, and I haven't felt particularly burnt out, though more time will tell if it is an adequate long-term solution to creative burnout.

The allocation of my development time to standard workweeks additionally helps to compartmentalise time into 'blocks', of which there are 4 per month, corresponding to 5 day weeks. Each block begins on a Monday, and thus the month that the Monday lies in is the owner of said time block (Making this last week the second week of October for development). 

The blocks allow me to set tasks that I think are appropriately sized for completion for the future. For example, I allocated this past week (14-18 October) for completing the functionality of the modular item crafting system, beyond which I will not interface with that system until it's time for content and polishing. Week three of October will be time for me to tackle the character equipment system, which ties in nicely with the modular crafting backend.

What This Means for the Blog

While this time management system technically means I have less available time for non-development activities, practically it has resulted in far higher productivity, and thus far higher effective time available than beforehand, so the blog won't be going away (in fact far from it).

In line with the allocation of week long blocks, I'll be writing a development update here weekly, released some time over the weekend with the aim of Friday afternoon (prior to the end of my work day, ideally). The updates likely won't always be long, and won't always have shiny pictures or snippets of code in them, but I will aim to keep this up to date with the current Solaris happenings.

Oct 19 Week 2 Update - The Crafting System

As previously mentioned, this week was all about the modular crafting system - the backend that makes it tick, and the UI that allows it to be used. This was possibly the most satisfying week of development to begin my new work schedule with, as I finished the system at 4:54PM on Friday afternoon, 6 minutes before the system 'deadline' (with the end of this week).

What Was Achieved

Before I go into the challenges with this particular system, it's pertinent to show what the system actually does.
The final implementation of the modular crafting system
If the above is confusing, it may help to understand how the modularity works. Each 'item' is simply a functionless container with a type. The type of the item in the gif for example is "Head" (synonymous with helmet, hat, or any other noggin based apparel). From this type, there's a list of compatible modules, and some default stat numbers. The numbers themselves are relatively arbitrary, bar size. Each module you wish to add has various properties that can be customised to affect the overall stats of the final item. Only a single property for each of the three example modules has been implemented at this time. Once you've added the modules you want to your item and achieved a balance you're happy with you can create the item. In a complete version of the game, this will send a work order to the relevant crafting structure and you can have a character complete that order. Currently, it simply spawns an item with the associated data.

The Challenges

The primary challenges with this system weren't so much related to the backend or direct functionality as they were UI integration and code maintainability. I've said before that perfection isn't the goal of the prototype, and I don't aim to achieve perfect maintainability, but I somewhat struggled to meet my prototype standards while connecting the UI with the backend.
There were several instances where problems had a brute force solution that was obvious, and a much more elusive elegant, generic solution.

Several times large, unsightly, and difficult to maintain switch-cases would have solved the issue at hand. If the issue wasn't already apparent, switch cases are not particularly re-usable and require copy-pasted implementations around the code base, meaning that if I were to add another module I may need to update the code in many different places. An example of a much milder brute force vs generic solution can be seen below.
Really it's just 9 lines, since the called function is completely reusable for getting module stats!
I'll take this moment to beg your forgiveness for showing you that. It's not something I was proud of writing, but I wanted to test it in theory and the brute force method was quick, albeit very dirty. This refactoring was actually a result of subconcious need to break from creative code writing, into something more mechanically satisfying. Needless to say I was quite satisfied with the extent to which I cleaned up that method.

That's about all I have to say on this topic. Next week I'll be working on, then subsequently writing about the character equipment, which should hopefully take far shorter than a week, though with all development work the time and cost estimate is almost always wrong by a fairly large margin.

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