Devlog #3

Author Note:

The developments made in the following devlog have been carried out through the course of the last few weeks since the previous devlog so it may be a bit more lengthy than I would have preferred. There might also be some duplication of notes.

Action:

Following my previous feelings of dissatisfaction I decided to review the script I had created thus far for the bug and break systems both. I did find a few variants, most notably bug_tally, which didn't appear to have any true functionality to them and these were either adjusted or commented out for the time being.

Observations/Planning:

One issue I determined was that the bug generating the break_point is added to the respective bug array but which resulted in a bug being generated with the break_point but not fixed with the break_point. It also seems to me that the current system of randomly generating the difficulty of the breakpoint undermines the difficulty generation of the bug itself so the bug difficulty should determine the breakpoint's as well.

The bug_trigger function is never called anywhere and was obsolete and thus it was deleted.

What I determined through this was that my production_growth func, which handles the primary task bar progressions (Code/Eff/Test/Learn), would be best served by a rework with a new function being integrated to handle the specific task progressions and calculations. In its current state it just feels clunky and awkward to both decipher and adjust if changes were ever to be needed for it.

Alongside this I also felt that the text label fonts, specifically the tick texts, needed to be reformatted to look cleaner as well as possibly adding a blinking function to help players visualize the time between each tick of progression across the bars for the respective task they have selected. I also decided that the implementation of an announcement label to declare when a bug was found/fixed or a breakpoint was started/fixed with a brief pause would be beneficial as well for similar reasons.

One last glaring issue is the floats need to be limited to no more than one decimal point to ensure the labels are always legible, at least as far as string translation is concerned.

Dillemma:

With a plan in mind for what to follow up I went through and began working on the revision of the breakpoint + bug relationship, my initial plan was to simply transfer the bug generated into the Hidden Bugs array and then the Found Bugs array when the breakpoint was generated and then triggered. However that immediately ran into a wall as I realized that continuing to code would cause more bugs to be generated and I couldn't track the individual entries reliably once put into those arrays.

Solution:

While I suppose it may not have been significant to simply have the breakpoint pull the difficulty string from anywhere in the array I, instead, decided to add a new array into the bug_log dict specifically to log any break_point bugs. This also serves to eliminate any potential doubling of penalties from the bugs being 'Found' and introduced into the 'Found Bug's category and triggering any penalties to the coding/eff progress bars and their respective values.

--- One Week Break ---

Mental Note:

I have realized a particularly prominent issue I face from working on the code is that I too often get myself tangled up into knots trying to think multiple steps ahead in an effort to 'foresee' problems that any course of action I may take will have. Having spent so much time cleaning up the spaghetti of the code in the wake of the initial game jam work I've become very leery of ending up in a similar circumstance and now am overcompensating. Effectively this has resulted in becoming mentally paralyzed, sending my anxiety levels up and resulting in a lack of desire or ability to decide a course of action.

Mental Solution:

Focus on singular tasks, document thoughts and suggestions as a method to physical parse through my ideas and observations of any potential issues not just to help with my own documentation of my work but as a means to narrow the scope of my mental focus. Reminding myself that I can fix problems if/when I come across them but I can't create solutions to problems I can't predict. I need to focus on relying upon experience by building that experience as opposed to becoming a coding medium based on experience I yet lack.

Observation:

Reviewing my prior solution to the aforementioned dilemma I realized there were more moving parts that would need to be adjusted. So, following my prior mental solution, I elected to go through each individual function in my effort to marry the break difficulty and bug difficulty to one another in a simple step by step list and analyzing the code from there.

One observation I made in the process of doing so was that the break_check function and break_gen function had no reason to be separate functions. Ironically enough this appears to be a direct result of my mental dilemma where I split these functions apart anticipating a potential issue as opposed to in response to an issue or experience.

Action:

I decided to merge these together into one break_gen function entirely and then nest this function into the function for bug_check. I then proceeded to made if/else statements, dependent upon what the bug roll itself was, for each category of bug difficulty if statement (Simple, Standard and Complex) and then having the break_check run then. Adding a return statement to return true or false then I included an if statement beneath those to trigger if break_check returns true and have the difficulty var for the bug's difficulty then be injected into the appropriate array entry for the bug_log dict.

This not only makes things neater and tidier and ties the breakpoint's difficulty to the originating bug it spawns from but also mitigates the possibility of stacking normal bug penalties on top of the breakpoint interruption itself.

Observation:

I just realized the persistent issue I have encountered with the cursor for the work screen not automatically being on the viewport is likely related to the coordinates it initially is set to instantiate in are different from the main scene's so I need to have it adjust to that.

Action:

I have created a new label_handler function to handle any alterations to the primary labels. This allowed me to create if statements depending on whether the task was active or the breakpoint was active to then change the max_value injection/conversation as a string into the label texts for each respective progress bar.

Dilemma:

A problem I am facing at the moment is that I don't much care for the way the tick texts display negative value influences (ex. '+ -0.29'). I also would like to have these labels toggle visible to false if the value for them is 0.0.

Idea:

I think that perhaps a for loop iterating across each tick text and checking the values being put into them before it is included to either toggle visibility or remove the + from the text would be the way to go.

Dilemma:

Thinking about this idea of mine the problem I keep having is that even if I do that I don't know any way to, inside of a for loop that is, change just one specific text's label to whatever the new string is for it without doing so for the rest or without excessive if statements as that would be up to three if/else statement for each text_tick label. At least that is my thinking of it.

