#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
f and left/right click to add/remove a fruit
- hold
g and left/right click to add the guillotine
- hold
s and click to move the start position. use the mouse wheel to
change its direction
- hold
e to 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