Progress Report 7/15/2022 (Patreon)

Apologies again for the delay! Now that I've gotten some much-needed sleep, I feel like I can actually write coherently. :P  Here's what I got done this week:

• Made the color buttons change the color of the giantess's respective parts (in prototype form), save for the accessories
• Made the breast sprites (in prototype form) swap with their respective buttons
• Began a design overhaul for the gameplay

I've bitten off a lot with this giantess customizer, but slowly and steadily I'm chipping away at it.

What I got done:

First and foremost, let's talk about the color. I'm pretty happy with everything so far (especially the individual nail colors!) but there's still some work to be done here. It can use some quality of life features to make changing colors even easier, such as a "reset color to default" button and making the multi-color checkboxes (like heterochromia) change the colors of that body part immediately on toggling it.

More importantly, however, is designing a way to give each accessory its own color set using the same two buttons (primary and secondary colors). There's already a lot of moving pieces in this menu, so I'm treading carefully as I'm working on this. The plan is to give Accessory 1 its own, different colors from Accessory 2, and so on. It's simple on the surface, but under the hood it's quite complex for a user interface.

This complexity is represented in the gif by my masterful mouse acting when I reach the Extras menu. Truly worthy of an Oscar.

Next, you might be wondering what those numbers on the breast size are. Those represent different sprites -- Sprites 1-3, to be exact. There's going to be a lot of sprites... a LOT of sprites floating around here, so the next big step is to swap them out for one another. This means toggling visibility on for one sprite and off for all the others, BUT only in the same category of body parts. You don't want all the clothes to disappear because you changed the hair style. I've got a good basis for it with the breast size "sprites"; I just need to apply the same code across all of the grid options.

This was no easy feat. Much like the colors and... just about everything in this forsaken menu, things got pretty complicated. We're working with a lot of buttons, here. So, how did I do it? I started with my new favorite prototyping tool: Notepad. I wrote pseudocode for it, which basically means breaking down what I want the code to do step-by-step without all the distractions of actually coding it. Here's what I wrote for the sprite swapping in particular:

--- Grid Item Pseudocode ---

Catalyst: Click an item button

Item button sends signal to manager

Manager toggles the button's respective sprite to be visible

  -Option 1: Each button has a separate signal. Simple setup but very bulky in code.

  -Option 2: Each button category has its own signal function; button is determined by
  name. Flimsy due to dependency on naming convention.

  -Option 3: Each button and sprite is placed in a category array by the manager; buttons
  and items have the same corresponding number. Complex setup but stable outcome.

      -Manager needs to get each button and sprite to place them in the arrays.

         -Option 1: Get the children of children (and so on) to get each GridContainer; get all
         children in each GridContainer and set them to respective category arrays. Bulky due
         to number of children in this case.

         -Option 2: Export each button and sprite variable; drag and drop each item into the
         manager's inspector. Incredibly tedious and bulky; last resort if ALL else fails.

         -Option 3: Groups! Group each button and sprite under appropriate names and use
         get_nodes_in_group() to get them into the manager. Minimizes tedium and
         bulkiness.

         -Option 4: Make the manager the root of its own scene and give buttons a script with
         connect("pressed", owner, "_on_button_pressed", [name]). Sounds ideal, but I don't
         fully understand how it works.

            -Might as well give this one a go. If it doesn't work out, use Option 3 as a backup.
            Option 1 is the backup backup. Option 2 can burn in a fire.

Manager toggles all other sprites in the same category as not visible

  -Manager needs to know what items are in each category.

      -Same solution(s) as above.

Result: Giantess's appearance changes to what the clicked item button represents

--- End Pseudocode ---

I had a system in place for writing this: start with what I know wanted to happen first: the catalyst and the result. From there, write everything that needs to happen between them, then provide ideas for how to achieve each of those middle pieces. The more complex the code is, the more important it is that things are thought out one step at a time.

I'm really proud of this, because each "Option" that you see up there is a coding detour that I could have easily spent days on trying to implement directly. Instead, this took me about an hour or so think through and write. I cannot stress this enough: writing down all of your options before executing on them will save you so, so much time! You can even see how my thought process cascades into what eventually becomes the solution I ran with.

Speaking of the solution, I ran with Option 4 (since I was going to make the GTS Menu its own scene anyways), but realized that the Connect function works for communication between the buttons and the manager, but did nothing for the manager getting all buttons and sprites to put them in an array. I had to go with Option 3 for that.