Solution:

Focusing myself on just doing this and seeing what issue or fix I could come up with, consistent with my mental solution, I decide to go through what I would need to, or could to, do step by step to make this work and I came up with an idea which was to create a string var that instead changes.

I was still unsure of what I could do with this yet but then I realized the solution:

1. Create a dict with two arrays: One for strings (Code, Eff, Test, Learn) and one for the para's being injected into the label_handler function for conversation (Code: float, Eff: float, Test: float, Learn: float)
2. Create a for loop with a range of 4 and have it cycle through three if/else statements checking for whether the the dict[tick][i] value was above, below or equal to 0. This changes the string var depending upon the result of these checks with either “”, “+ ” + (tick) or str(tick)
3. Create a match statement to match the dict[task][tick] with Code, Eff, Test or Learn and which then injects the var's string into a specific label's text depending on what is matched with it.

Result:

This solution was a surprisingly resounding success. I was exceedingly pleased with how this proved entirely effective with the very first test run and each run afterwards. It was nice, clean and succinct without too much extraneous code. I was very proud of this.

Plan:

Right now we are going to work on the label font and blinking. Then we are going to create the announcement label, possibly with a brief pause function attached to it. After this is done we will move on to fixing the cursor bug. When all of this is done we will work on the production growth function and then, finally, begin introduction implementations to all the new stuff.

I also realize that I need to modulate the text colors to change when the breakpoint is active and then again when it switches back to match the colors of the different bars. Along with this I also feel like perhaps there should be a confirmation button to select each new task within the progression scene as opposed to it just flipping depending on which task is currently selected by the cursor.

Action:

I created a function that, depending on whether the task is active or the breakpoint is it will tween to modulate whatever the new color is for each text tick label's text color.

Dilemma:

Hmmm. Strange the modulation appears to just be making each of the target text labels darker or brighter instead of changing their colors... is it perhaps some kind of weird 'overlay' situation happening where the new color is sitting atop them making them change like that?

Research:

This was an entirely new issue I was facing, as I had no prior experience with modulation of texts/labels so I was unsure of what to do thus I decided to do some research both in the Godot documentation and Reddit to see if I could isolate the problem that way.

I was met with limited success as I did find a possible solution to the problem but it didn't seem to address my particular issue, at least not directly.

Action:

I attempted to use the aforementioned solution but was met with an error I was unfamiliar with:

"No constructor of "Color" matches the signature "Color(float, float, float, float, float)"."

Theory:

I suspected either I was misinterpretating what was being used in the solution or that perhaps it was merely that specific sequence of floats that was the issue, not matching any existing indexes for Color().

Solution:

Reviewing the documentation further it appears to be simply that it doesn't have a match for that specific combination of numbers as, having copied the code for Alice Blue and pasting it into there the error disappears. Now we just need to find the codes for the colors we want and copy/paste them over.

Dilemma:

Hmmm... This is a real headscratcher. Either the values being provided are inaccurate... or something else is going on here and I can't quite put together what that may be... it would be technically easier just to create duplicate labels but I feel this is already bloated enough with more objects being added in and this is a good challenge to deduce whatever is going on here.

Test:

Ok so using a fresh text label, from my key_logger, with no colors set I tested adding the green color to it and it worked perfectly fine confirming it is not the color values that are incorrect. I them tried using both a green color and a following add_theme_override to orange to see if they were blending and confirmed this was not the case... which leads me to believe it is either something wrong with my code OR it is combining with the preset values. I will test the latter of these theories out now and then go from there.

Test:

Nope. The latter theory has been verified as incorrect with testing from the new default colored text label (from my Keylogger) being changed after having a new default color set... hmmm... so I am lead to believe it has to be something with my code itself fucking with it...

Solution:

Now that... is exceedingly curious... the tween's modulation... appeared to remain in effect even after the tween was supposed to be finished and it was not being overridden but merging with whatever new color value was being sent to the new font color... at least that is what I can deduce because after I commented out all the tween statements for the task match of the match statement then the break match theme_overrides worked perfectly.... very very odd... I will have to explore this further to examine exactly why this happened...

I am not sure what exactly happened here but given this, and prior experience with tweening in another project of mine in relation to the coordinates of the node not appearing to 'actually' change it appears that the function of a tween is a separate thing altogether. My best guess is that the 'modulation' just colors something else entirely that cannot be overridden by other means at least not conventionally. Very very interesting.

Action:

Alright so with a little more testing and some color tweaks... all appears to be in order. So the color swapping is completely fixed now. Maybe a little color polish later on but for now it's totally serviceable.

Addition:

So now the blinker... I've created the blink timer and starting with a .5 second timer just to sample what it would look like. Establishing the function to call the blink timer to start and I realize... maybe that's not necessary to have that function. The blink timer's timeout is what will call upon the function to toggle visible or not and honestly probably just have some kind of array with bool's and a for loop to cycle through and toggle the visibility off of all the visible text labels...

Conclusion:

-Breakpoint difficulty now matches originating bug's difficulty without adding to typical bug counts/penalities

-Tick Labels no longer display + negative values and show as “” when their value equals 0.0

-Labels now switch value displays depending upon Task/Breakpoint being active to better respective current tasks/progress

-Progress/Tick Labels now change color based on Task/Breakpoint being active to better match progress bars within each

-Labels have been modified with better font/outlines

-Task Progress labels now sit on their respective Progress Bar

More to come...