1.5M ratings
277k ratings

See, that’s what the app is perfect for.

Sounds perfect Wahhhh, I don’t wanna

March 2021

Posted on April 02, 2021

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!

image

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:

image

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:

image


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).

image

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:

image

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!

devlog devblog The Waking Cloak ProtoDungeon gamemaker game development pixel art

DEVTOBER 01 - 04

Posted on October 04, 2020

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.

image

[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:

image

After:

image

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

image

[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.

image

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

devtober devlog devblog gamemaker gamedev pixel art retrogaming
Episode I version 2.0.x and macOS support!Happy New Year everyone! I hope it’s is a good one for all of you. Here’s to another year of community, friendship, and gamedev. :) So… it seems like a good way to start off the year is with a big ol’ update...

Episode I version 2.0.x and macOS support!

Happy New Year everyone!

I hope it’s is a good one for all of you. Here’s to another year of community, friendship, and gamedev. :)

So… it seems like a good way to start off the year is with a big ol’ update for ProtoDungeon: Episode I! Not only have I made a TON of changes thanks to developments from Episode II, but now available for the first time is… 

(drumroll please)

PROTODUNGEON ON MAC!!!

But even if you’re not a macOS kind of human, don’t fear. As mentioned, this update contains quite a lot of updates for both PC and macOS versions thanks to Episode II. Here’s the full changelog:

From Episode II:

  • Lighting (reorganized the the torches in the level, as the new lighting draws emphasis to specific places; some places did not need to be emphasized, while I was able to take advantage of the lighting to draw attention to other locations).
  • Menu system (including a new Episode I title card).
  • Updated logo.
  • Saving/loading (all things considered, this dropped in surprisingly well; I did have to add a few extra cases to fix, such as falling through a pit to the level below).
  • Graphics settings.
  • Audio settings.
  • Updated to the Wandersong audio engine (also updated all audio container names to use constants instead of writing out the strings every time… there were way more of these than I expected).
  • Key remapping (new default keys as well to match the updated defaults from Episode II).
  • Ability to jump off all cliffs (had to rearrange some stuff to prevent softlocks and other issues).

Other improvements:

  • Repaired swap mechanic–this had broken after changing some of the underlying code for another mostly-unrelated system.
  • Updated the tiles for the pits that lead to floors below–these should be more distinguishable from the normal hazard death pits now.
  • Updated the swap spell item descriptions to be lore-based for consistency.
  • Simplified the lv1 swap spell puzzle, as it was trying to teach too much all at once and MANY players found this confusing (this was one area that the new lighting came in handy too).
  • Updated the lv2 swap spell puzzle, as it never actually taught the player how to USE the lv2 spell–this was the trickiest change, but adding a new room underneath both gives space for a lvl2 teaching puzzle and makes the punishment for falling a lot less brutal.
  • Fixed a collider in the outside room transition.
  • Updated the object activation/deactivation manager to account for falling to the floor below.
  • Updated the player “fall to target” state so modifying the target coordinates elsewhere won’t interfere with this state (“targetX” and “targetY” are variable names used for a handful of different states).
  • Tweaked the top of the teleporter collider so you can’t accidentally miss it.

Play ProtoDungeon: Episode I here! It’s free!

protodungeon major update devlog devblog changelog zelda game boy pixel art GameMakerStudio2 gamemaker
Night and torches are now working properly! :DThis was quite a journey the past week or so. My original plan was to just have darkness, with torches and a lantern-like item to help you survive at both night and in the caves: As it turned out, this...

Night and torches are now working properly! :D

This was quite a journey the past week or so. My original plan was to just have darkness, with torches and a lantern-like item to help you survive at both night and in the caves:

image

As it turned out, this really wasn’t what I wanted. It was TOO MUCH darkness, especially when large portions of the game would be spent outside at night. I still wanted the idea of scary, dark caves, but it would be way too irritating for everything doing it this way.

And besides, this method was super slow.

First, I tried to simply fix the lights so that they looked better.

image

Oops.

After talking it over with a few people on the Discord server, and due to the upcoming item mechanic, I decided to split out the “lighting” into three states:

  • Day
  • Night
  • Dark

Dark would be for caves and unlit dungeons: black, unless you had your light, or if there was a light in the room. Meanwhile, you would be able to see at night with a light, and that’s what I started work on:

image

