Alright, so I’m a bit late here, haha. April had a good start but ended kinda crazy. Our two-year-old got sick for a few days (just a cold, not the ol’ COVID-19), which wiped us out, and then she had a lingering “mood” for the rest of the week, lol. General exhaustion made me more interested in playing games than making ‘em (currently playing Rune Factory 4, which is a good time!). So no fancy images and stuff this time. Hope y’all don’t mind a bit of text.

Anyway, here are the news.

When playing with a gamepad, I’ve noticed the eight-directional movement feels really clunky with the stick. This clunkiness happens in a lot of older games too, for both eight- and four-directional movement. For example, on NES Online and SNES Online on the Switch, I can’t use the joystick at all. I have to use the d-pad.

In the first two ProtoDungeon episodes, I mitigated some of the issue by tinkering with some of the thresholds, but when I started testing a gamepad for Episode III again, I realized this was still not ideal.

Juju, who wrote my old input system, is working on a new open source input system. I haven’t contributed code, but I did give my input (hehe) very early on. Now after coming back to look at it, it seems to be just what I need. So I spent the first week of April swapping out input systems (which isn’t as easy as you might expect if you’ve never done it before, BUT it was way easier than I expected). Then I modified the movement code to use the new input_direction(), which gives much finer control to the stick.

But that much fine control–fully omnidirectional–was actually fairly nauseating. It was difficult to walk in a straight line. I ended up rounding the input direction to the nearest 22.5 degrees, meaning we were now at 16-directional movement. It feels really good! And as I played more over the month, I tweaked it further to lend more weight towards the ordinal directions (north, south, east, and west), in addition to scaling the speed slightly based on how far you’re pushing the stick. In my opinion, it’s now preferable over the d-pad or arrow keys (though don’t worry, I do the majority of my work with the arrows, and they are very functional and fun.)

The new input system also gave me an easy way to set gamepad axis thresholds, which is something a few people have already asked for. This is a setting in the behind-the-scenes file, but probably not an option I’ll add in game yet since that requires some rework on menus.

Then on a whim, I threw in gamepad vibration! This wasn’t related to the input change… I just wanted to do it, lol. It was a small thing that took me about 30 minutes but adds a surprising amount to the game. I can choose the intensity of the vibration based on what’s going on, and I added a setting for players to control the overall intensity (or turn it off). There’s no menu option for this yet, either. Hopefully I’ll get time for that in Episode IV.

I created a free GMS2 extension out of my vibration system called Good Vibes! It can do all kinds of fancy stuff using animation curves, and it handles some of the weirdness of GMS2’s vibration functionality too.

Next, I created a Linux virtual machine to allow me to export stuff to Linux! I tested this successfully with the current version of PD3. Tried to immediately export PD1 and PD2, but those projects don’t exactly work anymore–I’ll need to do it from the current project after I go through and apply engine changes to them (current project always contains all episodes, don’t worry, nothing is lost).

Finally, I ended this month’s changes on two separate things, neither of them finished: true borderless window toggling and proper depth sorting.

Borderless window toggling in Windows isn’t something possible with vanilla GameMaker. I got a small DLL from a friend, though, that can force the toggle. The only reason this isn’t finished is because the application surface gets stretched weirdly, and I haven’t figured out how to offset it properly yet. This one isn’t required to go live at all, so not sure when I’ll get back to it.

Depth sorting IS required, though, and that’s what I’ve been wrapping up. My z-height system is pretty complicated, and the old depth system didn’t always work–and when it didn’t, there wasn’t much that could be done about it. Occasionally you’d get weird overlaps where the player was under the ground tiles and so on. I did come up with a depth method that would’ve resolved it, but unfortunately it would’ve gone past the supported min and max depth that GameMaker can handle. So I switched to a simple grid sort system, where I can basically just chuck everything into a ds_grid, sort it, and then trigger each object’s draw event in order by iterating through the grid.

