Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Cake Kills Candy [procedural level platform shooter]

A topic by sitebender created Apr 10, 2017 Views: 567 Replies: 10
Viewing posts 1 to 11
(3 edits)

Cake Kills Candy is a procedural level platform shooter that was made for a 1 week game jam where the theme was cake. We were lucky enough to find a second concurrent one week game jam where the theme was candy and we just so happened to have a candy world with candy enemies. After that we decided to enter into two more game jams that we complied with the rules. The titan boss jam where you had to make a big boss and a controller jam where you had to have controller compatibility.




We are two developers, one of us makes the fantastic art and I make the game. Its been a while since we had made a game together as work and travel get in the way, but we all struggle with that. So we wanted to keep it small and do a game jam again. This is perhaps our fourth or fifth platform shooter game so what used to take two weeks can now be assembled in hours. A lot of the code is just copied and paste from previous games.

As a warning, I make a lot of development videos, but never any developer blogs, so this is more of a going back in time sort of thing. The project still has 2 more bosses to go that were made for the boss jam, but that first boss took way too long to make.


We started by quickly making a platformer engine. The assets in this video / gif show off assets that had been made previous to the jam, but would be removed for the jam. What you see here is indeed a procedural level, but its generated as the game starts with no way to generate new levels on the fly. The artist had come up with a cheese cake character to be the hero. The song is from a previous jam and made by


The artist came up with a great, universal tileset while I kept plugging away on level generation. As you will see in the video level generation was imperfect. The major issue with this version is some levels were non tranversable. I made our menu which is now standardized at this point. In this video you will see each level is generated with a brief pause due to no loading screen. There are inside and outside levels. Inside levels will generate a ceiling with more of a background. The inside background is inaccurate and would remain inaccurate for weeks as the background is only supposed to be 2 blocks wide at a time.


At this point it was time to add more bits of level generation. This time rather than larger, normal sized chunks, it was small chunks between the large ones. You can still recognize the larger patterns, but the smaller ones make the levels feel more unique. There are still no enemies and no exit. You will notice the random color. This was a simple way to make each video look different.


In addition to normal chunks and small chunks, extra large chunks were added. Ladders were also added even if ladders ended up being removed from the final game jam and have yet to be added back in. Its probably tough to animate a ladder animation for a cake. You will also see a charge shot used. Watching this video now its tough to spot the large chunks used since its a mixed bag. Moving platforms were also added.


At this point, enemies were added along with some effects for damage and death. If the game had a NES feel, it went out the window with these particle effects. Enemies are both stompable and shootable.


Larger gumball enemies were added which was easy enough since we had the basis for enemies with the jellybean enemies. The challenge for this video was removing the HUD. I had gone with more of a NES HUD where the game screen was a grid of 25 x 13. Well we needed it taller because the inside levels were turning into an issue. Plus the HUD in general was stock art that was made back in November as a place holder for any HUD.


We experimented with a one room of game and we had made a similar game in the past for a different game jam. Get the key, reach the door while enemies spawn in via portal and leave the same way. The door effect of pulling in enemies was added as a wow factor. Although it made me feel like the enemies would come with us to the next level. The portals were modified to turn red when they were about to spawn an enemy as a warning. The big complaint with the previous game was they dumped enemies out and straight onto the player. While this was true, the portals did turn color when they could dump out enemies. You will also notice a new load screen that was pretty ugly and broken.


The game started to come together as an actual candy cane background was added and the tileset was modified. The composer also offered up a fresh song that would become the theme and only song in the game. The cheesecake player was also modified as well. This is also the point where the game had some game breaking issues and would continue to have these problems for the next few days where the game would freeze when generating new levels.


This update brought outlines around the solids to make them stand out more. The small candy canes were removed from the background. The doors and keys were both changed.


The first game jam is ending, so it was crunch time. You will notice a HUD along with a ghetto ammunition and health bar. The player is granted random weapons as having a variety of weapons made the player seem overpowered. The original idea was to give the player 6 weapons and then no ammunition refills. Another issue with a previous game jam was that the player was just dumped into the game with spawning enemies which gave the player no chance to react. To solve this, we added a timer. There is no use for the timer on horizontal levels as enemies never spawn on the start screen, however the timer is kept for consistency.

Weapon sprites were also added and basically stapled to the player models. You will also notice that the cake characters are now different. In a perfect world we would have had more time to make the characters different and even offer a character select, but I'm slow with making user interfaces. Its so much easier to just make the game. That's probably why the menus are always so simple.

