I’ve been asked a few times now how the new height system in ProtoDungeon/The Waking Cloak works, and I think it’s a good time now to write it out!

This system was something I’d been tossing around for a while, but I wanted the boots (the jump item) to be able to go up and down cliffs properly. Alundra (a great Zeldalike PS1 game with lots of jumping around) inspired me and convinced me that it could be done.

If you’re familiar with the x and y axis in 2D games, you may also know about the z axis for 3D games. Since PD/TWC are 2D games, we will have to fake the z axis…

Keep reading

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.

Another month, another letter delivered right into your very phalanges!

Looking back over my development notes from this July has been pretty encouraging. It’s easy to feel like you’re not getting anywhere, so this is one reason I love keeping logs. This July, I got pretty close to grinding to a halt because I took on too much stuff, and it almost seemed like that’s how the whole month had gone. But no!

So picking up where I left off in June: tile collisions. Tile collision is a much nicer approach to creating walls for the player. It increases game performance and is much less time consuming and irritating to place than collider objects. And these tile collisions work! But they had a weird jitter when colliding that is no bueno. After loads of debugging and conversations with PixelatedPope, we discovered that the collision method was not precise enough to work with tile collision. So I put that change on the backburner.

And then I tackled jumping.

In last month’s newsletter, I talked about how this was all pretty easy to get working. And it was. But there’s another dimension (ha ha) to all this, and it’s the most complicated one: adding a z axis.

Now, many of you are probably familiar with x and y axes. In a 2D game, x is the “width” of the game world, east/west, and y is the “height” of the game world, north/south. The z axis is the “depth” of the game world, up/down. This is actually way easier to represent in 3D games, because 3D requires all three dimensions to be… y’know, 3D.

Displaying this z-index in a 2D game is pretty tricky. It’s not like you can just move stuff closer to the camera. That would just look like you’re increasing the size of things. Instead, you use the y-axis to represent the z-axis too. And while that’s a little tricky, it’s not the hardest part. The hardest part is doing this:

Essentially to get the depth all working properly (player can walk behind something but then jump on and walk in front of that thing), I had to use an object (you can’t change tile depth). But since I don’t want to make a bespoke object for every single raised platform, this object is a bit more clever. It creates its own sprite by drawing all the tilemaps under it onto a surface and then pulling the sprite from that surface (a surface is basically just a thing you can make GameMaker draw to).

And then you have to get the depth and z and so on set up correctly and blah blah technical stuff. If you’re making a game in GameMaker and you want to get jumping working with the z-axis, go check out this 5-minute video by Matharoo.

Alright, alright, so that’s a big deal, but that’s all the major stuff I should improve on for this episode, right? Don’t want to bite off more than we can chew. And that is where you would be wrong! :D

See, with jumping, we have a problem: the exterior and interiors are drawn at different perspectives. Outside is drawn from the front looking down (you see the fronts of walls), while interiors are like looking down into a box (you see all four walls). This would mean I would have to have two different ways for jumping to work based on whether you’re outside or inside. That’s confusing for everyone.

Currently (well not currently anymore), the interiors follow the classic Zelda perspective. It’s like you’re looking down into a box of a room and can see all four walls. This is so that you can easily see doors on walls, bomb those walls, etc. However, in order for you to see Link and all the enemies and stuff in the rooms and not just have it be the tops of their heads, these are drawn to another perspective, almost like they’re all “laying down” on the ground.

This decision was made for a good reason (you can see doors on all walls), but it’s also super weird if you think about it. It also gets complicated when you have multiple “layers” in a room because then you have to do stuff like this:

And this is confusing. I had players who were confused. They didn’t really know what layer they were on, whether they were going up or down, etc.

The solution is this: make everything use the same perspective. This unifies the exterior and interior; cuts down on weird walls; reads more clearly for the player; allows for a single, intuitive jumping system; and, I think, is just way nicer to look at.

Before:

After:

Okay, so yeah, I also have to redraw a buuuunch of tiles. Whee. But it’s for a good cause.

While I was at it, I updated my palette some more. I learned about “hue shifting” in color ranges, and there are a few colors that I’ve felt dissatisfied with for a while anyway. I removed one of the grays, opting instead for a similar light blue that was already part of the palette, then did a similar thing for a dark green. Then I changed some browns to make them a little less heavy and bland.

Drew a new version of the ocean tiles that I’m finally happy with! And I drew all kinds of tiles for a seafarin’ ship which was fun. I drew some waterfall tiles too, and new cliffs (8px and 16px variants). Lots of art to get done, and I’m pleased with how it’s going.

As a bit of a break, I did some long overdue optimization. Tall grass was apparently accounting for 11% of each step’s processing power, which is kind of insane. Turns out every single grass object was checking collisions with every single collider and actor object. All I need is to check for tall grass so I can display the “rustling” sprite. So I flipped it around so the actor object was doing the checking, and voila, we gain like 100 FPS. I then went through and set a few different objects to deactivate when they’re not in the current area, as well as triggering the deactivate script when the room is loaded, and suddenly another +100 FPS. Hopefully this will make things run faster for some of you folks on old potato machines.