Worse still, making the GTS Menu its own scene reset most of the color UI to its default state for some reason. I had to rename them from "Color" to "Skin Color", for example, and reconnect the color buttons to the sprites. Individually. One at a time. It set me back by about an hour... But at least the scene is its own thing now! So... organization win!

With all of that finally done, my week and my energy were both officially spent. It's not over yet, though; I'm currently working on a way to simplify the process of changing the colors of each different part (i.e. nipple colors 1-3) without having to manually tie signals to all of them. That would be crazy tedious...

At least, that's what I wrote down in my notes for what I got done this week. If you're confused by all of this, you're not alone -- I'm making the darn thing and I'm having trouble wrapping my head around all of it! This week was such a blur of menus and buttons that I genuinely can't remember most of the details of what I did -- I'm just reiterating my notes in a semi-coherent way. @_@

Let's take a break from all the menu talk and focus on something a little more familiar: the gameplay. You know, the thing that came before the character creator. :P  Taking the time away from it to focus on the menus has served as a sort of pallet cleanser; it gave me a chance to clear my head of the gameplay and get a more objective look at it. It's also given me a lot of time to think about it, and I'm making another executive decision to make some changes to it.

Changes to gameplay:

Obviously, this is a giantess game. However, right now, the gameplay feels like it's focusing on babysitting the heroes; you're supposed to be saving NPCs, but you're too busy saving yourselves. At times, moving around feels more like a chore than a game, especially with the addition of obstacles.

So, how do we focus the gameplay back on the giantess and saving NPCs? It's all about challenge. Challenge pulls the player's attention, and too much challenge in too many places means attention is scattered. That's not good, at least in a simple game like this. So, the goal of this iteration of gameplay is to minimize focus on the heroes and more on the giantess and NPCs.

My solution:

• No more movement quirks; the heroes should move perfectly or nearly perfectly with the player character. Alternatively, have only one hero on screen at a time and allow swapping with the press of a button.
• Each hero offers one active ability and one passive ability for the player to utilize.
• Abilities are still lost if the hero gets stomped, but this is no longer a focus.

The movement quirks were a lot of fun on paper, but sadly the execution just doesn't fit in a game like this. It may fit better in something slower-paced like a puzzle game; I'll archive the idea for future use.

With the removal of movement quirks, gameplay is gonna feel rather bland. Avoid the feet, save the NPCs, avoid obstacles. It got me thinking: what kind of game is this, really? In its most basic form, it's an endless runner (although I do want it to have an ending). It was this thought that made me reevaluate how the gameplay should feel.

What do other endless runners have that Run From Me doesn't? The main thing I found (for the fun ones, at least) is a variety of diverse obstacles -- and not just walls. I'm talking about obstacles that change what the player has to be actively doing.

Obstacle ideas:

• Mash button(s) to wade through water/mud/etc.
• Use springs (or similar) to bounce over walls
• Enter a door in a wall (or staircase?) to make it to the top of a narrow structure, and then another door/staircase to make it back down
• Optional obstacles that only certain heroes can help you make it past to make it to a secret area.
    -Enlightened: Float over a large stretch of water/mud/etc.
    -Bunny: Jump over small bodies of water and under overhangs?
    -Mole: Dig under a tall obstacle.
    -Ranger: Detect the correct door/tunnel to travel through.
    -Rocket/Barrel: Button(s) that open a door above (Rocket) or to the side (Barrel) for a very brief time.
    -Undead: Dodge a corridor of traps?

This list is far from complete, but it's a start for diversifying gameplay. Basically, anything to break up gameplay beyond "move to the side to avoid the obstacle". The water/mud idea in particular is one that I like because it requires input from the player. I'd like to come up with more like this.

Aside from these changes, everything else I have planned is still the same. The movement has just been something that's been bothering me for a while now and I didn't want to acknowledge it due to the amount of work I put into it. Prototyping can be really rough sometimes.

Anyways, I just realized I've spent two hours writing this. I'm gonna eat some Taco Bell and give myself some time to finally relax at home. If you made it this far... thank you and also I'm sorry! :P  This has been by far my longest post and I don't plan on making another post this long anytime soon. Anyhoo, have a great week (if you didn't spend it reading this) and I'll see you guys again next Friday!