I'm pretty happy with how it turned out, and the response has been pretty positive. I thought I'd talk a bit about the development process and what I think of the final product.
Planning the recipe
I went into this Ludum Dare with a few goals in mind. First, I wanted to work solo. Collaborating with other developers is one of my favorite parts of game jamming, but I had some social obligations that prevented me from being available all weekend. I didn't want to flake out on anyone, so I decided to go it alone this time. I did end up reaching out to the multi-talented Teo Acosta, who took time away from his own game jam to compose the awesome music track in the game.
Second, I wanted to keep the scope very small. I've participated in quite a few game jams so far, and this is by far the most important lesson I've learned. I try to come up with a game so simple that I can get it up and playable in a matter of hours. That's the only way I've ever been able to end up with something even remotely polished by the end.
For Hop & Chop, I'd had already brainstormed an unrelated a 1-button shooting game where your gun bounced and rotated out of your control and all you could do was time your shots. When the Ludum Dare theme "Entire game on one screen" was announced, I wasn't feeling particularly inspired by it, so I decided to try out the "bouncing shooter" concept.
My third goal was to draw some sprites of food. For whatever reason, I find drawing food to be satisfying, so I figured I'd pick a food-related theme. Just like that, the shooting/cooking idea came together.
Second, I wanted to keep the scope very small. I've participated in quite a few game jams so far, and this is by far the most important lesson I've learned. I try to come up with a game so simple that I can get it up and playable in a matter of hours. That's the only way I've ever been able to end up with something even remotely polished by the end.
For Hop & Chop, I'd had already brainstormed an unrelated a 1-button shooting game where your gun bounced and rotated out of your control and all you could do was time your shots. When the Ludum Dare theme "Entire game on one screen" was announced, I wasn't feeling particularly inspired by it, so I decided to try out the "bouncing shooter" concept.
My third goal was to draw some sprites of food. For whatever reason, I find drawing food to be satisfying, so I figured I'd pick a food-related theme. Just like that, the shooting/cooking idea came together.
Cooking up a storm
With my simple concept in mind, I managed to get something playable Friday night: a cook avatar that bounced around shooting cleavers and some fish that could be chopped up:
If you look closely, you'll notice that the fish are first chopped into large chunks, which are then chopped into medium chunks, which are then chopped into small chunks, which don't get chopped any smaller. This is the beginnings of the "ingredients system", which would later allow me to build out the various recipes in the game. This system is nothing fancy, but it ended up taking the most time to fully implement.
I'm going to go into some of the details of how the ingredients were set up in Unity. I'll try to keep the technical stuff to a minimum, so bear with me!
Food for thought
I'm going to go into some of the details of how the ingredients were set up in Unity. I'll try to keep the technical stuff to a minimum, so bear with me!
This is a screenshot of some ingredients in the Unity editor. On the left are the "prefabs" for ingredients of various stages. On the right is the inspector window for the currently selected ingredient prefab Fish0 with the various Food script fields I exposed from code. Each of the ingredient prefabs on the left have the same Food script on them.
The most interesting fields are the Next Stage Foods and Combines With lists. These are lists of objects that I can drag-and-drop ingredient prefabs into in order to establish relationships between ingredients or the different stages of an ingredient.
For example, the Fish0 prefab has Fish1 and Fish2 listed in the Next Stage Foods list. That means when the Fish0 game object collides with a flying knife, the Food script will destroy it and create new game objects based on the Fish1 and Fish2 prefabs. You can see on the left that those prefabs have sprites that look like the two halves of a fish. As a result, the whole fish appears to be chopped into two halves. If we were to inspect the Fish1 and Fish2 fields, they'd both have Fish3 listed in their Next Stage Foods lists, and Fish3 would have Fish4 in its list as well. The idea is to set up a chain of ingredients for the player to progress through by chopping.
Similarly, when two ingredient game objects collide, each of their Food scripts check to see if the other is on their Combines With list. If so, both ingredients are destroyed and a new ingredient from the Next Stage Foods list is created. For example, the Dough1 prefab you see on the left might have Pork1 in its Combines With list. If two of those ingredient game objects collide, they are both destroyed and a new Dumpling0 is created. The pork ingredient chain and the dough ingredient chain are then merged into a new dumpling ingredient chain.
All of the recipes in the game were put together by dragging-and-dropping ingredient prefabs into each other's lists to establish these chains of progression and combination. It took a while to build the ingredient system out in code, but once it was in place, I could quickly assemble and tweak recipes in the editor. This proved to be very useful when I decided to squeeze in the fried rice and mochi recipes during the final hours of the game jam!
Taste testing
So how did the game turn out? I had fun working on it, and the finished product still makes me chuckle. The comments I've gotten on the Ludum Dare page and in face-to-face playtests have been mostly positive. That said, player feedback and my own observations have revealed a number of design issues. I'm going to list just a few of the issues and then describe how I might go about addressing them.
One of the most common issues was that players couldn't tell what's going on with all the chaotically bouncing ingredients. It is pretty easy for players to spam their way through the first few recipes without understanding how ingredients are chopped and combined. They typically get stuck on the fried rice or dumpling levels because those require more deliberate tactics. It turns out my precious ingredient chains can be pretty inscrutable when they're represented by dozens of sprites bouncing around the screen.
To make the underlying system more apparent to the player, there are several techniques I could try out. One solution that wouldn't require additional code functionality is to simply add in more recipes that introduce each mechanic more gradually so the player can observe and internalize them in isolation. Another approach is to explain how the game works to the player explicitly through text, illustrations, or a directed tutorial, although that would be work-intensive and risks boring the player. A third option is to just change the system itself to something more comprehensible. What if each level was a discrete step in a recipe instead of making the entire dish? What if the ingredients don't move at all? What if the game was turn-based?
The issue that was most often voiced by the players themselves was how the control scheme worked. People seem to understand quickly that they can't control their avatar, but shooting accurately is still a significant timing challenge. I'd already taken steps during development to make hitting targets easier: I slowed the avatar rotation several times and made the default projectile fire 3 cleavers in a spread pattern, increasing the odds of hitting something.
I could continue to tweak and tune in this manner, or I could change the control scheme entirely. Sure, the "spinning gun" was the original concept, but that doesn't make it immune to change. What if the avatar moved side to side and didn't rotate, like a traditional SHMUP? What if the avatar stayed stationary and shot towards wherever the player tapped, like a "turret style" shooter? What if there was no avatar, and projectiles shot up from the bottom of the screen? These would all be cheap experiments, so they'd probably be worth trying out.
Finally, lots of players get stuck due to the level structure. Recipes typically require the player to perform chopping, combining, and cooking actions in sequence. There is also limited "ammo", which consists of different cooking tools they can shoot to perform each action. There are several awkward situations that occur if the player doesn't perform a given step in a recipe. Players often run out of "knife" ammo before they've finished chopping. This is especially noticeable if the recipe then requires combining and cooking steps, which can't be completed with the un-chopped ingredients. The player has to wait for the level timer to run out and the level to end so they can try again.
In fact, I added the 10- to 15-second time limit as a quick and dirty way to reduce the pain of these "stuck moments" by only making the player wait a few seconds for the level to reset. Kludgey design fixes like that are typical of game jams, but now that there's time to think the problem through, I should do better. What if there was no limited ammo, and the appropriate cooking tool became equipped based on the current recipe step? What if there were no discrete levels, and new ingredients kept spawning for successive recipes?
Food for thought
All this reflection might be overkill for such a simple game jam project, but hopefully it was interesting to read. It was certainly a good game design exercise for me. This game jam was just what I needed after a recent string of uncompleted projects. It's so refreshing to finish something, even if it's small and low-risk. Now I've got to learn what I can from this experience and carry over the enthusiasm into my next game.
Thanks for reading!
