bird food postmortem
#ld44 is my first Ludum Dare, and it was a fantastic experience. What started as a few hours of stress and worry turned into something really enlightening and special and I've been soooo upbeat all week since! Maybe it's the sleep deprivation (!) but on Monday I felt so completely pumped and accomplished.
There's way more written here than intended, but I think (hope?) it's a valuable insight into how the design of the game was approached and how its failures appeared. You'll find out more about the game than expected ^-^. If you haven't seen bird food yet and have time, please play before reading!
Overview
The game was made in 48 hours, submitted for the jam because the codebase it's built on is a work in progress and releasing the source code would be troublesome. All gameplay code and art was created during the jam, and the sounds were created with Bfxr except for the guillotine sound, which is two creative commons sounds combined and altered.
Coming up with a mechanic for the theme was hard, right? A lot of the difficult came from the wording of it being very narrative-applicable. It filled my head with metaphor about the workplace and thoughts of dystopia which are interesting, but i wanted to focus on gameplay. Approaching it from the perspective of sacrifice made it easier to work with.
bird food has you controlling a little worm whose objective is to make it through a series of grid-based levels. wormy moves at a fixed speed, and can move left, right, up, and down within an 8x8 grid. The levels are built on a 16x16 grid. To be allowed to move through a level, wormy must consume all the fruit present on the grid. wormy grows as food is consumed, which creates problems for the player to solve when navigating tight areas to collect more fruit. wormy can use conveniently placed guillotines to remove body segments to reach previously unobtainable fruit.
Core mechanic

The core mechanic of cutting wormy up with the guillotine is the main hook of the game, and I'm really happy with how it feels and acts. the guillotine feels good to use, and hopefully inspires a thought of "oh, that's cool!" in the player. The sound and screen shake add so much to making slicing up wormy feel satisfying. You sliced wormy up when leaving a level even when you didn't need to, didn't you, you monster?
It ended up being difficult to design with on its own, because the situations the design can force are so limited and obvious. Based on the feedback of the game I think this didn't matter too much, because in the amount of time someone dedicates to playing a jam game, the idea of the guillotine carries itself, but for a longer game experience there would need to be additional elements in the world to drive new situations and challenges as the player progresses: buttons that need to be triggered together by a long wormy, or separately by a shorter one, and maybe attacking elements like rising floor spikes or arrows that would hit a long wormy, but that a shorter wormy could avoid.
Another potential aspect is having multiple guillotines. I managed to code myself into a hole with that one: a single guillotine was implemented, then referenced in a few separate places, and by the time I wanted to try multiple guillotines it became difficult to think about tearing the code apart within the given timeframe. Lesson learnt for future jams, almost always throw stuff into lists. In most cases it's not too much extra effort to make your code operate on multiple instances of things if you're thinking about it. But sloppiness here became a pain point.
The controls, the grid, the horror
Which brings us to the biggest pain point. Despite every comment being positive (which I'm so happy about!), almost all of them mention the same thing: the grid, and to some extent how that relates to the controls. As mentioned, wormy segments reside in an 8x8 grid, whilst level segments live in a 16x16 grid. They're different. It sucks, and I couldn't think of an adequate solution in time after making the mistake. When working with a grid based game, you really need to have a grid size chosen before working on level design - if you decide to change that grid size, you often end up throwing a lot of design away. I decided early on, pre-level design, that 8x8 movement feels good on its own. With a fixed rate of movement, the grid size and speed directly impact the responsiveness of the controls. When it came to doing the level art, 16x16 just kind of ... happened. I'm not really sure why. It was a mistake, and it negatively impacted the result.
Half way through the jam I realised that I enjoyed the controls even within the mixed grid sizes, whilst also realising it's extremely frustrating at first. I tried to work around it. Changing the player movement to be 16x16 sucked, soooooo so much. It feels so unresponsive that it was just awful, far more so than the feeling of miscalculating the movement in an 8x8 grid. The easily tweakable aspect is the rate at which wormy moves. wormy moves slower in the released version than throughout most of development, but based on the comments probably should have been slowed down more.
The ideal would have been to design some level elements at 8x8 rather than 16x16, to keep the responsiveness of controls without affecting player expectations that the 16x16 levels give. Even after messing up the grid spacing of the levels this possibly could have been mitigated by making the fruit reside in the 8x8 grid - but that was another oversight.
Minor grievance: the guillotine takes up three grid squares, which made it difficult to place effectively in the small levels. It also can't be rotated.
Level design
But, overall, you did a good job, especially how you teach players how to play without any text at the first levels. - @dainiel-moreno
This comment means a lot to me, because designing levels is often something I struggle with from a creative perspective, but i really wanted to do a good technical job. The intended design was:
- Introduce the player to the movement in the first level.
- Separately introduce the mechanic of fruit unlocking the level exit in the second level.
- Introduce the guillotine in its own on the third level.
- Introduce the guillotine and fruit together.
It's only on the fourth level that the guillotine is required to pass the stage.
Originally, the first level didn't have any fruit - just a block in the centre that you would have to navigate around. As i wasn't able to produce any music for the game, the first level ended up feeling really dead. Fruit got added so that the player would experience something satisfying (the 'ding!' sound) quickly which the navigation alone didn't deliver, but the fruit is placed before wormy can move out of the beginning narrow passage. The player might has to think about fruit pickup affecting the level exit on the second level.

Level three is a special case, having no fruit but requiring the space bar to be pressed to move forward. I don't know how elegant this appears, but it does its job reasonably okay (with the minor bug that pressing space to restart that level when dead causes the end of the level to unlock - most players probably don't experience this).
The fourth level didn't require the guillotine at first, but eventually I found that replicating the narrow passage of the first with some fruit at the end requiring a guillotine slice to reach worked well without too much difficultly at this early point.

