Technical note: I switched from tracking frames between button events to using a timer at the recommendation of my mentor. I’m still not fully convinced it’ll be easier in the long run but it has been instructive, which might have been their goal.

It does prevent me from needing to do a bunch of frames to ms conversion, and prevents me from trying to take shortcuts. We may, in time, see if that’s helpful or unhelpful.

We’re so back! Needed time to figure stuff out but I finally succeeded in picking up my laptop and getting things done. The secret was finding a way to reward myself for doing the thing without being able to beat myself up for not doing the thing. I settled on a little reward (making a tiny friend in one of the Linux analogues to mspaint) for every 30 minutes of programming I do- easy, fun, builds up over time, no streak to stress about, and no punishments for “failing”. I can just pick it up and start adding to the stack.

So anyway, programming updates: I figured out how to make a cascading timer, which I packed into a structure that can convert timer ticks into milliseconds and made some tests for. Perhaps not the most tasty thing, but I’m glad to have made progress finally and am excited to turn it into the next step of my evil plan: making an array of button events so I can eventually parse user Morse code input.

Little worried that I didn’t need a cascading timer at all, as I’m probably going to stop reading Morse code input after a second anyway, which is within the abilities of a single timer set to 1024 clock cycles per tick (maxes out at 2 and a bit seconds) and cascading means I’m limited to one timer at a time. I think it’ll be okay though. Having a 32 bit timer with 72 hours of runtime before overflowing seems overall more useful and extensible than a 2 second one.

Took a mental health week- not doing too hot.

NewGirlJade wrote:

Is it normal to spend hours on a single function? I don't feel like I've even gotten to the hard part of parsing human input into Morse code but it still took me ages to work through the function to take a sequence of Morse tokens and turn them into a string. I'm gonna assume that's normal at my skill level though. At least the puzzling through edge cases has been fun, and I think I've got the right approach. I think writing tests for this one is going to be a piece of cake, too (she said, in her (alleged) hubris).
Cheers!
Jayda

I did start writing some tests for this one, and have a list of ones I want to do eventually, but it's been hard to focus and I poked at this enough to be pretty sure it's functioning correctly, so I'm moving on till I want to come back and finish. It's not ideal, but I'm being nice to myself and want to keep moving instead of getting stuck on testing.

This morning I started attempting to figure out how the 'tap it out' functionality I want can actually work. I want it to be dynamic based on whatever speed the user goes at, as long as it's somewhat consistent per letter. Checking every frame and keeping track of how many frames a button has been pressed is pretty easy stuff, but caused me to have to reckon with the fact that I don't have anywhere to store state yet- I just jumped right in to the Morse code functions because they were fun and interesting.

After some pondering and talking stuff through with my wife, I think I have a really neat layout for how the game state can flow, with a place to keep track of world stuff while in menus, and hopefully a decent bit of structure without being overwhelming. Sorry, that's kind of vague and floaty, but that's where I'm at right now. Gotta keep this mysterious, right? (It's just a bunch of enums and structs. That's all right now. There's going to be associated functions, too, like update and draw. And that's all computers are- just data and functions.) Now that I know where the state should be put, though, I think I get to start biting into more of the meat of how to parse human tippy taps into Morse code a computer can reliably read, which is pretty exciting! (To me, at least.)

Is it normal to spend hours on a single function? I don't feel like I've even gotten to the hard part of parsing human input into Morse code but it still took me ages to work through the function to take a sequence of Morse tokens and turn them into a string. I'm gonna assume that's normal at my skill level though. At least the puzzling through edge cases has been fun, and I think I've got the right approach. I think writing tests for this one is going to be a piece of cake, too (she said, in her (alleged) hubris).
Cheers!
Jayda

I actually got way more done last night before I let myself fall into conversation! Steadily working my way through implementing tests for all the functions I've completed in my morse code module so far. They even helped me pinpoint a few bugs which would have been much harder to find without them. I also did a minor refactor this afternoon without getting overwhelmed, which feels like a big deal to me- that's been something that historically contributed to projects spaghettifying- I'd try to move a function to its own little home and couldn't figure out how to make it work syntactically, so I gave up. I'm glad I've been getting the hang of Rust's syntax and how to find answers in the docs and elsewhere. The compiler is usually pretty helpful, as long as you know that it has a hard time pinpointing simple stuff like semicolons and unmatched curly braces.

