return to duck (Patreon)

hello.
i'm not 100%. i have not received medical attention, and will likely not receive it in the near future.
but maybe i don't need it.
maybe this is the same stress-induced somatic bullshit i've been dealing with on and off for years. maybe i just somatisized an allergic reaction this time.
who fucking knows. i don't.
whatever the case, i've decided i'm done letting feeling shitty stop me from getting shit done. i had no brain cells because of the allergy medication before, but fuck it, i'm going cold turkey, and we're making a goddamn video game.

we are almost on top of the initial battery of character art that needed to be done for the start of the game.
unfortunately, everything is still broken.
my poor programmers and myself, we are doing our best.
today we will return to duck.

disclaimer for my blind patrons-- most of the screenshots posted here are snippets of code. i am making the choice to refrain from IDing them because that would look like mega garbage for the rest of the post and also probably still not be very intelligible to your screen readers. sorry, friends.

The Goal:

in theory, the tutorial battle is completable. i wish to complete it.

The Problem:

i cannot go two seconds of trying to play this game without finding something horribly broken.

Last Night's Example:

i am trying to fix a thing mid-battle.
"oh," i think. "I will speed up my testing process by making a mid-battle save right before the thing I need to test! this will be helpful and efficient, ha-ha!"

>mid battle saves are broken
>bookmarks are broken
>returning after saving is broken in at least three different ways
>the game crashes when you delete a save

I don't understand. I don't know what we did. We refactored a lot, but we didn't refactor THAT much.

I fixed the thing I was originally working on. And I fixed save deletion. And one of the return-from-save crashes.

But mid-battle saves are still broken because somehow the first time you save in a battle-- and ONLY the first time-- all of the save data gets polluted with random properties like "@" and "@c" which is both fascinatingly bizarre and also impossible to google about. I don't know. I've made that Perry's problem for now, so let's ignore that and move onto the next problem.

I will just play a battle and see how far we get.

The First Challenger:

The first thing that happens is the player's turn is announced.
Next, the map's objectives are shown to the player.
The menu stops accepting inputs though, softlocking the player.

When I say first and second thing, I mean it-- we literally start the battle and shit breaks. i cry every time.

Actually, Perry fixed this yesterday, he swears... but it is not fixed for me.

In order to fix it, he added a state that checks if we're mid-event, "interpreterState" so that we can better process scene events without the intereference of player controls. But controls are still turned off for me, and not him.

A few minutes hunt and think reveals the issue-- I press a button to skip the turn animation. He doesn't. It is only broken when skipping.

This is the result of a previous fix that interpreterState replaced-- we turn the controls off manually in that case to prevent extraneous inputs mid-scene.

By removing the old fix, it works properly! We no longer get softlocked by the second thing.

The Second Challenger:

there may not going to be a third challenger today lol

Immediately after closing the objectives window, you can input TBS commands (like bringing up the menu, or hovering a character with the mouse) mid-scene. It's exactly the same issue as the above was meant to fix, but coming from a different place in the code.

Imagine if... Like there's an issue on a highway. A bridge collapsed. We fixed on bridge. And it has just come to our attention that probably all of the bridges around this particular highway have the exact same structural flaw, and will collapse.

We have to fix all the bridges.

This whole balance of TBS controls VS game scenes has been a huge, consistent pain point through all states of development so far.
A lot of cats and error-fixing even during the demo was focused around this and band-aiding over the problem.
We are, in terms of code structure, in a much better place to create a proper solution for this. It is imperative for future smooth development that however I fix this be scalable.

So let's talk more about this interpreterState thing from above.

What is a state, firstly? It is a way we tell the code what is going on in the screen and what it should be listening for right now.

For instance, we have a state for when the player has selected a unit. We have a state for when they have opened a menu. We have a state for when they're in combat, or the summary screen, or specifically the item menu, and so on.

This way, especially for control input, the code knows to only listen for specific button presses in specific conditions.

In the demo, we didn't have this, and it was unsustainably messy. Each button press was an array of conditional logic.
If you pressed the S key it first asks, are you in the summary? no, are you in combat? no. do you have a unit selected? no. you have the menu open? ok. the item menu? ok. do this.

Now when you press the S key, the code says, Okay, what state are we in? The item menu? Okay, do item menu things.

So this interpreterState is a specific state in which all of our game code will ask

Are you in the interpreterState? If so... do nothing! We are waiting for the scene to finish (via event interpreter, hence the name) before we are accepting any more control input.

This has been made to work for turn announcement, and nothing else yet. The reason there will not be a third challenger is because we now must make it work for all of the other bridges on the highway. And hopefully we will never have this issue again.

We have previously tried to sanitize scenes like this by having functions prepScene and closeScenes that ask everyone to rush around and shove everything off the stage like a bunch of backstage roadies. So first, we'll add switching to this interpreterScene to their list of Tasks.

Next, we need to detooth interpreterState's changes that made it specific to the one bridge we applied it to before.

Then, we need a more generic solution that we can easily slap onto any bridge. We'll make a function like... this.

And then we'll use it like this.

Basically, if we were just in an interpreter state, we probably need to go back to it. Ergo, we shall do so instead of doing something else.

I test.|
I realize [-1] does not work to get the last item of an array in javascript. Oops. We have to use $gameTemp_priorStates[($gameTemp._priorStates.length-1)] instead.
I test again.
The first bridge works.
The second bridge does not work because this depends on the last state being interpreterState and somehow it is getting its state updated twice at once. This is something we should probably fix for good practice anyway.

What's going on here--

Normally when we select to open the objectives, we have to close the prior menu. Closing the prior menu returns to the base state, which we want in most cases. But perhaps rather than returning based on the player turn, since we can now check what state we were in previously, we should return based on what our prior state was.

I'll quickly add this just so I don't have to type it out each time:

And so we'll change it like this... That way we only snap back to the TBS mode if we were in it before. Otherwise we are counting on being carried forward by something else.

I test a third time.

... why is that so big (sobs). whatever, it was silly anyway.
This works! This will still need to be applied to any future bridges we come to, but we can cross those bridges when we... yeah.

Perhaps we will have a third challenger after all.

The Third Challenger:

We have successfully used interpreterState to get through a scene without any noise, but we haven't included a way to get Out of interpreterState, so we are frozen into it even once the scene is done. I have some thoughts.

This is the function which generally manages the question of "What should happen next"? Before my above changes, it was used to push the turn along for the single-bridge case of interpreterState. I commented that out and happened to add that comment below. Seems like it's time to do what I said.

I do a quick test with that console log message to make sure this is being reached in the timing that I think and hope it is. Miraculously, it is. Love that for me.

Now we make a new function we've just made from the startTurn that this originally called. We can now call just this part, and it -should- clean us up.

We test.
It works.
It has taken four hours, but I have made it to the start of the battle.
God bless.
now, maybe, i can make -any- progress.