There are a few kinks to iron out. First, I need to fix cliff sprite generation. Cliffs create their own sprites based on the tiles beneath them–this way they can be properly sorted so the player can either walk on top of them or behind them. Currently there are some bugs with the generation so that the sprites are too tall and they don’t properly handle animated tiles.

Second, I need to get enemy sorting working too, which will be much easier when I’ve put enemies back in the game. :) The old way was to manually set their depth based on the player position, but that won’t work anymore. That said, with the new grid sorting method, this may not be an issue at all. We shall see.

I’m back!!!

Oh man it feels good to be doing gamedev again (and actually enjoy it).

So first things first, we had a baby!

This lil guy is super cute and has made an awesome addition to our family. As you can probably guess, this is why I spent a few months not doing gamedev. Even when I had time, I didn’t have the emotional or mental bandwidth to work on ProtoDungeon. And that’s to be expected!

But there was another issue: a weird bridge bug. Essentially, you could walk under a bridge… and if you tried to walk on it, you’d fall through it. I could not figure this thing out. Collision was working, options were all set up correctly, etc. Every time I thought about working on my game, I knew this bug was facing me down and I’d have to address it. And I couldn’t get over the mental block.

So I took another tack (I make it sound like this was a choice, but it was more a compulsion): something I’d been thinking about for a while was learning 3D. I wanted to see if I could get some kind of fusion between 3D and pixel art. I won’t go into all that here, but I had a good time, and it really primed the creative pump. If you’re interested here’s my twitter thread, and here’s a thing I made:

At last, around mid-May I had worked up enough courage to finally address the bridge bug back in ProtoDungeon. My 3D journey not only got me some cool skills, but warmed me up. And also the more I thought about it, the more I was sure it was due to one particular piece of code: the edge slip.

This was here so you didn’t run into scenarios like this, where you’re “floating” on the edge:

Basically it would slip you off the edge if you were that far over it. Makes sense, right?

Well, unfortunately, there are a LOT of weird edge cases (haha) where this is straight up broken. Like the bridge. The bridge was so narrow that it just always assumed you were on the edge, so it’d just push you off (rude). And there were plenty of places where you could fall off and just get horribly stuck.

And, sure enough, deleting that code made all of these things miraculously start working.

That felt really good. And even better, I felt like I could keep going! I decided to listen to something my instincts had been saying about the lv3 boots: the dash roll wasn’t working.

The lv3 boots, while equipped, would transform the roll into a dash, making it faster and giving you i-frames (invincibility).

This was fun, but it had problems. It wasn’t intuitive or consistent with how the other items worked. I could’ve figured out a way to teach the player how to use it, probably, but it also wasn’t particularly useful. It meant, first, I’d have to contrive some kind of environment mechanics to make the dash useful, and I don’t want to get too contrived. And second, it meant the standard roll was not actually very useful at all.

I brought this up on the Studio Spacefarer Discord server and after some discussion, I decided to go back to one of my very early ideas from years ago: adding a Pegasus Boots-style dash which the player uses by holding down the item button, “charging it up” via a jump and sprinting on hitting the ground. It sounds complicated, but it feels really good. No invincibility, just crazy speed. Then the roll could get the i-frames, making that more useful too. So behold, the new dash:

And, uh, yeah, this is SUPER fun. And while it’ll be useful in puzzles and stuff, it’s also a good way to just get around (as long as you don’t crash into anything… or maybe even if you do). The boots are all about travel and movement, and while a dash-roll could be included in that, I think a dash-sprint gives a lot more bang for your upgrade buck.

I’m happy to say I got a lot of other stuff done in March, even though I only worked about two weeks total. Here’s the full list…

Changelog:

