Checkmate Dev Log 5/11/26 - Game Sprint 2/3
Okay, last post I wasted THREE PLUS hours trying to fix a SIMPLE bug and I couldn't and I am fucking annoyed to the point that I want to punch a hole through my wall and now I have anxiety because this is going to go into the demo if I don't fix it and-
Elise: Breathe... Need me to swap?
Gold: Please...
Elise: Now you know how I feel. This? Simple bug, doesn't break the game, it's not a priority. Tag me in.
Okie dokey! So, that aside, wherearewe? :3c
Kira: Check the board, babe.
Elise: Oh, right! Okay, super duper simple! So the Force System is just a bar and a line. That stuff is gonna go into the HUD. ...Or is it? :3c Let's stop and think. MIGI THEME PLEASE~! (As a fellow parasyte? This helps. ^w^)
Elise: So this is an object-related problem. We don't wanna throw new code into this thing willy nilly. Either we place it in something that already exists or a new class. Hmmmm... Let's weigh the benefits.
Focus in PlayerController - What happens here~? Well, we're using a number that goes up and down for stuff like force strength and- I'm overthinking it.
Let's instead talk about the system again.
There's a bar with a line on it.
It pops up when we enter the state.
Click, the line rises.
It goes up to the tippy top and starts to fall.
Click in the right spot, the shot serves. (No need for criticals right now.)
Click in the wrong spot, it's a fault. What happens during a fault? Player gets to try again. But if they fault again? BIG BOOM. You damage yourself. And this is a lot worse than the opponent scoring on you because it uses your own attack stat against yourself! (We'll figure out the true rules behind self-scoring/same element crap later).
And if you whiff? No swing, you just catch the ball and try again. :3
So where to put that stuff? Honestly? A new script for the bar seems to be the right move. The player controller controls the clicky things for the bar but the bar is its own system, so we put in a new class!
Gold: Actually let's put it in the HUD. Elise: And tell me why~ :3c Gold: It's the HUD that controls the elements of it, Each element doesn't need its own behaviors. Elise: Okie dokey! You're the boss~! So, we'll set it in the HUD script then. Gold: The code's broken. Elise: Wanna take over? Then I'll jump back in? Gold: Unless you wanna debug? Elise: You've taken quite a beating. I'll handle this one.
So, from testing, state swapping seems to have stopped. Goes to positioning, then aiming, then literally nothing you can do! So something broke along the pipeline. First stop? Cycling!
Elise gets on a bicycle and dings the bell.
Let's make sure that setting works.
Elise: Found the problem! Like instantly. So? When did Aria tell you to fork this up? ;3
Elise: See how it doesn't match? Let's try it now, annnnnd... We're cycling between them again. Next? Cycle back to Position on the second shoot left click. ALSO, I think I figured out your bug, Gold. The other one, the one you wasted three hours on.
Elise: On switch - take a snapshot of the bool before changing ANYTHING. ...No. What's causing it to turn in the first place? ControlAimLine. It's running because inputBeforeAim is false. That happens because the mouse stops momentum aaand... Let's try dropping the scrolling bit. Nope...
Ugh, We may need two bools for this one.
Gold: I'm- Yeah fuck this.
Why was that so fucking hard.
Elise: May I take over again? You kiiiiinda stole the show on me. Gold: Sorry... Elise: Glad we fixed it though, let's move on!
Sooooo~! HUD manager. Let's go ahead and grab that object. Aria~? How do we control scroll bars? :3 By the way you feel better, Gold? Gold: Bittersweet. Keep going. Elise: I'm on it, Boss! So Aria told me we need a Scrollbar object and not a game object, but that doesn't have SetActive. Sooooo I'm going to have two variables there and just graaaab the second from the first. So from this, to this. ^w^
That should do. -w- And if it doesn't I'll eat my hat. :3
Cool! No hat eating for today. Now for the fun part! Bar go up, bar go down! I wanna figure this out, so Aria, what's the name of the thingy that the line is on?
And that's all I needed to know! See, Gold? How easy it is to do your own thing when you understand the shot you're working on? Okay so I have what I need. What I want to move around and what I need to change. NOW for the fun part.
Oh wonderful scrollbar, I want you to simply move your little line up to the top of the bar. Give me a ding when you do and bring it all of the way back down. That is all, Mr. Bar.
Make it go up over time, DING! make it go down over time, BOOM. Kinda like a carnival game where you smash the platform thing in with a hammer!
Elise makes a devious look at Gold while holding a certain two ton hammer behind her back.
So, if I'm right and all of this works, (with the shoot function turned off because we don't need it right now...) ... Actually, NOPE! WE'RE DOING IT LIVE!!!
The whooooole shebang should work now! (I fixed the syntax errors and mismatched functions between these shots. ;3)
Elise tests it. The bar just goes up. She checks the inspector.
...
... :3
... :33
BAAAAAAHAHAHAHAHA!!!!
IT ONLY GOES TO 1!!!!
Okayyyy, so a couple more tests, shot's still not going down. Because I didn't know how to use a clamp until now. In hindsight, it's simple, BUT IIII want a custom thing. Eh, don't need it. Ternary maybe?
So just a quiche reminder on ternary operators:
thingIWantToChange = is this true ? do this : otherwise, do this.
We good ? Good : Shut up about it. >w<
Okay, they seeem to work but it keeps going up. Good news, it flags for falling. And there's the problem. It's ONLY flagging for falling. Soooo it's just one or the other, never both. Fixing with NEW new logic...
So it should go up, swap the flags, and go down. And the REASON we need the second one is to make sure you can't quick-serve on the upswing. Gotta toss it first! Okay, so a couple other changes and...
Better! Okay so there's also an issue where you can back out mid-shoot...
Gold: Tagging in. Elise: Thanks Gold. Glad you're feeling better.
Okay, this one's simple. States should be locked if something is happening that would focus input, such as if the game is waiting for the player to click.
So "If a state that requires a player to do something is doing the thing, no state swap."
Boom. Now for some reason I can't change the aim so that's the next issue. It came from the double-lock I put in earlier. Thanks to that lock, I was able to flick the scroll wheel without worrying about the momentum carrying over, but I was unable to control it. I think I figured out the fix.
Kira: We fronted while Gold was having his meltdown and he took some time away from the problem. Power of pizza, bro.
Gold: Right, so... Hmm... Let me check the bool. I know that Scrolling() is just if the scroll value is anything but 0.
What I need to check is when that other bool fires on state swap.
...It doesn't. That's... off-putting. Well, after chatting with Aria, here's the problem, and it isn't too many toasters:
Scrolling() wasn't firing every frame, even though it was always checking for input. Also, having it take a snapshot on state swap was not working because of this. So, a change here and here...
And it's fixed. Now we finally have a working player controller for the most part. At least until the next manager state.