To make this feel more like a game and less of a pointless adventure, arcade points and scoring was added. Bonuses for health, level and without shooting. A platform shooter that rewards you for keeping your finger off the trigger!

There was another big modification that would never go noticed unless I mention it. The enemy, weapon and player sprites were pulled in via sprite sheet to save some time having to cut out sprites and add them. This also is the setup to some lazy mods as the game can also pull in external .png files to replace enemies, weapons and players.

There was another update after this one, but the only details to that were tweaking weapons so they fired from the barrel rather than from wherever.


The obvious question is after just dumping 10 updates here is why come back? The game jam is over. What more could you do if a game is complete? That covers the first week. There are still two more weeks to go! You can only go onward and upward from here in a literal sense. I will come back with more updates.

Thanks for making in this far and letting me elaborate on all these production videos!

I am back again to murder your 56 Kbps modems!


The week long game jam was over, the game had a bit of bugs that would get fixed over the next few days. To make the game look and feel different for the trailer, a bunch of new tilesets were made. From there it was time to look up at the Titan Boss Jam.


Like the horizontal levels, the vertical ones were made from chunks which is always a bad idea when it comes to being traversal. The first level generation resulted in some difficult to navigate areas. We wanted the boss to be huge or at least tall for the Titan Boss jam. A look up and down function was added even if it felt unnecessary due to the player being centered on a screen without a HUD. Speaking of HUDs, the ammunition and health gauge were both enhanced.


Three bosses were made for the game, but cake boss took the entirety of the two weeks to program into the game. The first delay was because the boss's face would be covered with blocks due to the procedural level design. With the boss's face covered it had to break through the blocks. This functionality took 3 days to implement as the level is a single giant solid object. Breaking through a block requires the game remaking the entire solid object. That solid object has no texture, so the tiles need to be peeled off as well.

We went the extra mile to make the tiles break into four pieces. To get that effect, the way the tiles propagate the game had to change as well. That was another interesting process, but because of the image slicer / lazy mod support it was easy enough to copy and paste over.

Breaking through the blocks is still a cool effect when you could see it happen, but the effect was unreliable at first in an imprecise way. The video below will demonstrate the fact you can also kick rubble.


There were a lot of major issues throughout the entire Cake Baws process. It would spawn too high, the levels were tough to traverse, the boss failing to break through the blocks it should. These three issues were fixed over a day or two, but there were three major game breaking issues that I will mention later. The level generation was enhanced to make it easier to get to the top of the boss without any crazy jumps. Its difficult to visualize bug fixes in a 10 second clip.


With the glaring issues fixed, the boss arms were added. These arms were designed to crash through the sides of the walls based on trigger points. The arms are always there even if off screen. They scan for the player in a specific hit box, but when the player triggers them they appear. The arms only crash through a vertical line of two blocks otherwise with the size of the arms, they'd obliterate the entire level. As you will see the arms do no damage at this point. Its just easier to test them.


At that point the arms could damage the player and shooting the arms would make them withdraw. The player can run out of ammunition and if that's possible, then how do you shoot a boss to death? You think up a different way to take down the giant. So it was time to make the boss punch itself in the face. Because the boss crashing through blocks was a three or more day process, it had to be used more, so with each punch in the face, the boss lowers itself and obliterates more solid platforms.


Well that week seemed to have half as many updates. There is still another week to tune in for as next week will be enhancing the feels and polishing every game breaking bug that came with the boss fight.


The previous week was challenging having to break apart objects and remove tiles, but it resulted in a cool effect that can be used later. The boss is constructed, but there are still three major, game breaking bugs.


It may have taken more than a week of production, but the boss can finally be defeated! The challenge here was the fact when the boss goes low enough it destroys the entire floor. With that in mind, the player still needs to lure the boss into punching itself. After that a platform, key and door spawn.


New art was made. The three game breakers were a long process to fix, which is why they were neglected. The first game breaker was if the player fell off screen, there was no solid surface for the player to spawn on, so the player was thrown out. If the player died, it was the same issue, no solid surface, so the player lost a life and again was thrown out of the pit. As for the third game breaker, now that its 5 weeks in, I can't even remember what it was. Here you see the debugger displaying the triggers.


Its lackluster having a boss seep into an abyss... it needs to explode or do something flashy! When it exploded into a bright flash of light, the level still looked pristine and unharmed... so it had to be lit on fire with a little bit of rumble and screen shake.


