Space Rob thinking: update 13

Refinements were made, but I'll be buggered if I can recall what they were.

Right, let's re-visit things and see...ah, one was about removing the grid component: as mentioned in a previous update, as soon as a button was made inactive, the others re-aligned into the remaining spaces.

Thusly, remove the grid, anchor the buttons to the relevant areas of the canvas, job done.

(Here's the buttons, anchored. Hilarious how massive they need to be on the canvas -the level scene is there, below the left-most button, so tiny!)

Next, another buttom could be selected while the character was dead, creating silly shenanigans like the camera (since it's fixed to the Player Game Object, which is still there but made invisible while the death loop occurs) jumping when "Jump" was quickly selected.

To fix such, the button needed to be unselectable while the player was unsightable...which reminded me of a tag that was set in the likely ungainly Coroutine responsible for said doom, cleverly called "respawndelay": so, you can tag Game Objects in Unity for various purposes. In this case, the Player object has a tag of -you guessed it!- "Player". Look at that playa!

Why? I'm sure there was a valid reason, same as why there's also a "Dead" tag which is triggered during "respawndelay"...still, I could definitely use this, by adding a simple AND statement to each button click check, so that it can only trigger if " player.tag == "Player" ", and since while respawning the Game Object is tagged as "Dead", it cannot be triggered! Result!

(If and AND and tags and equals and...)

The player methods of "Walk" and "Stop" were also massively simplified, for they are no longer dependent on continuous user input, since it's whatever thought was last selected which decrees the action: thusly, the "move" boolean variable can be set to "false" when the stop thought is selected -and, since "move" is checked each frame in the "Update" method, this then translates into a full stop through some coding stuff- and "true" via the "Walk" method, triggering the corresponding velocity change when "move" is looked at in "Update".

That made complete and coherent sense, right? It's humorous how in reality I'm talking about very basic programming (which is pretty much my current level), but oh lord it sounds complex when trying to explain it...

Anyway, a new method was added, "Turn", to match the new turn thought: unsurprisingly, when selected, the character's transform.localScale gets re-set to a new Vector3, depending on the value of the "facing" int variable.

What else...oh, if "Move" was the last selected thought and the character then died, they'd respawn still, but still displaying the moving animation -that just required setting "move" to "false" during "respawndelay", thankfully.

Trickier was trying to ensure that once you picked one thought, the same thought couldn't be re-picked immediately in the same button -eg. if in the cloud-shaped thought I pick "Jump", I then wanted to guarantee that a different thought will appear next.

When trying to "make it so"...strangeness ensued, with non-hilarious, frustrating consequences.

Annoyingly, I cannot fully recall what the issue was, but I think it stemmed from the variable associated with the thoughts in the script,for when it was re-generated to pick a new thought, it was outside the bounds of the permitted choices, and thusly a new thought didn't appear.

It's something like this:

-One string variable, "thoughtNames", holds the thought names (strangely enough).

-At start-up via the method "Awake", a thought name is randomly generated through Random.Range and given to the Game Object associated with the script -and, since the script is attached to each button, this gives each button a random name.

-Once a button is pressed and the "Reset" method called (which enables the activating/deactivating of the button and it's appearing/disappearing act), within said method I need to instantiate an int list, mark the utilised thought as an int variable called "currentThought", remove such from the new list, re-set the randomThought by -importantly- picking from the newly instantiated list, and then allocating this new randomThought to the button.

(The re-fleshed Reset method in all it's glory.)

Is this the best method? Well, previous iterations did not comply and this one does, so for now, I'll stick to it.

It's still far from perfect, and often the thoughts you want will just not turn up...plus, even though the buttons are pretty large on the canvas, on the mobile game test they're absolutely minute, so I'll have to fix that...but, and it's a big but, I should be able to create one functional, simple level.

So...I guess it's time to conceive that!

Your experimenting amateur,

Stefano Ronchi