[Devlog] A Recipe For Disaster
Last week, I created A Recipe For Disaster. A couch co-op game for 1-4
players, for literally all ages and skill levels, about running a
You can download it here (for free, any platform except iOS):
A Recipe For Disaster - on itch.io
(You only have two buttons to learn, move and throw, and the
campaign is basically one huge interactive tutorial that teaches you how
to bake bread step-by-step.)
Why? Because this was an old idea of mine that seemed fun.
Also why? Because I challenged myself to make and release a complete
game in one week.
I have the terrible habit of trying to make every project of mine "the
next big super successful project!" The result? Even the simplest of
projects becomes way too big, I lose motivation, I make too many
mistakes, and I abandon the project.
So I said to myself: "one week to make a game -- whatever state it's in,
you must publish it after a week and move on"
And I have to say that this was the best possible thing I could have
said to myself. I actually finished the game, had 100% fun and
motivation in doing so, and had loads of fun playing the game with
others. (I will, therefore, probably do more of these "one week games"
in the future!)
In this devlog, I want to tell you the greatest lessons I've learned
and convince you to try this yourself.
What's the idea?
This was the original idea:
"Cooperative. 1-4 players. Each player has their own separate area,
and you can't visit others. Any time you want to use a machine, you must
throw your ingredient into the machine. The catch? Once done, it will
fly out of the machine on the other side."
Basically, I wanted to make a cooperative chaotic cooking game
(obviously inspired by Overcooked), which forces you to work together
100% of the time, just by employing this simple rule. "Anything you put
in, will come out in the area of the player on the other side."
That was the full idea I'd written down a few years ago.
Lesson 0: "Finishing" is 50% of the process
I made the game itself in a week. Five days actually.
But the menus and buttons? The settings? Perfecting mechanics, adding
particles, fixing bugs? A few extra days.
Playtesting the game? With different groups, multiple times? A few extra
Creating trailers? A game website? Screenshots? You get the idea.
Combining everything, I think a week was spent actually developing the
game, and another week in making sure more people will actually find and
play it (besides me and my family).
But hey, "two week games" just doesn't have the same ring to it.
Lesson 1: Stay true to your course
As I was programming the first few machines and ingredients, I quickly
had to make a choice: what are you going to make? What type of
restaurant are you?
It became a bakery. (Why? I was, at that time, writing a scene from a
novel that took place in a bakery. Simple as that.)
Of course, my mind rebelled. What if we add all sorts of sidedishes?
Like coffee and tea? Pie? Cookies?
I constantly had to remind myself that "no, it's a game about baking
bread, nothing else!" And this was instrumental in being able to finish
the game in a week.
Every time I was stuck, I only had to ask myself the simple question:
"what's the next step when making bread? What ingredient/machine/process
do we need?"
And then I just implemented that.
This continued until I'd basically covered the whole process from
planting a seed => slicing/toasting bread. To be honest, I could've
stopped way earlier, or ignored the slicing/toasting of bread. But,
given my history, it's a miracle I even stopped there :p
During that time, I had other ideas, like: what if you could also make
croissants? Or baguettes? Or add nuts and spices to the bread?
All perfectly fine ideas ... but I ignored them. Maybe for expansions,
maybe for a future update.
But for now, it's a game about baking plain old bread, together, in the
silliest way possible. Nothing more, nothing less.
Lesson 2: Help players, but make it optional
As I played the game, I noticed I sometimes got stuck for a few seconds.
I would try to move through a tight space, thinking I had my joystick
pointed in the right direction, but I was slightly off and just kept
bumping into something.
If I, the creator of this game, with a joypad, have this problem ...
surely others will.
And that's a good thought. I added some simple code to help you get
around obstacles if you run into them, and movement was way smoother.
However ... you're basically lying to the player, tweaking their
movement without them knowing it.
This can also lead to extra confusion. Some of my players kept saying
things like "why won't it let me throw this onto that?! I keep moving
Intuitively in games, people try to "run into" objects to steady
themselves, before doing an important action. (You need to put the bread
in the oven? Run into the oven, make sure you're lined up, and then
throw the bread.)
But with my "helping code" active, you couldn't do that! You'd just run
past it diagonally.
So I made it optional in the settings.
Lesson 3: Create a "core game bible"
Over the years, I've developed this idea that good games (in my opinion)
are as simple as they can be, both in input and general rules.
This means that I always ...
It helps to write this down. At the top of my document, I have a list of
5-10 items, which state the core rules of the game that everything must
The important ones are these:
The players have two actions: move and throw. Everything
must use one of these actions, I'm not allowed to create more.
Whenever an object is thrown against something, its content
scatters. (It's randomly thrown onto adjacent squares.)
Cells only accept ingredients/objects if they can use them.
Otherwise, they'll just fly over those cells.
Really, if you remember these, you know almost everything you need for
You might think that this is very restrictive. Boring, even. Just a few
rules, how will the game stay interesting after level 1?
But that's the beauty of restrictions. Restrictions breed
creativity. I had to think "out of the box" to invent 20 unique and
interesting levels, without changing any of these rules.
For example, the whole concept of "scattering" was a result of such a
If I can't pick up objects ... how will this game work? Oh, I know,
you automatically pick up stuff on your cell, or you can remove them
by throwing something against it.
Gradually, this developed into "scattering", which is used for (nearly)
I did not know beforehand, when I started the project, that something
like that would even exist or become a core part of the gameplay. It was
a result of the game bible, the restrictions, trying to keep it simple
Another example: the maximum backpack size. At first, cells and
players could hold any number of objects!
I thought it was "too difficult" to explain a max inventory and ask
players to keep track of that during gameplay.
As it turns out ... it's even more difficult to keep track of what's
happening if you literally have ten things in your backpack. It's too
much! Too overwhelming!
On the last day, therefore, I added a maximum of 4 things. At most
four things in your backpack. At most four things in a cell. Something
doesn't fit? You simply don't pick it up and it keeps flying. The thing
can't go anywhere? Your fault, it's destroyed :p
There is no tutorial explaining this maximum. It was added last-second.
Yet it made all the difference when I played the game with others. Just
a simple, red feedback message "Backpack full!" is enough for them to
get the hint.
Which leads me to ...
Lesson 4: Tutorials
I like to think I've gotten quite good at tutorials. All my latest games
have simple, one-liner rules which are explained with clear images when
(That's why my games usually have "worlds" or "campaigns", where each
level introduces the next tiny step towards the final level, in which I
can finally enable ALL the cool rules and systems I implemented.)
At the same time ... this is what many people do:
They don't read text
They immediately say/think "this is too difficult" or "I don't
They immediately press the button to start
And hope they'll figure it out as they go
Not everyone, and the tutorials still manage to get the gist of the
idea across most of the time, but it's not ideal.
So for future games I'll try something different. No static images at
When you start a level, you just immediately start. However, new
elements get a small box hovering next to them, with a short
icon/explanation. Or simply prompting you to "try out the new location,
see what it does!"
This removes any upfront tutorial and hopefully encourages player to
engage with the new rule/element more.
Remark: at the same time, I'm working towards a future where I can
make games that only have one input (probably the joystick for
movement) and still make them fun and challenging :p I doubt if I'll
ever succeed, but it's something to work towards.
Lesson 5: Iteration
My games share many similarities. As I said earlier, they often have
"worlds" or a "campaign". They often allow keyboard and gamepad input,
for 1-4 players. They often future moving characters, on a grid.
You see what I see? It's an opportunity to use old code and
iterate on it.
Looking at my old code for managing controllers, for example, I could
immediately spot 10+ ways to make it more efficient and robust.
Using this iteration principle, every game I make will always be
quicker to create, but still more efficient and robust.
Remark: as I write this, I've already started my next one-week game.
And again, I could iterate on some existing code, improving it. Heck, I
even managed to get multidirectional conveyor belts fully functional
in less than an hour! Which is the real benchmark for efficiency when
creating games, as we all know.
It's a tiny thing, just taking an hour to improve or rewrite some
old code. But game after game, you start building a huge codebase that
makes every new project way easier to prototype and (bug)fix.
Lesson 6: Marketing takes time, but not that much
Yes, screen grabbing all parts of your game and turning them into
trailers and screenshots is a lot of work.
Similarly, creating your pages, with nice images, fonts, color scheme,
description, tagline, also takes a lot of work.
And it's mostly busy work. You already know how the game works, how it
looks, that it's fun. You're done with the game itself! But others don't
know. And they will never know if their first glance at your game leaves
a bad impression, or no impression at all.
When I actually sat down to do it, I think fully creating the trailers
(both PC and Mobile) took at most 2 hours. Getting screenshots from my
recorded play sessions (and sometimes editing them) took another hour.
Creating the logo, background pattern, marketing text, etcetera another
2 hours at most.
(After creating the game, you already have all the assets and visuals
you need for marketing, so it's mostly searching, searching, searching
-- hey, I can use that, let's copy and paste it here.)
So don't skip out on it. If you do this challenge, reserve day 7 for all
the marketing stuff. You should be able to get it done (somewhat
properly) in that time, giving your project just that final touch it
often needs to be more than a simple prototype.
Lesson 7: Audio fun
A short one. Usually, I just play a nice piano track for the background,
and get my sound effects from a free Sound FX website or generate them
myself using something like Bfxr.
But I want to be better than that!
So this time, I actually recorded a background track with my microphone.
(Guitar, clapping, etc.) In fact, I recorded a special song for the
trailer which (in a funny way) sings how the game works. I think it's
really fun and will probably try to do that again.
I also recorded all Sound FX myself. I opened and closed doors (loudly),
dropped stuff, made noises with my mouth, clicked pens, etc.
I think it turned out quite alright for a first try!
However, the sound effects are a bit unbalanced in terms of
volume/energy. Some can fall away completely in many situations. And I'm
certainly not the best audio engineer in the world, but I'm learning.
Anyway: try to create all sound (effects) yourself for your next game,
or just do something different from your usual style. You'll learn a
lot about how to actually make good/fun/fitting/atmospheric sounds.
Why you should do this challenge
Now let me get serious for a moment.
From a young age, I've heard these one-liners over and over:
When you get out of school, you'll need to make a living, earn your
Right now you can play and fool around, but when you have your
diploma, you should know what you want and get your career going!
You can't just make whatever you want! It needs to be useful --
think about marketing, career, income!
Okay, great, you made this game. But how will you sell it? You
should send it to publishers! Start spamming it on your social
media. Oh, and put ads in it! Ads everywhere!
Many more like it.
The result? I tried to turn every idea I had, from the age of just 12
years old, into something "big and successful and practical and
Which is just wrong. Very, very wrong.
It stifles creativity. It stifles experimentation, personal growth, and
development. It takes all the fun, the spontaneity, the passion out of
your (creative) work. Because everything needs to be perfect, and it
needs to sell, and it needs to be big and portfolio worthy.
No. Stop that. It's hurting everyone growing up around the world.
I just made a game which will generate me no income at all, and will
surely not be enough to get exposure or land a deal with a publisher
somewhere. (I've been dreaming of getting into the ID\@Xbox program for
a few years now ... this will surely not impress them.)
But I only spent a week on it. And I had fun. I learned a lot. I
created systems I can re-use in future projects. I generated more ideas,
some of which are halfway done as we speak. I think this might actually
be the most fun project I ever made. And hey, I can still add it to my
portfolio, my website, and who knows? Maybe it will impress the right
people and get me somewhere. ("Woah, what a coincidence, we need someone
to program a co-op bakery game, and this guy already made one!")
Anyway, my point is: if you're like me, if you've been stuck in huge
projects and huge expectations for years, try something like this. Pick
an idea of which you thought "should create that in the future", and
just make it now, and see how far you get in a week.
(Or a month, or a day, depending, on your schedule and project type of
course. I had the whole week of spare time, minus a few appointments and
other minor projects, to dedicate to this project.)
Try the game if it looks like something you'd enjoy!
It has a solo mode, although I must say it's not the best mode, because
it was obviously built to be a cooperative game.
It's playable on literally anything. (Except iPhones, because screw
Apple and their practices. I can't afford their expensive devices just
so I can export a perfectly functioning game to their app store.)
Try the "one week game" challenge if you feel stuck, or without
inspiration/motivation, or just want to pad your portfolio.
(Frankly, numbers impress people. They shouldn't, but they often do. The
pages on my personal blog where I list all my projects in a certain
category have the highest click-through and response rate of
And that's it for "A Recipe for Disaster"