Ludum Dare 53 took place the weekend before final exams. This is a great time for a professor to step away and do some creative exploration, but it's not a good time for my students. Truly, it's hard to find a good time for students to jam since it's not like the rest of their classes hold off for a bit so they can spend 48 hours making something, despite the fact that this might be the single best way to get better at making things.
The theme for Ludum Dare was "Delivery," and at first I was a little disappointed. It felt a little like people were voting on the worst part of RPG quest grinding. After some discussions, I realized there are a few different interpretations, and I look forward to exploring more of the games during the scoring period. For my own game, though, one of my first ideas is what really stuck: a delivery person who manhandles packages. The result is Mr. Delivery Man.
I read the theme Friday night but could not set to work until Saturday morning. It did not take me long to get a minimally playable proof-of-concept implemented: drop a package and kick it as far as you can. I sketched some character ideas on paper, and then I pulled out my Wacom Bamboo to draw them up in Gimp. I feel much more comfortable sketching in pencil than I do doodling with my digital tablet. Every time I do something like this for a jam, I feel like I should invest some more time in getting fluent with the tools. Then I think about how long that would take and deprioritize it. Still, I wish I had more confidence. I watch my art majors with their tablets, and they fluidly add layers, sketch ideas, and move on. All my ideation is on paper, which makes the digital production feel weighty, leading to a lot of reworking. It's not like you'd know it from the results, either. They are only good enough.
 |
| A digitally-enhanced photograph of a goofy pencil sketch of some character ideas |
I tinkered with trying to add a knee joint to get something with a QWOP feel, but I ended up preferring the straight-leg kick. I also spent a little time trying to animate the character as if he was holding the package before dropping it, but this proved tiresome and didn't significantly add to the gameplay. The result is that he's got a bit of Homestar Runner magic in how he holds that box in the air.
Recording the sound effects was some of the most fun I had on the project. I did a little quick research on how to Foley the sound of glass breaking. I took a break from that to make an afternoon coffee. Opening the cupboard, I was inspired to clink some mugs together. Perfect. I recorded myself clinking mugs together for the glass sound, and then I punched a spare board game box for the impact sounds. Conveniently, the box had some bits in it, which gave it a nice depth of sound. It's subtle, but it's quite nice. Whenever the box is struck, one of four random glass sounds and one of four random impact sounds are mixed together, so even though it's a small set of sounds, it still feels audibly satisfying.
The music also brought be great joy. Tritones play on tremolo strings before dropping the box, and this adds lovely tension to the very silly experience. There is a moment of silence as it falls. I experimented with playing audio through the fall and the kick, but this was much less fun than just bringing in the music after the box came to a rest. I think the polka is just right for a successful kick, and the sad trombones came out as I desired. I had to look into LMMS' controller tracks and pitch variation for the trombones. This feature didn't work quite like I wanted, since I wanted to mix square and interpolated forms; there may be a way to do this, but I couldn't find it. I was able to get a satisfactory sound by adding enough control points to a curved wave.
By the end of Saturday, I wanted to get a Web build up to make sure everything was working as intended. Here is where the headaches began. My usual continuous integration configuration makes use of the godot-ci action, but it does not currently support Godot 4.0. There is an open issue about this that actually had some discussion contemporaneously with Ludum Dare 53. The latest post points to an alternative approach. I looked into that, and after a lot of frustration and back-and-forth with GitHub Actions (push, wait, check, fix, repeat), I ran into a more troubling issue: Godot 4.0 Web build requires SharedArrayBuffers. I had just encountered SharedArrayBuffers on Friday when working with my game studio team: a subset of them were trying to fix an audio stuttering problem, and we had discovered that we could address it by enabling the "Threads" option on the HTML5 export. This worked fine on our test machine but then failed in integration. This is because SharedArrayBuffers require custom http headers, and GitHub Pages does not allow such a thing. All of this came after I had just added on-screen buttons for all the controls, assuming the Web build would work when deployed, but now I had to consider the real possibility that this would be strictly a native game. The biggest problem with this is that it's much harder to integrate with the Ludum Dare review community if you don't have a Web build. Indeed, one of the threads I just saw on the LD site was asking for a filtering feature since the author did not want to run any non-Web games.
Somewhere on my journey through many search results, I saw someone mention that itch.io had recently added custom header support. Whether this was specifically to support Godot 4.0 games or a beneficial coincidence, I do not know. A quick test showed that, indeed, this worked just fine. While I prefer just having all my jam projects in one place, and that place being GitHub, it was very easy to get the version on itch.io playable. I set up a Makefile to automate the generation of the Web build and its zipped contents, but I have not yet gone so far as to automate uploading to itch.io using butler. If I have to continue using itch.io as a platform for jam games or side projects, I will have to look into it.
It was midday on Sunday before I had the deployment issues sorted out, and I still had the energy to do a little bit more with the game. Something that had inspired me early on in the project is that just kicking the boxes around is a fun toy, and I figured I could use achievements to reward players for trying different things. Mr. Delivery Man then became my first game with achievements. I think that they serve the design purpose very well, and this sentiment is echoed by the early comments on the game during the Ludum Dare rating period. The software system behind the achievements it not terribly clever: each achievement is an object with a function that can tell whether the achievement has been met based on a game record, and after each play, the list is checked to see if there's any new ones met. I had hoped that after implementing my first achievement system, I would have a better idea about how I would want to do it next time. The truth is that it was just sort of pieced together, and I'm not sure I gained any great insight into implementation patterns.
That's the story of Mr. Delivery Man. He was almost named Delivery Dan in an homage to great characters in both Red Meat comics and Firesign Theatre, but leaving him anonymous ended up feeling right. Once again, here is the Ludum Dare page for the project; while you are there, consider checking out Delivery Destroyer and Messenger, which were created by two of my sons.
No comments:
Post a Comment