With new art, frosting was added, faces were added, different size heads were added. As you can see the face has and impact on the left and right. Then it begins to get angry. Damage smoke puffs were added, even if that still might change.


The arms had been added in a previous update, but now they function. Candles are on fire, hands slap down and fists... just punch you! Because I never specified it before, arms only hurt the player when moving into the structure. When they leave, they do no damage. This was a fair compromise considering arms retract when you shoot them.


The old rubble system would break the tiles into 4 equal sections. The new system cuts out random sizes and makes it stack at the cost of processing power. For those paying close attention, you'll notice the rubble is darker and now behind the player. Its just a little detail to enhance the experience.

To save on updates, the rubble system was optimized because wow did stacking use a lot processing power. It was only noticeable when the boss broke through a large amount of blocks. After this video the rubble was limited.


After dealing with the boss for more than a week, we just about forgot there was an entire game connected to it. With the new rubble system it was time to enhance the blood system... or in this case jam system. Gumball giblets were also recreated so their axis was centered. The chirizo launcher was also enhanced to cause bloodshed every frame an enemy is caught in an explosion.


With two days before the jam ended, there was some sort of corruption that resulted in the level generation script somehow getting erased when the save failed. That has happened in the past which is why there are always 10 backups. I recommend everyone make automated backups. The catch here is that the automated backup failed before the save failed. Somehow, the backups were from 21 days earlier.

We were lucky that it was only one file that failed to save and its an obvious file. It took a while to upgrade the three week old file to something more current. You will notice below the same level is loading because it fails to generate the level so it loads the last level which is saved to the PC. What is never saved is the file with all the room sizes which is why the screen appears below where it should.


With the boss done, the game felt good, and the final touch was to reinstate the game into the boss. The boss appears every 10 levels starting with level 11. There is a cheat code to jump to the boss for the sake of testing the jam. In addition to that, three new tilesets were created as an easy way to make the game feel fresh. A trailer was hastily thrown together from 10 minutes of gameplay.


Well its probably more than 3 weeks, but here we are, Cake Baws is done, in game and the game is better for it. We kept production going on Cake Kills Candy. As always, thanks so much for making it this far whether you read everything or just took a look at the Internet slowing gifs.


Cake Baws is over, the fourth and final jam is done. We can sit on our laurels and consider the game done. Its playable and it has a boss. Its arcade, its fun and you can play by shooting or get rewarded for not shooting.


Game jams are a good way to learn and we learned Windows 8 struggles with the game. Perhaps its because the level generates a .png of levels and then reads it when it should probably create a grid and then read it. Jams are learning experiences and this will help the engine in the long run to offer Windows 8 compatibility.

