A Slightly Stale Postmortem

So, I started planning out this postmortem pretty much immediately after I published the game. And I guess I should probably actually write it out now. Welp, time to stop the fluff and start the postmorteming. (And hey, last postmortem, I tasked myself to 'plan out my next postmortem a bit more before writing it', so I guess I can mark that as 'done'). Unfortunately I only got around to publishing this postmortem well over a month after I started it. But here goes anyway.

Why did I make this game?

Well, unlike all my other games, which were either made for assignments (Untitled Voltorb Flip Clone, Inconvenient Space Rocks) or for game jams (pretty much every other one), this game was made so I could unwind a bit. I'm going into my 3rd year of University at the start of October, and this year involves a capstone project. And, during the Summer, we're all expected to do a decent amount background reading/preparation work for this project (well, we were told that we'd be told what we're expected to do in regards to background reading/prep work via webinar at the end of July, and then, after that webinar, we should get on with it). So, I kinda spent all of August working on that (yes, the Twine port of Epic Gamer Moment: The Game came about via the background research, and yes, I'm still working on the background work), but, towards the end of August, I managed to make a working prototype for my product. Anywho, on the last weekend of August, my family had kinda booked a short break, so I was able to take a few days off. And, at this point, I figured that it might be worth trying to take a bit of time off the capstone project, seeing as I was starting to get into a bit of a rut with it. And what better use of some time off is there than creating a game? (Actually, now that I think about it, there probably are better uses of time, but those uses of time wouldn't have resulted in this videogame existing.)

So yeah, I made this so I'd have something else to think about besides my capstone project.

And I can already say, with 100% certainty, that it did give me a break from my capstone project.

Designing the game

