Wizbird Games

Devlog #007 - Commit #2036 (Patreon)

Published:

2026-02-27 16:00:18

Edited:

2026-02-27 23:51:17

Imported:

2026-09

Content

"Where did February go?" I always ask myself that, but it is a shorter month, so... Anyway.

Game Implementation

As I correctly predicted in my previous devlog, 3-3 is taking a bit longer. That's the unfortunate but not unexpected news.

The better news is 3-3 is close to done. Since last time, I:

Prototyped out the idea I had for the op.

Implemented a bunch of algorithms and other stuff to make it all work (some of which can be reused in future operations).

Decided it was likely I'd be going with it, and added some passable graphics.

Pushed the game's 2000th commit.

Wrote and "directed" all of the episode's pre-op and briefing portions.

Drafted its in-op dialogue.

Next, I'll have to connect the dialogue up to things that happen in the operation. I'll also be doing some balancing and numbers-tweaking to make it "feel good". Once that's done, I'll have to further balance it out for each difficulty, as well as add score/rank thresholds. And finally, I've still to write the post-op story.

Look, code! It's related to 3-3! Have fun figuring out what it actually does and in what context, though.

So, that's all going well.

The great news, though, is 3-4 is about a third of the way done.

CHIRAL REACTION NEITHER NEGATIVE NOR POSITIVE?!

Yes, in order to not burn out, I've jumped around a bit and have been working on a few different things, swapping it up every now and then when I get "bored". It seems to be working decently enough.

Alpha Testing

Episode 2-6 (!) was released to Residents and higher. Overall, it seems to be well-received.

As always, there are a few minor annoyances and things that need to be tweaked, but that's definitely on the "extra polish" side. Focus on getting everything down first. Polish can come at the end. We can't polish something that doesn't exist.

Along with that, I've trialed reworks for both Hyper-Specced Nanites and Force-Injected Nanites. The former is a bit too strong, and the latter is nearly useless.

Nanites bonus is now consumed +50% faster.

Instead of increased Nanites healing at the cost of lowered Syringe capacity, F.A.S. makes the Syringe faster at the cost of a bit less healing power.

These newer versions seem to be a bit better. I'll keep playing around with the OCs to make sure they feel nice by the time 1.0 is here.

Commit Deepish Dive

So, here's a funny commit.

#2016 [bf7ad4b] Fix auto-completed lacerations granting -69 TECH

Basically, in certain cases, lacerations can report being completed with an "OK" and -69 TECH points. Somehow. This can happen at the end of 1-4 when a certain event happens.

But... why -69 points? Surely it was me putting in the funny number as some sort of placeholder, right?

Actually... no. I had no idea why this was happening. It was a minor bug, though, so I didn't really care too much about it. But when developing 3-3, it came up again, and it was very obvious. So... I kind of had to fix it.

Here's a quick explanation. To calculate how much TECH a laceration is worth when it's completed, it relies on a variable called "quality". It starts at 0.0, and is set by the Sutures tool when the Sutures sew up that laceration.

Usually, "quality" is guaranteed to be at least 0.3. (The game deems that anything below that "doesn't count as a suture". Hence how you if draw really really bad sutures, the game won't "apply" them to a laceration.)

However, if a source other than the player "completes" it, that number is never set. "quality" remains at 0.0.

And I figured out that the -69 TECH bug happens only when the player isn't the one doing the "suturing".

With that 0.0 in mind, allow me to show you a function that's called to calculate a laceration's TECH value. I'll start with the raw code, and then replace the variables with actual numbers. Keep in mind that 0.0 is the "quality".

return int(lerp(tech_poor[0], tech_poor[1], Game.get_lerp_pct(MIN_QUALITY, FINE_QUALITY, quality)))

return int(lerp(-25, -10, Game.get_lerp_pct(0.3, 0.4, 0.0)))

return int(lerp(-25, -10, (0.0 - 0.3) / (0.4 - 0.3)))

return int(lerp(-25, -10, (-0.3) / (0.1)))

return int(lerp(-25, -10, -300%))

...lerp? Don't worry, I can explain. Consider the numbers [-25] and [-10]. I want to linearly interpolate ("lerp") between those two numbers depending on a % that I provide.

So, if I give it 0%, I'll get [-25] back. If I give it 100%, I'll get [-10].

If I give it 50%, I'll get [-17], because that's about halfway between [-25] and [-10]. See?

Alright. In this line of code, I'm expecting a % between 0% and 100%. That % is calculated under the assumption that "quality" is between 0.3 and 0.4, and that's because MIN_QUALITY is 0.3 and FINE_QUALITY is 0.4. Qualities higher than 0.4 would have been handled in code before the code I'm showing you. Qualities below 0.3 should be impossible. (Remember, I said, "usually, quality is guaranteed to be at least 0.3.")

Uhh. Quality is actually 0.0, which makes the % calculate to -300%.

It was meant to only take numbers between 0% and 100%.

100% is [-10].

0% is [-25].

-100% would be [-40].

-300%, which is what we have, would be......... [-70].

I used lerp, not lerpi. In other words, I'll get a floating point number back, not an integer. And floating point numbers like to do really funny things with division.

I think that the [-70] we're getting is actually more like [-69.9999999...].

And guess what int(...) does? It truncates a number; it chops off the decimal.