• Fixed some incorrect z-object cliff placement .
• Added bridges that work with the new system (can go over/under them).
• Fixed a bug that caused bridges to be submerged at the wrong level.
• Things fixed by removing the edge-slip code.
• Fixed coming out of the water onto a ramp.
• Fixed umping up to a ramp.
• Adjusted the ground logic to prevent getting stuck when falling down a ledge onto a ramp.
• Completed moving the beach “down” on the z-axis to accommodate tide rising and falling.
• Removed the old roll dash for the lv3 boots and replaced it with a sprint dash which can be “charged up” with a jump.
• Added i-frames to the roll.
• Force the switch to the “item get” state to prevent issues with sprinting and rolling into items.
• Started testing various other previous bugs to see if they were resolved with the latest changes (a few are, so far!).

That’s all for this month. Thanks for reading!

I love and hate debugging. It’s frustrating to have a problem and have to work it out before you can continue being creative. On the other hand, it’s a puzzle, and I like puzzles. Working them out feels really good. Like beating that boss.

Anyway I don’t know if this is helpful to y’all, but I decided to write up a blog on my debugging process. (Maybe I’ll do more in the future under the “Debugblog” series??)

So here’s the issue.

In this gif, I’m ONLY pressing one key at a time: left, right, up, or down. But the player is moving at an angle somehow.

The weirdest part: this doesn’t happen all the time, and it only happens in daytime. This is baffling.

So the first step in debugging is we need to replicate the issue. When I initially found this bug, it was only happening on a random screen and just slightly so. I ignored it for a while. When I saw it happen again, I started making mental notes of the conditions in which it occurred.

Keep reading

This is the second year I’ve participated in Devtober! Game dev every day for a month can be tough, but it’s a great way to build up some incredible momentum.

Right now, I’m definitely feeling about like I did back in ProtoDungeon: Episode II, mired in the menu and saving systems. It’s a lot of gritty, technical work with loads of mysterious bugs, so I don’t necessarily feel like I have momentum. Even looking back over my progress didn’t inspire much enthusiasm until I remembered: almost nothing worked at the end of September. And reading through September’s devlog… well, gosh darn it, maybe I’m doing alright.

My goal for Devtober was to have Episode III playable from start to end. Well… the results are in:

Is it pretty? No!

Is it feature complete? No!

Is it bug-free? Definitely not!

Is it playable? You betcha!

So we made it! It was kind of in a super rickety jalopy that’s constantly backfiring, with wheels that keep slipping off and a floor rusted through, and there are a hundred angry cats in the backseat (for some reason), but we made it!

In our retrospectives at my day job, we always go over a few basic questions. What went well? What didn’t go well? What can we do better next time? So I’d like to ask those here:

What went well?

• I actually achieved my goal: the game is end-to-end playable.
• Mid-month vacation–stepping back, only working with pen and paper–was a great change of pace.
• I made a lot of progress considering the type of thing I’m working on.

What didn’t go well?

• Z-height bugs hounded me at every step.
• I never even started work on the boss or the secret challenge room.
• Most enemies and obstacles are not in the game.
• Pretty discouraging dev overall.

What can we do better next time? (Referring here to Episode IV)

Limit scope, limit scope, limit scope. Episode III would have been pretty okay if I hadn’t decided to completely rework z-height. Once I saw how big a task that was, I should have been much more ruthless on the cutting floor. As they are now, Episodes IV-VI are pretty lightweight on new features, so they could’ve taken more of the load.

Also, Episode III is big. It’s nowhere near as big as The Waking Cloak, of course, but it’s definitely much bigger than it needed to be for a prototype dungeon. That’s more time filling it out, more time decorating, more rooms in general.

Also with that in mind, I have decided to cut the boss for Episode III. I had plans, but nothing implemented. Instead, I’ll wrap up the episode similarly to the ends of Episodes I and II: something simple.

[13] Most of the way through building and debugging this room before realizing this puzzle won’t work based on what the player has at this point……… The original design did work but had a fatal flaw I’ll have to work out.

[14] It might not look it with all the random bugs and visual glitches here, but this is a major step in the right direction since yesterday!