This was actually getting pretty close. It doesn’t adhere to the palette, which isn’t great, and a few people on the Discord server still felt it was too dark. After some conversation, I decided to try a different method, one I’d used a long time ago.

Pixelated Pope’s Retro Palette Swapper.

The reason for this was mainly because I didn’t want to create two sets of images for every single piece of artwork in the game. Inevitably, I would’ve missed some, or updated one sprite and forgotten to update another. It would’ve been a lot of work and code modification. So, a shader seemed in order. I started by doing some mockups of how night would look, using some existing images. I took this opportunity to consolidate my existing palette, remove unused colors, and add a few new ones to support the night palette:

image

Version 1 was a bit funky and bright. So I tried again:

image

This was…. much better.

After some more tweaks, I had a new palette ready to go. The night palette (the bottom row) only used colors from the day palette (the top row).

image

And so I began the process of working with the palette swap shader. It actually went pretty well, though for some reason it wasn’t hitting certain objects, like the player, or jars and other interactable items.

image

It took quite a bit of digging to figure out what was going on there. Initially I thought the palette swapper was ignoring certain layers (since I was applying the swapper shader to a specific set of layers), but that didn’t hold up. Torches and gates, for example, were also on those layers, and they were palette swapping.

After a lot more digging, it turns out that the shader was missing these objects because I was modifying their depth. In GameMaker, changing the depth means the object gets put in a temporary layer for drawing, and that temp layer is not accessible via code. In other words, the shader would never apply.

I spoke with Pixelated Pope, and there were two methods I could try: 1) apply the shader to a depth range, or 2) apply the shader to the full application surface.

I tried the depth first, and while it worked, it was amazingly, unusably slow. So it was time to try applying the shader to the app surface instead.

The palette swapper has scripts to apply the shader to sprites, layers, depth, and so on, but nothing as far as surfaces. I fumbled around for a bit threw some code together to apply the shader to the app surface, and voila.

image

Yeah, so it was pretty apparent I had no idea what I was doing.

After more consultation with Pixelated Pope, it turned out I hadn’t quite been calling the right functions in the right order. With everything moved to the Post Draw event, and automatic app surface drawing disabled, I had it:

image

But drawing the app surface manually does mean that I don’t get nice, automatic resizing for all monitor resolutions and aspect ratios. It worked fine on my 16:9, 1920x1080 laptop monitor, but in the past, 4:3 and 16:10 (and so on) have caused the game to stretch or squish badly.

This was the case when I changed my resolution to 1024x768, so I spent more time messing around with the app surface until it was drawing at the right scaled size (with 1:1 pixels to avoid distortion), and centering it. Unfortunately, the GUI layer, which is drawn after the app surface (and after the Post Draw event), did not want to behave.

image

It may not be totally noticeable here, but the GUI was stretching beyond the sides of the game, which not only looked weird, but caused some minor distortion to those sprites.

It took a long time to figure this one out, and it all boiled down to using display_set_gui_maximize(zoomLevel, zoomLevel, offsetX, offsetY) (using the same parameters as I did to fix the app surface drawing/scaling/centering), instead of display_set_gui_size.

Finally, I had to get lights working. Since I didn’t want to make the shader somehow exclude the lights from the palette swap (I would have no idea how), I followed another Pixelated Pope suggestion: the lights now draw an extremely faint, white circle at 0.08 alpha. It’s not noticeable to the human eye, but it IS noticeable to the shader. The shader doesn’t swap the palette of anything touched by that light.

image

And that’s all!

I hope you enjoyed reading this. Next up, I’m planning on working on true darkness for scary, unlit caves and dungeons. This should be easier, since I’ve already worked with the overlay method–I just need to change it to complete black and tweak it until it looks and plays nicely (famous last words?).

gamedev indiedev indiedevhour The Waking Cloak ProtoDungeon devlog devblog game design game development retro retrogaming pixel pixel art zelda games music video

Posted on April 05, 2019

ProtoDungeon: Episode I by Studio Spacefarer
Explore the first demo for The Waking Cloak in an all-new dungeon!
itch.io

The very first demo for The Waking Cloak, ProtoDungeon: Episode I, is live on Itch.io! And it’s free! Go!! Play! Enjoy! Tell your friends! Reblog and spread the news! 😄

gamedev the waking cloak indiedev pixel art game development zelda retrogaming pixel graphics gamemaker video games gameboy games indiegame link's awakening