This is my third post celebrating National Game Design Month (NaGaDeMon). The first, brief post described a technical issue with Godot Engine, and the second, longer post described by that first post didn't really matter any more.
Earlier today, I pushed the button and published the itch.io page for my NaGaDeMon project, Blobbo Globbo. If you want the TL;DR, go to that page, download the Windows or Linux builds, plug in a game controller or two, and enjoy!
Blobbo Globbo is a one- or two-player arcade-style game. The core gameplay involves shooting slimes, which captures them temporary orbs. Before the orb dissipates, you can kick the enclosed slime across the screen, running over other slimes for combo points. It is highly inspired by classic games like Bubble Bobble, Snow Bros., and Tumblepop.
I have wanted to make a game in this genre for years, and in fact, I started one in May as a potential summer project. I spent about two weeks on it before my analysis was that I would not be able to see it through, in part because the art requirements far exceeded my capacity to draw. Getting better and more efficient with asset production is a perennial secondary goal of my projects, but given the complexity of the summer meant it wasn't the time to pursue it. This was, in part, because of an entirely unlikely and absolutely amazing summer vacation. Yes, for once, I chose relaxation over the joy of work! Also, I was pretty burned out from an academic year of pandemic management.
After my first project went sideways, I returned to the idea of making a game like Bubble Bobble. With only three weeks left in the month, I opted to prototype using Kenney's platformer pack, which I use extensively in my game programming class. I briefly considered trying to replace this art with my own, but I'm content having made a game whose play aesthetics match the visual aesthetics of the pack (if I may say so). I also pulled in a few other public domain visual assets, which are all listed in the project documentation on GitHub.
 |
| The start of a round |
The music is all original, composed in LMMS using exclusively the SID emulator. I wanted to capture a retro sound akin to what I enjoy hearing on Slay Radio. I was also inspired by a talk that my colleague Christoph Thompson gave at the Symposium on Games a few weeks ago, in which he described the history of game audio as being one of compromises. He talked about how the C64 overcame its significant memory limits by including an audio synthesizer, generating audio rather than playing back streams of data. I was able to take some simple themes from my imagination and arrange them in LMMS, but I have to admit that when it came to controlling the SID emulator, I was fairly well just playing around. I understand the four waveforms that are available and generally how different waveforms can combine to make different sounds, but I don't have a clear aesthetic or compositional sense of what makes a song like the theme from One Man and His Droid so amazing and iconic. (Of course, Rob Hubbard probably took more than an hour to compose it...)
I also created most of the sound effects, although a few were picked up from public domain sources. Mine were made using the sxfr plugin for LMMS, which I've used in the past for many jams and projects. Previously, I have created separate project files for each sound effect, which is kind of tedious. For this project, I realized that I could use the "export tracks" feature of LMMS, allowing me to maintain just one project file that contained all the sound effects. This made it easier to compare sounds and match levels, but creating sound effects in LMMS still has the negative side-effect that you cannot export fully-trimmed audio. The exported WAV files contain a lot of silence at the end, which I then have to clean up in Audacity. I looked briefly into SoX to automate this processing, but after some attempts, I realized it was taking more time to automate than to just do manually.
 |
| Player 1 has some points and Player 2 is losing a life |
About halfway through the project, once I had the fundamental gameplay working, I started scaffolding in some of the other conventional pieces such as the main menu. In my first pass, I found an appealing "splat" image, chose a typeface, pulled in some greens, blues, and pinks, and got the menu working. Playing through, the difference in visual tone was jarring: the ad hoc title screen was saturated and bright whereas the levels—using Kenney's platformer assets—were muted and soft. This emphasized to me the importance of having a palette. Before working on any other gameplay, I picked out the key colors from the asset pack. I put these into the palette in Godot Engine, which I had never used before but seen used in some video tutorials. What a great feature! Now, with a single click, I could easily get my menus, HUD, and effects to draw from the same colors.
My game design courses focus on system design, and my game programming courses focus on technical implementation issues. This means that there's a vast area in between that I don't often get to explore, and that's one of the reasons I stay active in game jams and events like National Game Design Month. Particle effects and shaders are good examples from this project. I show students some basics of particle effects within engines like Unreal or Godot, but we don't spend a lot of time looking deeply into them. For Blobbo Globbo, I am happy with the particle effects used to "warp" between levels. They are not going to win any awards, but they are much more interesting than the usual one-day example I give about making simple explosions. Shaders are an area of game development where I understand some theory but have very little practical knowledge. For Blobbo Globbo, I slightly modified a found fisheye effect that is used subtly when a slime is captured. The teleportation animation includes a simple vertical wipe that I was able to get working myself. There are horizontal and a circular screen wipes used in the early scene transitions. I had to find some tips on how to approach the circular one, and I modified both to use smooth stepping for a softer visual effect. That in particular is a tool I'd like to keep on my toolbelt for future shader work.
Speaking of my game programming course, if you're a long-time reader then you'll know that they have a sort of menu of options they can choose from to earn A-level grades. One of the options it to implement a pause menu. Although I've graded many student projects' pause menus, I've never actually made one myself, so that was one technical feature I decided to include in Blobbo Globbo. It was fun. Not much else to say about it, really.
 |