Near the end of the month, Pixelated Pope got back with me with some fixes for the jittery tile collision. After a few tests, I implemented it in my PD3 project. It took a few attempts (the GMS2 beta was being a bit unstable), but eventually it was working! Shout out to Pixelated Pope for his hard work on this system.

And finally, I started to put it all together. This ended up exposing a lot of issues with my system, some of which I still have to resolve. Namely, 1) walking off an edge is too lenient, but if I make it stricter, the player gets stuck the cliff, and 2) my system to draw tiles on my z object does not properly handle tile animation. Oh, and building these cliff objects is painstaking.

BUT.

YEAH THIS DOES WORK. It’s pretty fun clambering around!

That’s it for this month! Onward to August!

Well, month two of this newsletter! We’re still doing this thing!

This gif isn’t really related to anything in this newsletter, but I wanted to share this because 1) there will be a few paragraphs without images and I want to provide you with some interesting content, 2) I’m sort of possibly doing more camera rework which you may hear about next month… who knows, and 3) it’s hilarious.

So anyway, yeah, I got a lot done this month. I installed the GameMaker Studio 2.3 beta, created the ProtoDungeon 3 project, and put together the git repository. Of course, I ran into a fair few bugs when transitioning to the 2.3 beta. Namely, the player would always just slide to the right…

After quite a lot of debugging (is my input library working? is there an object on the player pushing the player? are there two players pushing each other?), I discovered that the player was pushing herself. Some stuff had changed behind the scenes that messed with one of my collision checks. Easy to fix though!

Then I fixed up some ancient camera issues that have been around since the dawn of time. The camera was originally created to follow the player with lerp (short for “linear interpolation;” this is what makes the camera move smoothly). This lerp caused all kinds of little visual quirks if I wanted to instantly move the camera anywhere because it was trying to “smooth out” that movement. And it was inflexible too. Well, now I have more control over it; stuff most people probably won’t notice, but it makes things much easier on my end and does actually get rid of those quirks.

As sort of another giant rabbit trail (bear trail?) from starting actual work on Episode 3, I implemented the new floating HUD. I thought I had a ton of code that would be impossible to untangle due to the way the camera compensated for the HUD being at the bottom… but this was surprisingly easy. Now, there’s some rooms that aren’t big enough causing problems, and I’ll have to go through and resize all of them (most of Episode I will be this way). Anyway, super pleased with the new direction on the HUD here.

Before:

After:

And then the main feature: I worked on the new boots! The boots have a lot of different functions, but I’m trying to get the main one: jumping! This also went much faster than expected. I do have a lot of polish to apply still, but it does work.

Fun fact: it’s the same sprite as the ring spell object, and it ends up kinda looking like the Mario jump. I dunno if it’s gonna stay that way… but it’s not bad?

Also, please watch these gifs. I had a lot of funny moments working on jumping.

Lastly, I ran into a tile collision tutorial, so I (perhaps unwisely) chose to convert my collision system to that. It’s much more performant and way easier to change in the workflow, but it will require me to fix a few collision issues I’ve sort of been masking until now. Will this pan out? Who knows.

I’m pretty excited at my current pace of development. Of course, I’m not over-optimistic enough to say this episode will be done soon, though. :) 

Hey everyone! I’m trying a new thing. :) Welcome to the first monthly Spacefarer Newsletter. These might get a bit snazzier in the future, but for now, behold:

It’s been a while since I did anything on any gamedev project, so I needed to ease myself back into it.

I started by doing some maintenance on StudioSpacefarer.com. I hadn’t ever added ProtoDungeon: Episode II–the change was only in my drafts, lol. So I added that. I did some touch-up on the CSS and some link repair (The Waking Cloak discord has been the Studio Spacefarer discord for some time now). 

I also requested access to the GameMaker Studio 2 v2.3 beta. This has a ton of features such as sequences, tags, try/catch logic, and so on that I’ve been really longing for. Lots of stuff that will improve both my workflow and performance of the game. And… at the end of the month, I received access! I have a list of several things I want to get to that will take advantage of these new features, but the main one will be converting my cutscene engine to use sequences. This means the logo, the intro/outro scenes, and even the menu and transition animations! These are currently pretty fragile, so I’d love to make them more solid.

I freshened up the Studio Spacefarer Discord server channels with some emoji. Thanks to Mazzymon, a regular and mod, for the suggestions. I also did some other maintenance on links and freshened up bot powers to keep those pesky spammers and meanie heads out.

