Mr. Nutz Week 3

What’s up y’all! It’s time for the new weekly check-in, which seems like it’s settling into being posted sometime on Mondays. Let’s check in on the latest.

the tl;dr

gamedev - 5.7 hours

This was the week of game dev I needed. During weeks 1 and 2 I really struggled to sit still and work on this. This week I rediscovered some of the inescapable truths of difficult work.

The way my schedule works is still a bit in flux, but so far it looks like I have five work days. Then there’s one day off, then there’s one day where all I do is reflect and write the blog post for the preceding week, so that’s something in between a day off and a work day.

Putting 5.7 against five workdays, that means I worked more than an hour a day. If I stick with my plan of working on game dev and speedrunning both simultaneously, and in equal proportions, I will probably max out around 2.5 hours a day in each discipline. That would be 2.5 hours * 5 days = 12.5 hours of game dev per week. I do see one flaw in this planning, which is that once it comes time to actually live stream my speedrunning, 2.5 hours a day for game dev might truly be unrealistic, but we’ll consider that problem when it’s here.

The most important thing that I saw come into place this week in terms of work-habits was… well, that I developed a work-habit. From time to time I’ll flip through the old classic Atomic Habits to bring some of what it advocates for to the top of my mind. Actually ‘reading’ it is totally unnecessary at this point since I’ve read it several times.

One thing that stuck out to me during this flip-through was that you cannot improve a habit that you do not actually have yet. This called to mind my own proclamation that I would try to work 2 hours a day on game dev this week - something I wrote in last week’s blog post. In reality, there was no way for me to move my productivity from where it was to this 2 hour mark that I pulled out of thin air, because there was no stable game dev process happening that could be improved on.

This week, I solidified a morning game development habit. My new morning routine looks like the following. I wake up. I make a coffee. I take Podo out to go to the bathroom. I make Podo breakfast. I do a training session with Pancake, where I have her do all the tricks she knows in exchange for treats (it’s good to do this while Podo eats breakfast, so he’s occupied). Then, I clean the kitchen. This kitchen clean can take ~30 minutes, so it’s a good opportunity to wake up and ease into the day.

Once the kitchen is cleaned, I make a second coffee, and move over to my work desk, where I immediately jump into a timed game development session. This is the only time I will work on game development all day. So far, the results are terrific. I can feel myself remembering what it takes to really work on this project.

As for what I worked on, you can check out this little gameplay snippet for an example.

Truthfully, a lot of what I am actually working on is structural. When I first worked on a 2d platformer, I envisioned fewer actions for the main character. You could only run, jump and shoot. With so few actions possible, programming the movement wasn’t that difficult. I did still use a finite state machine (more on this momentarily), but the state machine was all coded within the player object, in one script.

This time around, I am planning ahead for a lot of different actions. The first complex one you can see here is the dash, which can also be done in the air resulting in an air dash.

Backing up to this concept of the finite state machine - while it sounds like a really fancy name, it’s fairly simple. It is a programming concept that often gets used in video game development where a given object (in our case, the user-controlled player) can be in one of several different states, but only one state at a time.

This helps your code become modular, and avoids long and intricate if / else sequences that get increasingly difficult to maintain the more possible actions the player can take.

As an example, imagine coding what the equivalent of the SNES’s Y button does in this game. If we are standing next to an object that can be picked up, it should cause you to pick it up. If you are holding an object, it should cause you to throw it. If you are ducking, it should cause you to simply place it in front of you.

If you were to jump in headfirst and program in these conditions, you’ll end up making an if / else scenario that is already somewhat complicated. Once you factor in also being able to dash, or jump, double jump, or slide, the if / else conditions become an unworkable maze.

The finite state machine that I’ve been able to program for a few years now solves this issue by separating what the player’s button presses will do based on what the player is already doing (i.e., what state they are in). The step forward I have taken over the past few weeks is that instead of programming this state machine logic directly into the player (manageable for few states), I have created a custom class that generalizes the logic of the state machine so it can more-easily be expanded to cover a large number of states.

The custom class definition consolidates the functions that make the state machine work. It looks like this:

By default, being a member of this new class called PlayerState doesn’t do a ton, but you can envision how a given state might look. By default, you get set up with a reference to the player node, and to the animation player. Then, there’s four functions that you’ll commonly use.

What happens when you enter the state? For example, when you enter the “jump” state, you need to change the vertical velocity of the player to create the effect of jumping. What happens when you exit the state? For example, when you exit the dash state, you might want to reset the player’s horizontal velocity back to its default, since the dash mechanic makes you move faster.

How do you want to handle inputs while you’re in this state? Think of the previously discussed example of how the Y button is treated. If we’re in the crouched state we want Y to place a block we are holding down. If we’re in a running state, we want Y to throw any blocks we have in storage.

Finally, what animations do you want to be playing? Since states are tied to player actions, it’s convenient to also animate the player on a state-by-state basis. If we’re sliding, we want the sliding animation. If we’re in the idle state, we want the idle animation.

As you keep building out more states, the player scene starts to look like this:

The player has a camera following it, a collision shape, an animation player, a sprite sheet that the animation player manipulates, and then there’s the list of states. It’s as if the player can have one brain at a time, and the options are the different state scripts. Which brain is active is continually switching, and one and only one must always be active.

So anyway that’s where I am at so far. Let’s see how much further I can get this by next week.

speedrunning - 6 hours, 43% Learned

The slow grind of learning Mr. Nutz continued this week, with another 6 hours on the books. I am up to 43% of the game learned, which is 12 of the 28 levels.

It seems like I am capable of being right around world record pace through these 12 levels, which is a good sign. The game is extremely simple. You can basically just run, jump and shoot. Despite this, it still manages to also be extremely precise.

The world record run that I am comparing myself to was done by French speedrunner Le_Hulk, who beat Mr. Nutz in 29 minutes and 25 seconds seven years ago. Hulk sets an extremely high bar. By learning his strategies myself, I am able to see just how much work he put into this run. As speedrunning often does, every button press is measured. I am eager to go live, but there’s still more than half of the game to learn. For now, I just need to keep pushing forward. I can do this.

weight loss - -0.1 pounds, -1 pound overall

It was a slow week as far as weight loss goes. I ran four 5ks over the course of the week, and my total miles walked + run was 43.2. I was pretty dang active. But, as they say, you cannot outrun a bad diet.

My eating habits this week felt similar to the way gamedev went - I did a lot to actually establish eating habits. One successful thing about this week is that I stuck exactly to the plan I had laid out for myself. I ate lunch and dinners that were entirely whole foods six of the seven days this week, and had one cheat day where I ate whatever I wanted.

Sticking to the plan was a big win, because I successfully exercised discipline - which is something my food-life has been lacking for some time now. The only issue is that the plan didn’t result in me losing any weight. This still feels like a win to me. Like I talked about in the game dev section, you cannot improve a habit until you actually have an established habit to improve upon.

I think the whole food meals are great - I’ve been eating tons of vegetables and avoiding processed food. I think the one cheat day is also great - focusing on the fact that there would be a cheat day at some point this week did help me stay the course on the other days. Granted, I do think that this week’s results demonstrate that you can do a LOT of caloric damage in just one cheat day. But, I do still think it’s worth trying to keep it in the schedule. My activity level is also looking very good; I traversed an average of 6.2 miles a day this week. The overall volume of food on non-cheat days just needs to be lowered slightly, and I think I will be in a good place. I also want to start incorporating some fasting. I have a goal to fast one of the six non-cheat days this week. We’ll see how my adjustments go in next week’s check in.

That’s it for me! Have a great week everyone <3