So, the core gameplay loop/mechanics of the game (having an unlimited supply of ammo, ammo takes some time to recharge, you need to use ammo to defend yourself from attackers, allowing an attacker to get to you = game over, you only score points from discarding ammo) actually came about from a discord conversation I had with a friend on the 20th of August. Long story short, they mentioned they were participating in a game jam with a few of their friends, and they were in a bit of a rut in regards to designing the core gameplay, so I made a few suggestions, in case that would help. In the end, they worked something out amongst themselves (the end result of their work was this: https://gman8r.itch.io/lampyridae-matsuri) and, in all honesty, the idea they went with was better than most of those suggestions I made.

Now, you're probably asking 'okay that's a cool story why is that relevant?'. Well, one of the unused suggestions I suggested involved an unlimited supply of ammo, which takes some time to recharge, you only score points from discarding it, but you need to defend yourself etc... Sure, the proposal had some dressing that only worked in context of the game jam they were participating in. But, underneath that proposed dressing, there was potential for a somewhat decent game, that didn't exactly need that dressing in order to work (and I guess the originally-proposed dressing was a bit on the 'unjustifiable' side). So, when I found myself thinking 'hmm, perhaps I should try to think about something that isn't my capstone project for a bit', I already had a relatively simple, yet decent game concept on the back burner (and was also complex enough for me to meet that task I set myself in 2's postmortem to 'Make something a bit more complex'). So, it made sense to make that game.

When it came to re-dressing the game, I remembered that in my last postmortem, I had tasked myself to 'use more sprites instead of relying almost entirely on primitive shapes'. So, I knew I'd have to come up with some sort of dressing that wasn't over-abstracted to hell and back. So, I asked myself 'hmm, what thing could someone have a potentially infinite supply of, that they can both use to protect themselves, yet also have a reason to discard?'. At that point, I remembered a particular skit from asdfmovie5, involving an individual who works at a muffin factory.  An individual who is throwing muffins at someone, and has an unlimited supply of muffins, because he works at a muffin factory. And, if he wanted to, he could eat those muffins instead, and they would probably taste nice (even if he couldn't then throw the muffins after eating them). So, I figured that it would make sense for muffins to be the ammunition of choice featured in my game.

Once I had established that muffins would be the ammunition of choice, I started to design the rest of the game, under the working title 'Muffin Factory'. I figured that it would make sense for the muffins to be produced by some sort of muffin machine (allowing them to passively regenerate, without any input from the player, and that the attackers would have something to attack), and then having the entire game within the muffin factory, (as the player defends the muffin machine from a threat which had already surrounded them) Then, there was the question of 'who would attack a muffin machine?'. Well, why would someone target a muffin machine in particular, unless they were trying to wipe out the competition in the 'baked snack' industry? And, what other baked snack is most likely to be the mortal enemy of muffins? Cupcakes, of course! Initially, I had the idea that the 'Cupcake Mafia' were sending their CupcakeBots to destroy the muffin machine. Eventually, on Wednesday, I realized that 'Cupcake Cult' sounded much catchier (and helps explain why they're so determined to eradicate the muffin machine: zealots be zealoting. And also why you're having to use scorched-earth tactics with your muffins (because they've effectively made muffins extinct, and this your last chance to have muffins)). Anywho, once that was done, I realized that 'Muffin Mania' sounded like a much more catchy name for the game, and then I started the process of making the game.

Making the Game

Friday the 28th of August to midday on the 31st of August: working out the game logic

So, I mentioned earlier on that I was away from home on this weekend, the last weekend of August. So, on the way there and on the way back, I started planning out the classes  and such I'd need to implement.

Most of the game was built on the same base as The Button Factory, so I only really needed to worry about the GameObjects, the game logic, and stuff like that.

So, I wanted to make things relatively efficient in regards to collision handling, so, for the game itself, each of the four 'lanes' has its own ArrayList of CupcakeBot objects and Muffin objects. And, for the update/collision handling loops for each lane, I'd  started by updating the the cupcakes and the muffins as usual. Immediately after the update, I'd then check collisions, by comparing the distance that the nth Muffin in the lane had left to travel with the distance that the nth CupcakeBot had travelled; If the muffin had less distance left than the Muffin had travelled already, that meant that the Muffin was behind the CupcakeBot: meaning that they had collided (and that both of them should be considered 'dead'). And, as, if the current pair hadn't collided, it would be impossible for later pairs to collide (seeing as they had both been around for less time than the first pair), I'd cease the collision handling as soon as it reached a pair that didn't collide. ofc, if there were no pairs of cupcakes/muffins to collide (or left uncollided), the collision handling would be skipped/stopped. Finally, it checks to see if any had reached the end of the 'lane' they were on ('killing' the muffin if it had reached the end, and ending the game if a cupcake had reached the end), and, for all the things that were not 'dead', they'd be put on the 'alive' lists for that lane (and the 'dead' objects would be put back on the stacks that they reside in when inactive). I implemented the CupcakeBots and the Muffins as subclasses of a 'LaneTravellerObject', which gave them the functionality for recording how far they still needed to travel along a 'lane' to reach their destination, as well as allowing them to have a value to indicate what 'lane' they were on (for purposes of working out how to render their sprites), without needing 4 seperate subclasses for each lane's Muffins and CupcakeBots.

The player character was relatively simple to plan out. Arrow keys move you, spacebar uses the muffin. If you're standing in the middle, you eat the muffin, and if you're standing in the middle, you eat the muffin. At first, I was considering that 'hmm, perhaps you stand on the lane with arrow keys and press arrow keys again to throw a muffin, and space at any time to eat it'. But then I realized that was a stupid idea, as the arrow keys are nowhere near as mashable as the spacebar (and 'spacebar = muffin action' just feels much more intuitive). And, just like the muffins/cupcakes, the state (where you're standing) would be represented as an integer (with the additional 'middle' state, for when you're in the middle).

This player state is also used in the game update loop when responding to a muffin action. If you're at a lane, and you performed a muffin action, a muffin would be revived from the inactive stack and put into the alive muffin list for the lane you're standing next to. However, if you're in the middle, and you perform a muffin action, your score would be incremented. All the code for working out if you can perform a muffin action, as well as the cooldown for muffin actions (along with the indicators of muffin counts/the muffin cooldown) is handled entirely within the player object.

The cooldowns (both for the muffins respawning and for the cupcakebots spawning in) were initially planned to be a lot shorter, but ultimately those timers were extended, because they made the game too fast for comfort.

I also specified the dimensions of the game (of being 784x784) as an integral part of the game. The player is in the middle, and they have 5 states (middle, and one for each lane). I figured that the player should be a 64*64 sprites, and the 5 potential positions should effectively be in a plus shape, so it's easy to tell what state you are currently in. This amounted to a 192*192 square in the middle. Then, in each of the 4 cardinal directions from the middle, there should be a 256px long 'lane' for cupcakes to come down/muffins to be thrown up, ending at the outer edge of the player's square. Finally, the far end of the 'lanes' should be covered by a centered 80px by 80px sprite. So, when the cupcakes spawn in, they look like they're coming out of those things, and, when the cupcakes despawn, they simply disappear inside there. The cupcakes and muffins are also 64px*64px, but the extra 8px on either side of these covers allows for some illusion of depth. But basically, the dimensions of all the objects comes to a total of 784*784px . So I just stuck with that window size for the game, and specified the co-ordinates of where things would go using that as a basis.

Anywho, on Monday afternoon, I finally got home, and could finally start producing things.

The afternoon of the 31st of August: object time

So, once I finally got home, I could properly start working on the game. This is the boring part of the postmortem, as this info is kinda boring. I wrote the code for the game objects, and created the art for the player character/muffins/cupcakes/spawners. I didn't get around to the muffin machine on Monday, but it was in the works. I designed the CupcakeBots based on the cupcake from FNAF (pink icing, some sort of candle, eyes, beige-y lower half), mainly because that's the first thing my mind jumps to when I think of cupcakes. And I figured that, by referencing that somewhat decently-known cupcake, it would be obvious that they are supposed to be cupcakes. The robotic legs are my own idea, because I wanted to make it pretty obvious that they are robots, and I figured that spider-like legs jutting out of the cupcakes would be appropriately unsettling for an enemy design. You certainly wouldn't want to eat those cupcakes! Anywho, I also attempted to draw the muffin, player character, and CupcakeBot sprites freehand, instead of my usual geometric pixel art. I was already planning on making the surrounding area 'geometric pixel art', and I wanted to make the sprites 'pop' more. That, and I couldn't be arsed to work out my usual overly-precise pixel art for the player/muffin/cupcake sprites. I guess the somewhat sloppy sprites do have a particular charm, though. But the spawner art was, as per usual, overly precise pixel art (as that was a rather simple thing to produce)

Anywho, Monday ended with most of the busywork of actually coding the game objects done, but with plenty of work left to get the game playable.

Tuesday, September 1st: Actually making the game playable

On tuesday, I finally made the game playable. In the morning, I started off making some improvements to some of the unfinished game objects (such as indicating the count of the player's remaining muffins, how long it would take for a muffin to respawn (via an arc object in the Player object), fixing some of the co-ordinate stuff for the classes), and starting work on the game update loop. There weren't many deviations from the initial design worth talking about during the morning, so I'll just skip to the afternoon.

So, during the afternoon, I decided to create a 'BackgroundMuffinObject', to go in the background of the title screen, so it would look less bland. It basically does roughly the same thing as the IncomingRon objects from 'Upron Simulator 2012', however, these are muffins, merely decorative, and they despawn after going off-screen (after they've been on-screen ofc, otherwise they'd instantly despawn and that would be stupid). I also decided to recycle some of the cutscene handling stuff from The Button Factory into the game, so, at the start of the game, the player will be given a tutorial, in the form of some totally-in-character monologuing from the player character. And then, after that monologue is done, the game actually starts.

Eventually, I managed to get the game to actually, y'know, work. At first, the game was stupidly fast (the same proportions between timers as in the final product applied to this earlier version of it, but just faster), not too fast to be completely unfair, but fast enough so that it was honestly impossible for any player to keep up with it. So I had to slow it down a bit, but, after that, it worked. I had a working game. All that was left was the extra bit of cool stuff on top of this game so it would be presentable to the world.

Wednesday, September 2nd: Polishing it off, and releasing it.

Wednesday was the obligatory 'welp, time to make this look presentable' day.

I only got to this part of the postmortem some time after the rest of it, so I'll just go over the stuff I remember from when I was making it. For the audio, as well as the usual kazoo noises/improvised sound effects, I decided to experiment with some of the 'chirp' and 'DTMF tone' generation stuff in Audacity, mostly so certain noises (such as the cupcake bot noises) would sound distinct from everything else going on. At first, all the potential cupcakebot spawn events (when they spawn in each of the lanes) made the same sound effect. However, I realized that I could do something even better. So, with the way DMTF tones work in audacity, you can basically enter a sequence of characters, and a time length for the total tone thing, and then Audacity renders a sequence of tones from those characters, which, start to finish, lasts for the entire specified length. If you have a single character input, it's just one tone for the duration, and if there's a lot of characters in there, it does all of the relevant beeps for each of those characters really quickly. So, for each of the directions, I made a sequence of beeps with varying input lengths (meaning varying quantities of beeps of varying lengths within the same length), so, if a player is paying attention, they can associate a sequence of beeps with a certain cupcake spawn direction, and react accordingly, not needing to see the screen. I supplemented this with the muffin recharge noise (a chirp that varies in amplitude as it goes on), allowing a player to work out when the muffins recharge by hearing it (and I also added the gradient effect to the recharge circle thing). This recharge noise is played at the start of the muffin recharge process (and is 1 second long; as long as a muffin takes to recharge), so I didn't need to faff around with looping it and stopping looping it and such. The explosion noise (played when the game ends) is of particular note. It's basically just an odd mouth noise that bears a passing resemblence to an explosion, supplemented with some white noise, reverb and distortion effects, and plenty of amplification.

I also changed the name of the antagonists of the game from the 'Cupcake Mafia' to the 'Cupcake Cult' on Wednesday as well. Why? Well, the story I made for the game established that they had a lot of influence over baked goods, a fanatical devotion to cupcakes, and a zealous hatred of non-cupcake things. Any sort of self-respecting family business might not be able to have that much influence, and probably wouldn't be overly zealous about baked goods. However, a cult, on the other hand, probably could be all that. And came with some free alliteration!

After some testing of the game, and a few other minor tweaks, I eventually found myself satisfied with the quality of it, and I was finally ready to release it. So, I put it into a .jar file, wrapped the .jar into an .exe (using Launch4j), and even worked out how to give a custom icon to the .exe. Then it was just the matter of getting some cool images for the itch.io page and a nice thumbnail, and then I finally published it.

And then I started work on this postmortem before forgetting about this postmortem for some time and only finished work on the postmortem towards the end of October.

Assessing my performance

Reflecting on the goals I set in the postmortem for my previous project

• Use less gratituous sound
  • I didn't go too overboard on the sounds this time.
• Make something a bit more complex
  • Yes, as this game definitely has a lot more complexity than '2' had.
• Use more sprites instead of relying almost entirely on primitive shapes
  • Yes, as (besides the many .drawString calls), there is only one primitive shape used in this entire game (the muffin recharge indicator)
• Try to make another game with a point behind it
  • No, as this game was more of a recreational 'haha funny sprite go whee' sort of game.
    • Although I guss that some people could see the 'you score points by discarding your attacks' mechanic to be somewhat intriguing
• Put a bit more thought into my titles
  • Somewhat achieved
• Plan out my next postmortem a bit more before writing it
  • This postmortem was planned out in advance before I properly wrote it, which helped a lot with finishing it off well over a month after I started writing it

Goals for next time

• Try to make a game which involves viewport scrolling
  • So far, all of my games have a fixed camera, with 0 viewport scrolling being used. This does limit the playing field for my games, however, so I should aim to create a game that's somewhat bigger in scope, not limited to just a single fixed viewport.
• Actually finish and publish the postmortem in a reasonable amount of time
  • I should finish my postmortems in a reasonable amount of time, instead of procrastinating on them and then only finishing them off well over a month later, as I've almost definitely forgot something important I originally was going  to discuss about wednesday.
• Make a game that isn't an endless high score chase
  • All of my games are basically endless high score chases, with no real development of any sort as the game goes on, besides a potential difficulty curve (although the only game which has a real difficulty curve is Inconvenient Space Rocks, as everything else kinda stays at the same difficulty throughout). This also limits the amount of new things I can introduce during the game. However, if I make a game which isn't mindless endless high score chase, I might be able to properly add new things to spice up the experience as a player does well.
• Make a game that has some sort of point behind it
  • I guess that I didn't manage to fulfil this goal from last time this time, so I probably should try next time to make a game that actually has some point behind it or something like that.