| Finally, a real pause menu |
The gameplay underwent a few significant changes over the last three weeks. Originally, if a projectile hit an already-captured slime, it would be ignored. However, this led to a gameplay problem where one could just spam the shoot button with impunity. There is, after all, no limit on the speed of shooting, in an attempt to capture the arcade cabinet feeling of button-mashing. Instead, I made it so that a captured but non-kicked orb, when hit with another projectile, would pop. Since points were only earned by the kick, this meant that a player who overzealously shoots would eliminate their own opportunity for points. It wasn't until playtesting it with my kids that I realized that this was far too subtle: there was no way for the player to see that they were missing the opportunity for points. Instead, it seemed a conservative and reasonable thing to do to just sit in one space and shoot as many projectiles as possible. This cleared the board, which is the implicit goal of the design, but without earning any points, which of course should encourage a particular kind of play. After this test, I redesigned the shooting and capturing system so that shooting a captured, non-kicked orb would pop the orb and release the slime. This makes it more clear that care should be taken with shooting, and that points are earned by well-timed kicks.
There are always opportunities to introduce new enemies and new levels in a game like this, but if I were to put more time into the gameplay, I would start by exploring some other directions. Right now, if you complete all six levels, the game loops but increases the difficulty of the enemies (the speed of all the slimes and the fire rate of the pink ones). I think it would be interesting that if a captured slime is released, either because of the orb timing out or being popped before being kicked, it either increased the difficulty rating of that particular slime or changed it to a harder type. Another improvement that is common within this genre is adding pickups that spawn across the board, either by themselves or as a result of interaction with enemies. These give a reason to traverse the board rather than sit in tactically advantageous places.
One of the design challenges I faced was how to express to the player how to play. It's a simple enough game that one can stumble across the handful of inputs: move, jump, shoot. It's less obvious that one ought to run up to captured slimes to kick them until you've seen it done. I make my game programming students include some kind of instructions in their games so that I can figure out how to play them. Most students meet this requirement by dumping instructions onto the main menu screen in some kind of fanciful font, which has the awkward result of being less learnable than if they didn't include instructions at all. One of my design goals, then, was to do better. My solution was to put in a static tutorial screen, which disappears after seven seconds but can be clicked through, that shows the core loop. The original design used Kenney's Input Prompts pack, but these were designed for pixel art, and my kids pointed out how out-of-place they looked during testing. I found Xelu's free prompts pack and was able to pull in some higher-resolution images that fill the bill. It didn't have exactly what I wanted, which was a controller-neutral depiction of which buttons to press, but I was able to piece together something approximating that by composing blank buttons with labeled ones.
 |
| Tutorial screen |
The name of the game came from a dinner conversation with my family. I asked what I should name it, and all manner of silliness ensued. When I described it as having slimes or blobs, somehow "Blobbo Globbo" came up, because you sort of glob the blobs. That got enough laughter that I decided to keep it. Conveniently, a poet might also use it as a partial rhyme for "Bubble Bobble," especially of you go full Cockney. Please include your thematic poems in the comment section.
It enjoyed spending time in November creating this game. As usual, one of the greatest delights comes from watching my kids play the game. I hope you will enjoy it as well. Keep in mind that, like most of my games, it is free software licensed under the GPL, so you are welcome to download the code from GitHub and tinker with it yourself.
No comments:
Post a Comment