loss of control (Patreon)

in the past couple posts, i briefly mentioned a control refactor. the reason it happened now was just because, since i was going to be making changes to the way summary information was displayed (and therefore controlled), it was easiest to just get that out of the way, as control requests were increasingly messy and difficult to implement, let alone troubleshoot. this won't be a full programming breakdown, but we can at least vaguely talk about the way it's structured.

The Old

in the demo, the controls (at least for our corner of the code) are structured in three parts.

first, the traffic controller:

in general, this says, when a button is pressed, go to a place that handles what happens when that specific button is pressed

next, the methods that check if a button is pressed. 

this says, when a button is pressed, tell whoever asked that the button was pressed

this probably sounds stupid.
that's fair.
these methods are not very useful right now but we elect to have them because there is some nuance in what 'when a button is pressed' means. what if it held? is it pressed then? what if it is half pressed? what if it is not held but is pressed down really hard?
these methods exist because if we someday have to change our handling of the nuance behind 'what does pressed mean' we can easily do so all at once by editing these instead of editing every place where we have asked for a button more directly.

of note, this is all defined per-scene (scenes: are we in the title screen? the battle? combat? summary?)

finally, there are the methods that actually handle what happens when we have determined the player has pressed a button 

left, right, up... action... oh my. you can see that that suddenly gets really messy. it's a bunch of conditions sorting out exactly what the current situation in the game is. i'm not even going to try and talk through that one, i couldn't do it. and that's the problem. 

so let's summarize:

• every frame, we call the traffic controller
• who asks what button has been pressed
• and sends us to something that handles everything that button can do
• based on what the current circumstances of the game are. 

button first, then state.

that does work. i mean, the whole demo works like that, right. it's just not very scalable going forward, and we want to get our course straight before we take off zoomign here. 

the reason it's like this is because this is just kind of how the structure happened. when i was first learning javascript (and this framework), my first goal was like how do i make Anything happen when a button is pressed--  and when i figured that out, i just built it out from there as i knew it would work. now that we have gained experience and understanding of our needs, we can go back and make it good. 

The New

it's kind of the opposite of the old one. instead of 'button first, then state', it's 'state first, then button'

what is a state? not like kentucky, but rather, what condition is the game in right now?

some example of states we have are:

• the summary screen is open
• a unit has been selected
• we're using an item
• we're in ranged combat
• we're currently transitioning between scenes

under new refactor, all of this is tracked with one variable. as you cannot be in two places at once, you cannot be in two states at once. this is a Finite State Machine, as lulu suggested to us. it simplies our control-handling a lot.

now let's check in with our control functions, and see how they're doing.

first, the traffic controller:

....eh? huh? what? that's it? that's all? that's all that's left?

javascript is weird, and most things are effectively just variables. strings are variables,  classes are variables (or maybe the reverse), and even functions are kind of sort of just variables.

which is why, if we shove a bunch of functions into a specific variable like this...

we can call them all within one line! neat!

how about our button functions?

ok, those aren't very different. you can see we're making more use of having generalized calls for if you call any type of button, to simplify things, but more importantly, instead of being scene-specific, these can now be called universally which further simplifies and standardizes our code across various parts of the game.

and now, the handling functions-- the part that actually does something. before, it was spread all out through various button functions, and even within them it was hard to understand what would happen when. now:

it is so much more manageable! we can read through it! if we press X button, do X thing. if we press Y button, do Y thing. maybe we occasionally have an extra conditional, but this is so easy! simple! clean! it's hard to let it go. 

and so it is now so so much easier to see exactly what is going to happen in a given condition of the game if a player presses any button, and that makes it much easier to understand and design control schemes. 

we are in a good place to start making new systems and features!