[15] Going on (much needed) vacation, so I won’t be posting for several days. I’ll keep working on stuff! Though at a friend’s advice, not going to “force” it. Anyway, today I worked on a handful of things. Started fixing the cliff depth sorting! (Yes, bad shadow.)

[16-17] Went on a hike. Haven’t touched ProtoDungeon. I don’t even have my laptop here. Feels so good to decompress!

[18] Since I (intentionally) left my laptop at home, working on dialog and boss design on good ol’ paper.

[19]  No pics to show since it’d just be blurred pencil/paper again. Fleshed out ideas for the boss (a simple one so Ep3 doesn’t take me TEN YEARS TO FINISH) and started concept work on the Magic Fan dungeon. Might do the same for the Bell and Sword+Chalice dungeons!

[20] Great progress on next dungeon mapping. I’m actually to the point where I miss working on PD3 now! Which is good, since we’re heading back home tomorrow.

[21-22] Reworked how ground level is calculated. No more swapping cliffs in and out between night/day. The ocean is now at “sea level” at night and up +16 in the day. Much simpler! Shoutout to levitating block, red door, and sprite glitches on the left. Lots left to do.

[23]  Block work. I fixed stuff so they don’t get shifted up when switching rooms, but now they get shifted down when loading… more fixing to come. Fixed the block collision and allowed walking ON the block though!

[24] Every time I turn around to fix one bug, the bugs behind my back I already fixed come out to play. Today I fixed the teleporters (again). There was an issue with the target z not being set properly, meaning you’d end up behind the cliff here.

[25] And then there’s days like today where when you fix one bug, you accidentally fix another bug. Jumping over gaps works now! :D

[26] I worked on the biggest interior in the game. Getting all the cliffs to line up nicely in a way that’s visually easy to parse.

[27-28]  Yesterday I spent trying to figure out why THIS ONE TELEPORTER wasn’t working. Eventually discovered it WAS working. There just wasn’t a region object to setup the area/room, so the game got confused Today I’m getting that big ol’ cave working!

[29] Today, I fixed these rocks. That is all.

[30] Today I updated how items get set/reset. Some previous fixes were combining their powers to put the items in some weird places. I nicely asked them to please calm down. Now you can grab keys and stuff!

Okay, so keeping up with multiple social media channels along with actually doing Devtober and a full time job and a family and stuff… yeah, it’s a lot, lol. Maybe when Studio Spacefarer has sold a hundred gajillion copies of The Waking Cloak, I’ll hire a community manager.

I have to break up these posts because tumblr is deathly afraid of gifs (I can’t blame it, gifs are the worst). So here’s 9-12.

[09] Teleporter objects (doors, stairs, etc) were especially broken by the recent change. Took me some of yesterday and all of today to fix ‘em.

I don’t know how that lock pillar got there.

[10]  It’s been a fight, but the bottom section of the map is now working (if not fully decorated, please excuse my mess). Grab you some lotus boots!

[11]  Testing pits! You guessed it–z height messed these suckers up too. I’ve also removed the “pit pull to center” behavior (originally from the Game Boy Zeldas). It doesn’t always work. Prior to that fix, you could just walk across the pits.

[12]  Working on the next part of the map, this interior. Blocking out some basic WIP graphics so I know where things go (cliffs in my whitebox draft didn’t properly account for “half” heights like 8 and 24). I’ve had to modify this room a fair bit already!

Alright, here’s another round of Devtober posts. Making some good progress. :)

[05]  Episode III summed up in two words: Cliff Stuff. All I ever do is cliff stuff. Save for a few twitchy areas, most of the south part of the map is complete (cliffwise). Look how much neater it is than on day 1!

[06]  Got tired of cliffs so I made an inspector to inspect the cliffs (and other things). (I’ve been using this CONSTANTLY since I added it, good times)

[07]  Today. Today was gonna be the day I fixed cliffs once and for all. (reeeeeally hoping to wrap up cliff bugs in the next few days….)