AAAAND…. (drumroll please): I wrapped up level planning for ProtoDungeon: Episode III! This took a lot more time than expected (as usual, lol). This hasn’t been the most creatively fertile times… lots of stress with the whole coronavirus deal, taking care of family, etc. Also Episode III is larger than the first two episodes, and I daresay I’ve put lots more effort into this one too. I’m pretty proud of it. It’s closer to my final vision for The Waking Cloak’s level design, at least for a single self-contained level (whereas TWC will have a lot more interconnection between areas).

After that, I moved on to enemy design. I’ve got two bad guys planned for this episode, not including the boss or passive traps. There might be room for one more enemy, but there’s already enough going on that I’ll probably keep the scope down here. :)

And there you have it! May!

So I’m Working on another optimization patch. I’ve run the profiler, and it looks like the object(s) taking the most time is… (drumroll please)

You guessed it: the tall grass!

Okay, so what’s happening here is each “tall grass” square is an object. Every frame, they’re checking for collisions with actors and other objects, and if so, they create a rustling effect. Unfortunately, since this is doing collision checking and ds_list creation/deletion every frame for every single patch of grass, it takes up about 12% of each frame.

I could do a quick fix on this, but I’m gonna go the slightly longer route and put together something I’ve needed for a while: a deactivation manager. This will deactivate all unnecessary instances (enemies, grass, NPCs anything that doesn’t need to watch for updates) and place them in a data structure that keeps track of them per in-game “region”. That way when the player is entering a region, the manager can go through and reactivate everything in there. When they leave, it can deactivate everything.

It’ll be a little complex since it has to work properly with save/load (deactivated objects won’t save, and instance IDs aren’t guaranteed to be the same for each run; I’ll need to reactivate everything on a save and then deactivate), but overall I think we can have it done soon. Hopefully this means a nice framerate jump for everyone.

I think I have determined also that the day/night shader is not the cause of the framerate issues some of y'all are seeing, but I have some ideas for improvements as well just in case.

The second episode of ProtoDungeon is just about complete, and I hope you’re all looking forward to its release as much as I am! :D

And as devtober (working on the game every day for the month of October) is over, it’s about time for a retrospective too. I prefer that term over “post-mortem,” which makes it sound like the project died (though I guess this episode is graveyard-themed, so that might be appropriate!).

What didn’t go well:

Mainly, I took on too much. This wasn’t intentional, but it WAS a result of:

1. Not planning long-term.
2. Not breaking down big tasks and spreading them out

For example, the menu should’ve been broken out into the basic menu, audio settings, video settings, saving, and control remapping, and then divvied them up over the next few episodes. Instead, I did ALL OF THEM AT ONCE. It was a big task, and doing it all at once slowed me wayyy down. The lack of variety made it tough to make good progress.

Also the mausoleum… as happy as I am with the results, building out an extensive series of logic that I would only ever use once… bad idea. If I’d thought it through, I would have built it differently. Unfortunately, by the time I realized this, I was already halfway through, and undoing it would’ve been more work than just forging ahead.

What went well:

Devtober! I was able to work on the game every single day, and despite that I wasn’t able to finish the game by the end of the month (not necessary for Devtober, just something I wanted to do), I made a ton of progress in little tiny steps. Momentum is a great ally.

Speaking of momentum, posting every day on the social medias—even just images of code or my Trello board—helped regain some of the interest that had waned over my quiet months. Posting every day forever is certainly not sustainable, but it’s something I could consider for once or twice a week.

Oh, and despite that I did too much this episode, I’m happy I won’t have to build all these systems in the future. :)

What to start doing next time:

• List out the remaining (known) tasks for the whole ProtoDungeon series
• Make sure the tasks are broken down to an appropriately small size
• Build these into a (flexible) roadmap
• I wouldn’t say this went badly, but I’d like to keep early alpha testing more restricted and then only open it to patrons when it’s closer to being finished.

I think with some better planning, I’ll be able to finish Episode III quicker than six months.

The major new things we got in Episode II:

• Ring of starlight—a new item is always a big deal and will be for every episode!
• New audio engine—thanks to Wandersong for this! I was able to do some cool stuff with two different versions of the same music track
• Menus—Episode I was just a static screen, but now we have new/continue game, audio settings, graphics settings, and controls remapping!
• Autosaving—a huge undertaking, much bigger than expected. But now you can actually quit the game and come back and pick up where you left off. This is part one of the complete saving system, but it is the biggest, most difficultest part.
• NPC—I’d planned a lot more dynamic action for this guy walking around and tending to the graveyard, but I managed to trim it down after spending so much time on everything else.
• Day/night—another huge undertaking, including the ability to switch between day/night, lighting, day/night sensors and logic, and the palette shift shader (which means I had to rewrite how everything gets rendered due to the pixel scaling).

That’s not to mention dozens of fixed bugs and incremental improvements in various areas!

Anyway, I hope you’ll look forward to Episode II’s release on November 9. If you haven’t yet, check out Episode I here (it’s free!). And if you’re a patron, I’ll be opening up the poll for the Episode III item soon!!