I also learned that when using Helix you can push space + ? to get a searchable list of all key commands. I can't stress how huge this is for me. I've been having a lot of fun but my working memory isn't amazing so I find myself looking up commands very often, or even taking long-cuts so I wouldn't have to break my flow to look up a command by manually thumbing through my notebook I made when doing the :tutor Helix provides (for the third time). There's so many things that are so productive and nice-feeling if you can just remember how to do them. It's funny how even being pretty mediocre at a modal editor is still enough to get some street cred from other developers. Pretty sure it's like playing Celeste or a Sonic game or Kitten Burst (my favorite game of all time, which nobody's heard of) - it feels pretty good to be bad at but (probably) feels amazing to be really good at.

I'd definitely recommend checking out Kitten burst though. I don't know the creator personally but he's always really kind in his forums and put SO much thought into the game. He did the visuals, writing, and music himself and they're all stunning. I still think about it all the time and it's not that expensive. Worth every penny IMO.
Kitten Burst Steam Page

Anyway, I'm pretty much a test convert by now. I just learned proptests are a thing and I want to check them out to see if they'd be worth setting up, but I'm a huge proponent of "something is better than nothing," and "most things worth doing are worth doing poorly." Some tests are way better than no tests.

Thanks for stopping in! I don't know if anyone reads this but I like pretending there's at least one person who's enjoying my rambling, and has learned at least something from my floundering :3

link to the github repo for all interested:

Cheers!
Jayda

Was having a bad time with writing tests until my mentor looked at my code and realized I wasn't deriving Eq or PartialEq on my MorseSegment type, so I wasn't able to use assert_eq! on them, and I was misunderstanding what assert_matches! does and why it was working for just a single morse segment but not a vector of them. I'm glad I struggled with it so the lesson will probably stick and I learned more than if I'd just gotten the answer straightaway, even though it means I've still only written one meaningful test, lol.

About to go to a programming meetup with my wife where I plan to write a bunch more tests (but will likely spend a bunch (most) of the time talking to people, as The Lady intended.) :3

Took a break for a couple days for mental health, but I'm back in the saddle now! Been digging into how the deref implementation from last week works, and made a fun discovery about the * operator in Rust.
&*self.0
Specifically I learned how much this is doing all at once. I'd been thinking of * and & as opposites, like multiply and divide, which cancel each other out. I thought & means "make a pointer to the thing" and * means "this thing I have is a pointer, go look at what it points at and go get it" which I don't think is necessarily false, but, in Rust at least, it seems to be more complicated than that.
The * operator is apparently exactly the same as saying self.deref(), which is to say "get the thing out of self", and * is going to be a different function based on what type self is. So &*self.0 isn't the same as self.0.

I also learned that a Trait/interface/typeclass is just a way of saying "if it has this trait, it will implement the corresponding function"

I... I get to learn what a CDN is so I can paste an image here :'D

Edit: It wasn't that hard- just needed to sign in to digital ocean and make a bucket.

The idea is that this will open up when text input is needed, with a cursor starting at the center. I tried to make the tree as alphabetical as I could but sacrificed a bit of symmetry in the name of (hopeful) ergonomics. Again, I tried to make more common letters closer to the center. It might be terrible. I got the idea from Dreamshell's text input system which did something similar, but more compact and using the Dreamcast's two joysticks and a trigger to select a character. It felt and looked really cool but was pretty hard to get used to (I said it felt cool, not necessarily good). Since I'm going to ease people into the Morse code one or two characters at a time my idea is I can also ease people into this system just as slowly.

I don't like most text input systems for the GBA and am hoping this will help make the process less frustrating long-term, since my concept for this game will require lots of picking out letters. I also just think it looks cool. I was initially going for a slightly more fractal design, as you can see in my second iteration, which isn't completely off the table, but I want to prioritize function over fashion since I want the game to be fun first and foremost, and the final design with the character mappings just fit so well.