[08]  Holy crap, I think I fixed it. “Negative” cliffs (z height values under 0) were causing so much trouble. I solved it like a true hackzor: make EVERYTHING positive. “Sea level” is now z 96 instead of z 0. Suddenly it all works.

I’m ironing out a ton of smaller wrinkles now. This change affects loading, object placement, etc. Made lots of good progress on those today though!

Hey, so, yeah, it’s Devtober! I forgot to mention!

I joined last year when working on ProtoDungeon: Episode II. Essentially it’s “work on your game every day” for the month of October to build good habits. I kinda do this already, but it’s always fun to join in with everyone!

Anyway, in lieu of a monthly newsletter for October, I’m gonna be posting (mostly) daily on ProtoDungeon: Episode III’s development. Enjoy! Here’s days 1 through 4!

[01] I started decorating! Not just so it’s nice to look at, but so I can figure out how to place these dang cliff objects, lol.

[02]  Did some more decoration work today. Feels good! Then I bit the bullet and updated my region sprites. Now it’s easier to see where one area begins and ends and not block half the screen lol. I’d rather not show you the PD3 map yet, so here’s PD2 before/after.

Before:

After:

[03] I drew this! Inspired by a design by one of the server regulars.

[04]  Dog woke us up at THREE IN THE A.M. so I got up at 5 (after not being able to go back to sleep) and did this.

More to come! Maybe stuff will work! Who can say!

Alright, here we go!

I picked up where I left off in August: wrapping up the tileset for the episode. Water details, beach details, waterfalls, spikes, cracked floors, etc. Lots of work, especially since I haven’t done a lot of art recently. I’m really proud of the improvement here though.

Next I started on another big task: enemies! I’ve done these before in The Waking Cloak, so there’s a decent framework. Definitely still a big deal, though, given how much I’ve already done on this episode. 

I have two enemy types planned, one of which I’m (creatively) calling a hopper (not the official name but probably what it will be called in code forever). In terms of gameplay it’s like a cross between a goomba with butt spikes and a tektite. Will this be annoying to deal with? Maybe! Hopefully not too much. That’s what testing is for.

Anyway, to give you an idea of what went into this single enemy:

• AI - fairly simple, just runs every step and has a chance to trigger the jump state
• States - idle, jump, death
• Art - sprites for all states, facing both east and west each
• Hitbox logic - hopper hurts player with spikes, player hurts hopper without spikes
• Jumping - tweaking this to feel right without being too fast or too often definitely took some time, as well as flipping the spikes orientation
• Player impact - tricky to get that little bounce without feeling mushy
• Confining to a single area - will be useful for all enemies
• Work out bugs with pushing the player on hurt - will also be useful for all enemies
• Enemy manager - keeps track of enemies, deaths, etc.(I ended up putting this on the backburner for another episode; will be mostly useful when I have multiple rooms)

The other enemy? I want to keep it a surprise.

I took a break from enemy design to update the save/load functionality. Ever since I added saving and loading in Episode II, whenever the game had updates, there was a high likelihood that a save file from the old version of the game would break in the updated version.

The reasons for this are numerous and complicated, but the fix is to add save file versioning. With this, I save a version number to the save file, say, 1.2.0. When I make changes to the game, I will also update this number in the game itself.

For example, say a player saves and quits their game in a certain location. Then say I move that entrance to a room in version 1.3.8. If the player updates and they will not be able to load in the proper location and instead might load inside of a tree or a wall and be unable to escape. Thus the fix: the conversion script would check the save file version (1.2.0) against the game version (1.3.8). It would run a line of code to check whether the player is in that position, and if so, move them to the new room entrance.

I wrapped up the hopper, then did a quick bugfix for the cliffs. There was a case where if you jumped at a cliff and hit the ledge just right, you could do sort of a glitchy jump where you weren’t falling or getting up on the cliff. It didn’t hurt anything, but it didn’t look good. I actually got frustrated trying to replicate the bug after fixing it which… uh… I guess means I fixed it.