I was worried about successfully communicating to the player where a level ends, when they can't exit, and why. The art for the level exit indicators aren't great. Thankfully, the 'ding!' sound is extremely effective and gratifying, and nobody mentioned struggling with this.
Missed opportunities
Sound was troublesome. A few people mentioned that with the difficult controls, having a sound match the movement of wormy would assist in moving accurately. They're completely right, and it's part of why fruit so densely packs some segments of the levels. I tried to add a Pacman-like movement sound but the things I tried ended up sounding irritating. I should have tried harder to fit this in.
A great comment was someone suggesting that levels change colour to show progress. This would have been such a low effort implementation that would add a lot. I realised just after publishing that there should have been some sense of indicating the player was approaching the end of the game because without that, it becomes so tempting to quit when things get frustrating. Having a progression indicator would have meant a lot.
A similar problem was with level goals. I would have liked to have more flexibility with the win conditions for a level, ideally needing a wormy be greater or shorter than a number of segments to pass. The problem with this was the same as the progression - I failed to think of a way to communicate those things to the player. The general thought was some sort of artwork depicting 'pips' indicating a number of segments wormy should have to pass the level, but it didn't work out. Communicating something to the player was a lot of the problem with the movement system, too - some players think it's too fast, or that 16x16 might be better, but the core problem is that 8x8 tile movement within a 16x16 tile world goes against expectations.
Theme
Very few commenters mentioned the theme, I'm excited to see how the ratings come back for that category. The design was fully intended to adhere to the theme and came to life because of the theme. The struggle of wormy represents the struggle of employment, of cost, and of life. wormy works hard to gain things wormy desires (fruit), but part of that earning ends up costing the same thing that is given up to earn more.
The name of the game, bird food, slightly alludes to the metaphor: the perception of wormy in the player's eye is that wormy is everything about the world. Realistically, wormy is still just one element of the food chain. But the name is mostly nonsense that was thought up an hour before submission when I had to draw the splash screen :)
A minor thing that might have affected perception of this would be being able to carry segments through levels. I was worried about how this might affect design of the levels, but in the end it wouldn't have negatively affected anything.
Development tools
You've played the game, right? And you've made it through all of this text,
which I'm so grateful for! You get an easter egg! Open up
the game, start the
first level, and press shift + e. Surprise! The level editor is in the
final game! Just before intending to remove it before deployment I figured
nobody would trigger it accidentally, and I worked hard on it, so it stayed
in ^-^. Making a level editor is a big time investment in a 48 hour
game, but it made the final hours sooooo much easier.

The controls:
- left click a tile to add a wall, right click to remove (this was draggable until a bug put that to an end, sorry!)
- hold
fand left/right click to add/remove a fruit - hold
gand left/right click to add the guillotine - hold
sand click to move the start position. use the mouse wheel to change its direction - hold
eto move the end position in the same way as the start position
pressing ctrl + s (on the devel version) saves the file to something like
this:
guillotine 14 10
goal 26 4 right
player 4 0 up
wall 0 0
wall 0 2
wall 0 4
fruit 8 8
fruit 10 16
fruit 4 8
When you die in a level, pressing ctrl + space respawns you in edit mode -
which made it easy to make sure fruit was preserved correctly when saved.
The levels were set to read in a fixed list of file names (1.lvl, 2.lvl,
3.lvl) and if a file doesn't exist, the level starts in edit mode, which made
designing the game as simple as playing through it. I'm a tool junkie, so i
was happy with this system, and the expression you get from being able to
"draw" tiles is a great bonus.
Bugs
Testing is an extremely important step, which I completely neglected because I have nobody to ask to test it :) The only known bug is that sometimes wormy's head visually displaces from the rest of the segments. Limiting the scope of the project to just a few elements, and accepting some of the problems highlighted instead of striving to improve every aspect of the design, saved a lot of heartache. Having just one minor bug is mostly luck and witchcraft, which I'm extremely thankful for!
Reception
Almost every comment mentioned the same flaw (the grid), which made it so surprising that every comment was also incredibly flattering and kind. I doubt I'll work on a post-ld version of bird food, but I'm so glad to have made it and that people enjoyed it - at least one person even finished it! Now that you know how to remove tiles, you can finish it too :)
Thank you for playing and reading! <3