With the jam over, production halted for a bit. There were other projects to get back to and other games to get updated (outside of

Traffic for Cake Kills Candy died almost after three days even with exposure of four jams. As time went on, I noticed people seem to like and retweet Cake Kills Candy far more than my other project which is nearly done. While I am a fan of finishing long term projects before moving on, I hear you should always attack with your best weapons, so after a week of a break... production continued.


A good way to get back into the groove is to fluff what you already have. We spent a bit of time making a controller screen. While it seems like an unsubstantial update, there are five production videos for just this simple task and the hilarious failures of programming.


There has been a question that has been in a few forums for a few games, "if your game emulates the NES, why does it need a load screen?" Cake Kills Candy has a loading screen because it generates, then assembles levels. The burden that consumes time is assembling the level. The early levels have a mere blink of a loading screen, but the later levels say level 8 and up have 4 - 5 second loading screens.

Two days were spent making different methods to load and assemble the level without a loading screen. The best method seemed to be a combination of assembling what's on the player screen and a wave that loads the level from left to right. This was the most effective method because if the wave surpassed the player's screen, it no longer needed to check the player's screen and when it was fully loaded it was done.

The burden of processing power was smoothed out to unnoticeable with even the largest rooms. The game will only generate horizontal rooms ten or more screen lengths so to test it, the system generated twenty or more to overburden the system. Then forty screen lengths. At that point the burden became noticeable, but that was four times the largest room in the game.


There were always two enemies, jellybeans and gumballs. Gumdrops were added. They have random faces, which creeps me out. They are juicy and explode into the same color juice as their body.


The game has always been single screen rooms, horizontal rooms that grew with the level you were on and a vertical level to fight Cake Baws. While it is designed to be an arcade game where the objective is get the key and make it to the door... its just a start.

With this update, the game generates larger levels that go right, left, up and down. The only problem is that it burdens the "no load technology." We have the luxury of having a countdown 3, 2, 1, GO so the game would slow during that process as the level loads without a loading screen.

Each level is still generated.


There were several issues with the previous update. The rooms lead to maps becoming untraversable. The longer load times would cripple frame rates for the first 4 - 5 seconds. To cure everything it required polish. Finding the rough edges when the game generated levels and modifying certain sections.

With the "no load technology" getting in the way, a new load screen was added. Better to have a load time than grind to a halt in the first 4 seconds of playing the game. There are methods to lessen the processor burden of assembling a level, but its better to pre load. As we move away from the arcade feel of the game,the 3, 2, 1 countdown was removed.

After a day or two of polish, we continued to squeeze the load time sponge. The levels are 20 - 30 screens long and these are 16:9 wide screens rather than 4:3. It is a considerable burden because everything is generated, the backgrounds, the solids, the tiles over the backgrounds. The level assembler became more specific and less generalized. Even with larger rooms, the average load time was 3.5 seconds. Sometimes it was 2 seconds or lower, other times it was 5 seconds.

As the pre loader became more specific, the backgrounds became generalized. Rather than assembling background tiles, pre built background tiles were added. The 3.5 second load time turned into an average of 1 second with the most being 2 seconds for an entirely interior level which requires the most processing power.

It was a great trade off, levels up to three times larger than the largest it had previously been for half the waiting time.


These updates have now caught up to exactly where we are as of two days ago. Sorry its a bunch of technical things. The art has progressed, its just not in the game yet.

This blog is slowing my PC! I should use less .gifs.


The game has been pushed further to be closer to where it was. To make the larger, multiple room levels, enemies were pulled along with the keys and doors. Now that the new level system works better, enemies have returned to the game. We intend for each level to be capped off with a boss, but in the meantime, doors and keys both spawn in the last room of each level. A variety of larger room chunks returned after being removed.

As Cake Kills Candy transitions from arcade to something else, the details have been changed to make it feel traditional. Gun kickback was removed due to how annoying it is in a game with vertical rooms, the banana blaster is the default weapon and never consumes ammunition. Enemies can no longer be stomped, because the game was far too easy with it. The game is still too easy when you consider the player has a gun and the enemies only pace. The weapons menu has been reinstated and enemies no longer do damage based on what level you are on.


Yesterday was all about adding a new enemy... the gum droplets. The gumdrops are horrible things with faces that creep me out. Right now they feel like the other enemies, so to make them different when they die, they explode into four gum droplets.

While still unfinished, these gum droplets are impossible to shoot, because if you're shooting something to death what chance would they have? They can die from explosives like rockets and the bouncy grenade.

Because its tough to destroy them, they do no damage, instead they slow the player down. In the coming days or hours even they will be enhanced and finalized.

There is an image slicer that takes sprite sheets and cuts them up to allow for lazy mod support. A lot of the time yesterday was spent on getting their sprite sheet to be sliced correct. There are 4 sprites for each color and it turned into a logistical issue for a bit.

New to the game are damage points that will jump out of whatever takes damage. That might get pulled from the game as it continues, but for now as a time capsule, here they are in this animated screenshot.


While there was an update yesterday, I'd rather discuss keywords. Even with this development blog, Twitter and all sorts of things hoping to garner traffic to Cake Kills Candy.... its our other game that seems to have even the tiniest bit of traffic. Despite Cake Kills Candy being in four game jams, after the first three days its all just flat lined. Without the four game jams there would probably be no traffic to the game.

Meanwhile, our other game AlienVania seems to get traffic via keywords such as MetroidVania and Rogue. At some point it was meant to be a rogue, but that was pulled and I had forgotten to change the keyword. Traffic kept rolling in via that keyword until I changed it. The MetroidVania still stuck because it is a bare bones, 10 day game jam MetroidVania. Even the tiniest bit of traffic that it garners is more than Cake Kills Candy.

So to shake things up, the keywords have been changed to hopefully get more views.

Even on Twitter, some keywords seem to gather far more attention, likes and retweets than others that are even more popular.

I took a few days off off from doing these blogs to give someone else a chance at the top without bumping this daily. The past four days was spent with enemies and enhancing the weapons.


There are four different tank marshmallows. They have high health and move slower than normal enemies. The more damage they take, the faster they run. Its easier and more effective to just not shoot them.

With these enemies came new stats such as increasing speed rather than maximum speed all the time. The player has this stat and its a wise stat to have, but with the crunch of the original game jam, the time was never taken. There is also a new rush attack that can be applied to any enemy, but it will be just for these enemies at the moment.


Grenades were something in the game, but removed from it, because when you can hop on enemies why would you need grenades? With the move to make the game fair for both enemies and the player, the enemies can no longer be stomped. The game feels easy enough when you can shoot through enemies. The drawback to unstompable enemies is the fact that enemies can bunch up in nooks so you need a grenade to destroy them.


It took a good three days for these droplets to be finalized. These enemies are more of a trap that gets launched out of the larger gumdrops. The droplets stand in one place hopping until you walk close enough to them and then they pounce! If these droplets cling to the player, then the player moves slower, jumps lower and it takes multiple consecutive jumps from the player to shake them off. They only do damage the first time they cling and if the player has one on them, then the others refrain from pouncing.


In the past four days a lot of the weapons have been reworked and enhanced. Projectiles have changed, muzzle flashes and hits have changed as well. This is something that has been in the sprite sheet for weeks, but in the crunch of a game jam, they were never added. Cake Kills Candy has its own sprite sheet slicer for lazy mod support and dealing with the slicer's math is a slower process, but it sure beats having to cut and paste images to make sprites.

Anyway, bananas have changed to six shot weapons. Once you're out, you can throw the peels or set them down. These peels make enemies slip and fall. It was about three days working on this weapon on and off between enemies. It might not look like it from the gif, but seeing and hearing the enemies slip turns this simple throwable into a joy to experience!


It is within these past four days that I've noticed there's less of a Twitter response with less retweets and less likes. Traffic for the game continues to be flat lined with a page view every few days.

(1 edit)


There are four larger style marshmallows that are already finished enough, but yesterday was about fleshing out the mini marshmallows. There are four minis, a default enemy type, a rocket, a spiral marshmallow that jumps when the player jumps (for now) and an exploder. The rocket will turn into a rocket when it spots the player where it then bounces horizontally off enemies and walls. When it hits the player it detonates.

As for the exploder, when it sees the player, it will charge at and follow the player. If it comes within a certain radius of the player it stops and arms itself for a brief second before exploding. Explosions can damage both the enemies and the player. If the player is damaged in the explosion, the player becomes invulnerable like all damage taken, thus preventing the player from dying if caught in the explosive wave. The explosions will now push affected objects away from the point of origin.

I am back again to murder your browser, RAM and modem!


With 8 marshmallow enemies and gumdrops finished it was time to make the world they all live in! The world turned out far better than either of us were anticipating and I think that's because less background tiles is more. The background tiles look good, but having interior backgrounds turned each level ugly. Plus it was tough to navigate as it all blended together.

Rather than a simple tileset swap, there are a different number of tiles and arrangement here along with a new cloud system. The entire process was about six hours of programming. With a different color palette, this makes the CloudMallow Cove look and feel different than the previous tilesets. The game is also divided into two sections where the first eleven levels take place with the old tilesets and original enemies and the next ten takes place in the gorgeous CloudMallow Kingdom.

If I've had 40 updates and each one of these is 10+ MB this page is 400+ MB. Maybe even 600 MB.

To give you all a break, I'll space out a visual update for next time.

Production continues, but its obvious I am spinning my wheels when it comes to marketing... all my games. Over on Twitter, Cake Kills Candy gets a lot of likes and a few retweets. I can break into double digits and it feels good. Getting people to the page is a different story.


To make the page look more desirable, I made a new 2+ MB .gif for the to get people to click the game.

Has it worked? Maybe. 5 page views and 5 downloads yesterday. Interesting enough the other game AlienVania's page view rate took a dive.

I consider more a place for developers than players. Perhaps if I had a grander game it would get more players, but in the meantime I have gone the free asset route. I made a free art asset pack for publicity. Come for the art, stay for the games.

Has it worked? Again, maybe. It managed to net a new follower so I consider that a success. A developer that uses free assets, so I assume he's here for the assets. As for the traffic, it seems to be flowing to the free assets. 25 is better than 5 even if 20 is going to the assets. According to the analytics the majority percentage find the assets from the game assets tag over the newest game assets, my profile and my feed. That gives me hope that people will still find the assets after they get older.