Then I circled back around to ramps. Westward-facing ramps had incorrect height calculations, meaning they act just like eastward-facing ramps, so I fixed that.

Some more attempts at ramp collision made me question whether I wanted to still do them or not. Of course I’d still have north-facing stairs, but collision is much simpler on those. Since I only had one east/west ramp in the level design, I removed it and decided to only do north-facing ramps.

NEXT… the fun part! The culmination of all my plans for the dungeon, creating the map in Tiled, painstakingly building the new mechanics, and so on: actually creating the dungeon room.

Of course, I’ve changed the functionality of the boots since I last planned the dungeon. This has been a pattern starting back in Episode I, and it’s a result of taking theory and putting it into practice. For the boots, here’s what changed from my initial design notes:

1. Lv1 - Jump height has been reduced from 16px to 12px. I decided partway through level design that not only could you jump over pits, but you could jump up cliffs. But jumping up the standard height of 16px breaks a lot of design; cliffs would have to be very tall to serve as blockers, and various other obstacles break too. 12px jumps let you go up 8px cliffs without jumping over various obstacles. However, the map design did not yet account for 8px cliffs.
2. Lv2 - Diving has been added. Not sure how I overlooked this, but here we are. Diving below the surface is great for ducking under projectiles and maybe finding some secret stuff.
3. Lv3 - The dash no longer serves as a “long jump.” This solves a handful of redundancy issues (mainly jumping/swapping), but it did require a map update. Instead, dashing only acts as temporary invincibility and a faster roll. This will still let you dash through attacks and so on, but not over pits, and I plan to use this in Episode III.

So I made quite a lot of changes, all told, from the Tiled draft to the room in GameMaker.

I broke one of the cardinal rules of programming: instead of making small changes and testing often, I got lazy(?) and made a BUNCH of changes and didn’t test for days. I figured adding collision tiles and water tiles and cliffs wouldn’t cause too much trouble.

Well. They mostly worked. But the first foray into the dungeon was pretty janky with loads of bugs. It was honestly pretty discouraging, and I wanted to just stop and give up for a while. But I started breaking down the problems into more manageable chunks. That was enough to keep me going. Here are the bugs I tackled this month:

• Made tile collision respect z-height.
• Fixed an issue with the east area border snapping the player back.
• Prevented jump in midair
  
• Fixed camera dip when diving
• Fixed cliff sprite generation drawing invisible layers (usually leading to garbled, neon-colored cliffs)
• Prevented teleporters (stairs, cave entrances, etc.) from triggering when submerged.
• Fixed camera movement issue when loading the game that started the player in the wrong room (sometimes within a wall).
• Fixed issue with being able to jump into tile walls and get stuck.
• Fixed cliff collision box calculations (I messed this up earlier this week when messing with tides interacting with cliffs).
• Made one high cliff at the bottom of one of the areas shorter, thus fixing a bad collision issue.
• Rigged up a way to allow high tide to smoothly allow you to walk onto floors at both 0 and 16 (the secret is to lower all adjacent cliffs by 16 at high tide).
• Fixed invisible daytime tiles when loading a daytime save file.

I also rigged up a way for “tides” to work, meaning tiles and collision changes depending based on day or night. 

Near the end of the month, I took one more swing at (north-facing) ramps. This ended up being a whole thing. I couldn’t use my stair object like before because the player actually has to change z-height. I temporarily forgot how triangles worked.

It’s hard to see here, but the player needs to make it up to a z-height of 48. However, she’s only getting up to about 37. This completely baffled me for about an hour. I tried changing the calculation, the collider, and so on, with no results.

Well. As it turns out, I was trying to force the hypotenuse of the triangle (the ramp) to be the same size as the sides (the ground and the cliff). This isn’t physically possible, lol. When you’re only factoring in two dimensions, this isn’t an issue, but when you add the z axis (even if it’s faked), you have to obey the laws of geometry.

(still some work to do here; ramp movement is very fast and the shadow is all over the place, but it does work).

After that, the bugs were getting me down again, so I decided to switch gears. I added the boots, chapel keys, regular keys, and some rocks! This doesn’t sound like a lot, but it goes a long way towards making it a real, functional game.

And lastly: October is going to be fun! I’m doing Devtober! I effectively do this anyway–a little bit of game development every day–but it’ll be good to join everyone again. My goal is to have everything playable by the end of the month from start to finish (but not necessarily bug free). Wish me luck!

Peace out. Here’s an early enemy bug.

I spent the first week of August cleaning up cliff and z-object stuff. Not very glamorous! I was definitely ready to move on, but it had to be done. Everything I mentioned at the end of the July newsletter? I tackled it.

1. Falling off ledges now works properly. This was surprisingly difficult.
2. Tile animations on z objects is now handled… 
3. Building cliffs is much less painstaking now. The objects automatically resize themselves for proper collision, and the sprites are all color- and number-coded.

And more: lots and lots of weird cases and stuff fixed. Cliffs at a “negative z” (below sea-level, essentially) were a whole ‘nother animal. They’re still a little janky, and I’ll have to do more manual intervention for these.

Also, area transitions were only based on x and y, so throwing z into the mix messed those up hardcore.

Once I got past all that, I decided to tackle swimming!

Talk about a switch. Cliffs took me a few months. Swimming took me, like, a couple days. Even the stuff I thought would be hard (falling off waterfalls, slippery momentum, etc.) ended up being more or less built in to the systems I have, lol, so I basically just wrote a line or two of new code for those. Diving took an extra few days on top of that, mostly just because I went back and forth on how to modify the z.

Next came rolling. (You might say we’re on a roll.) This was the first bit I’d copied over from The Waking Cloak project in ages. The Waking Cloak will eventually be built afresh on the ProtoDungeon foundation, but I guess the old code does still have some useful stuff in there!

I did spend an evening converting my mess of move speed/direction/vectors to create a Vector2 struct in 2.3. Structs are a nice breath of Object-Oriented Programming in GameMaker. :) Then I leveraged this so I could easily modify the direction of rolling, jumping, etc. I could have done all this without, but it makes it easier.

“Rolling” in the water will be a dash. Unfortunately, in doing all this, I broke the “slippery” friction on water, which for some reason took me a few days to fix.

Roll cleanup from there involved allowing jumping into a roll and rolling into a jump. For gameplay purposes, these don’t let you jump further or anything, but it adds some usability. Without this, if you press the “roll key” right before landing, nothing happens, and it feels clunky. With this, if you press the roll key while jumping, the character will roll immediately when they hit the ground. It feels really good!

I updated the controls to match the new rolling. Space and shift now both trigger rolls for keyboard, and the left face button does so on the gamepad. This also meant I had to update the control remapping settings (which needs a UX overhaul, I’m breaking a couple guidelines here, but no time for that now lol).

Next came the dash. This only took a few days, since it’s basically the same as a roll, just faster (not shown in the video, I sped it up after recording) and with a cool afterimage effect! I had to take a video instead of a gif to capture the full effect (gif framerate is too low, so it’s much more “blinky”). Anyway yeah, click this giant link to watch, lol.

And then I rounded out the month by updating various tiles and sprites. It was pretty tough to get back into the swing of things, art-wise. Thanks to the Studio Spacefarer Discord server, though, I’m pretty happy with the direction things went.

Check out the “before” in last month’s newsletter.

Oh, also, on the penultimate day of the month, I felt like taking a quick break from all of everything to install rt-shell, a plugin that lets you do debug commands. My previous debug method was a list of hotkeys. It was pretty limited! The new one is extensible (I can write my own scripts), so it’s gonna be really helpful.