Raven Delivery Service Post-mortem

This is a post-mortem writeup for Raven Delivery Service.

This was my 15th time competing in LD, and this time around we had (for the first time!) a team of 4, including @ibyume, @vincent-castelli, @xellaya, and myself. We ended up making a 2-player co-op potion brewing game called Raven Delivery Service, with design heavily inspired by Overcooked. While our game is best enjoyed as a couch co-op game together with a friend, there is also a single-player mode that tests your multitasking abilities as you control both characters at the same time.

Let's first take a look at our results! 

Overall:    56th  (4.000 average from 48 ratings)
Fun:        102th (3.783 average from 48 ratings)
Innovation: 243th (3.413 average from 48 ratings)
Theme:      618th (2.870 average from 48 ratings)
Graphics:   220th (3.935 average from 48 ratings)
Audio:      15th  (4.333 average from 47 ratings)
Mood:       168th (3.705 average from 46 ratings)

Not half bad! It's also worth noting that the average of all 7 scores is 3.72.

Since I've been doing this for quite some time now, we can also reference my stats at ldstats.info. That site hasn't been updated to scrape from LD38 yet, but it's the best way to compare our rankings and ratings to my past entries.

The first thing you'll notice is that my past entries put up some pretty stiff competition! I've scored above 4.0 overall in 9 out of 10 of the past compos that I've entered! Despite doing pretty well this time around, the average score (3.72) is lower than any of the 10 past entries that I've done.

What does this mean? Well...not that much to be completely honest. LD ratings are a fickle thing, and any number of things could have affected them. For one thing, I didn't push as hard as I usually do to get ratings, plus LD was..."interesting" this year, which in theory doesn't affect the actual scores but does affect the amount of feedback. If anything though I think the main contributing factor could have been a lack of polish, and the presence of some general rough edges in our game. (More on this later) Actually, scratch that -- the main contributing factor was probably that a fair number of the raters probably didn't play the game in its co-op mode! We'll dive into that later as well.

It's a pleasant surprise that I was able to place so highly in audio even while only making a single song for the entire game! I have to admit that I've been slacking a bit on the audio front, as I used to make entire soundtracks, but it's cool to see that I don't necessarily have to put in a bunch of different tracks to be appreciated.

What about my personal goals? In my I'm In post this time around, I said that my personal goals for LD38 were:

Working well with everyone on the team? Check! It was quite stressful in the beginning for me knowing that we had two people new to LD and game dev in general and I was worried about being able to ramp them up and loop them into the process. However it seems like things ended up working out and I think we ended up with pretty nice teamwork in the end.

Staying happy and healthy? Hmm...I think I did "OK" on this one but could have done better. There was definitely a period of time in the middle of the project where I was feeling quite pessimistic and didn't know whether the design was really going to work out at all. It felt like there was so much left to get done and that the game hadn't yet reached that moment where it was *fun*. Fortunately my other team members picked me up out of it and we were able to tackle things one thing at a time. Also, we ate well :)

Making something simple? Uhh...no, I failed on that front yet again. More about this later, as I think it deserves its section.

As always, let's go over what went well and what didn't go so well.

What went well

Trying new things, having a bigger team

Not only was our game different than anything we've made in the past, but we had a different energy and flow to the team as well thanks to our two new members! Overall there was a lot of new stuff going on and I think it was great! In addition, I think it felt nice for both myself and @xellaya that we weren't the sole ones responsible for programming and art, respectively, and that we could distribute some of the workload instead of doing 100% of everything.

Controller support

It definitely took a bit of fenagling to get everything to work correctly (this is the first time I've worked with Unity's joystick APIs), but I ended up with working, solid multiplayer controls where you can use either gamepads and/or keyboard in whatever combination you want! We got a comment as such, too:

"I think this is the first time that I've seen someone use Unity's input system correctly in a jam...:cry:"

The main difficulty with input handling was that I didn't want to make any assumptions about the control setups that people had. In the end, I ended up mapping controller #1 to player 2, and controller #2 to player 1, and having keyboard bindings for both players. This way you can play in any way you want:

Of course, in the single-player mode, any and all controls are bound to the single player, so everything "just works".

Major props to @xellaya who drew the control diagrams that we show to the players to explain the controls. They're simple, effective, and work much better than anything we've done in previous games.

I should note that I was really disappointed when the webgl build didn't seem to detect my gamepads properly, especially because Unity basically makes it impossible to make a standalone build that defaults to a specific resolution (their resolution-picked dialog tries to match the aspect ratio of the user's monitor...). But it turns out this was a fluke more-or-less specific to my system (I'm running Windows Server 2012 because I'm weird), and it actually Just Works (tm) on most sensible machines. Hooray!

I still did end up providing a standalone build for anyone who has trouble with WebGL controller inputs and/or wants to remap control bindings. This version did take a slight bit of extra work to make since I had to make sure that the input configuration dialog was self-explanatory and also we supported any reasonable resolution. It's worth nothing that the wide majority of standalone Unity games that I played did not do these two things correctly =(. I know that I'm in the minority here, but just because you have a standard 16:9 widescreen monitor doesn't mean that all of your users will. Construct your game accordingly! This is a little tricky to handle correctly for pixel art games such as ours, but you can use a scripts such as this pixel perfect camera one to help.

Lots of fun details

We had a ton of fun details in the game that were not strictly necessary, but made the game that much more awesome. Things like the actual ravens flying around and unrolling the potion requests, the bubbling of the cauldrons (as well as the super awesome gurgling sound they make!) and last but certainly not least, the beautiful tileset that @xellaya made for me to build out the levels out of.

All of the decorations, vines, and background layers really help pull things together into a more cohesive package rather than just a flat old boring set of platforms. I love it!

Coming up with a single-player variant that worked

At a certain point in the design phase I realized that I needed to come up with a decent single-player game mode. Up until that point I knew that we were going to have two witches and that our main focus would be on cooperative play, but I needed to come up with something that you could play by yourself as well, because I figured (correctly) that a lot of LD raters wouldn't get around to playing the game with a friend.

Fortunately the design for the single-player mode was not too involved at all, and I took a cue from Overcooked in that it was more or less the same game but with one player controlling both witches. So instead of an exercise in cooperation it becomes an exercise in multitasking.

One thing that had to change in order to make this work is that the cool little minigame arrows that you have to press in order to get / upgrade the ingredients had to go away for the single-player mode, because the whole point of single-player is that while one witch is gathering an ingredient you get to move the other witch around. This was unfortunate in that the single-player mode didn't really have the "full experience" but the game wouldn't make sense otherwise.

Some people who played the game in single-player mode said that they didn't actually realize you could control both of the two different witches in the first level. Luckily, I set up the second level such that you **have** to switch between the witches, so that level sort of forces you to make that realization.

Co-op design

Saving the most important (and most lengthy) for last...

Making a co-op game was great and I would definitely do it again! When we settled on our idea, I knew that I wanted to achieve the same feelings of cooperation + teamwork that you see in Overcooked, and I went forward with design and programming with multiplayer in mind first and foremost.

It was very tricky nailing down the design to create a good "rhythm" of multiplayer gameplay and I could easily write an entire separate post about it. I heavily referenced the Overcooked level designs to see what really made them tick in terms of their design. This article, was extremely elucidating and I recommend it for anyone interested in these specific game design sensibilities.

I knew from the beginning that I wanted to make our game in a platformer-style, so I already knew that the movement would be mostly horizontal with ladders taking you between different levels. The next thing I had to do was to figure out the tasks that you needed to do in the game. Mixing 3 ingredients in the cauldron to make different potions not only was more or less equivalent to the basic design in Overcooked but also made intuitive sense as well, so that was fairly easy to figure out.

The next thing I needed to do was to somehow encourage teamwork over working alone. With just the ingredient gathering stations and the cauldrons, there wasn't any incentive to really work together besides coordinating which ingredients go in which pot. I knew I wanted some element that would encourage people to take on specialized tasks, sort of like an assembly line. Overcooked often does this by letting you transfer objects between each other using tables -- so in effect, you can move ingredients between each other much faster than if you were to just carry them yourself.

My first attempt at replicating that was to make a sort of table alcove that functioned as a "pipe" that you could use to send ingredients through (but could not travel through yourself). At this point I had enough elements to design a full prototype level and start testing the actual game to see how it played.

This is what the prototype level looked like:

There's a lot of placeholder art here, but all of the elements are there -- the two mushroom stations on the left, cauldrons on the right, potion delivery stations on the top, and the two "shelf/table" objects in the middle that you can use to transfer ingredients (which ended up being replaced by the teleporter). Playing through this prototype level was invaluable and I was able to understand a lot of the design issues much better through the process.

Around this time we were also throwing around a number of other ideas, one of which was the ability to speed up the potion brewing process by fanning the flames around the cauldron (which required you to stay at that station). I implemented that without too much difficulty and we tried it out, but I quickly realized that the gameplay boiled down to a super boring assembly line: the optimal strategy was to have player 1 constantly gather mushrooms and send them over, and player 2 put them in the cauldron, fan the flames, and deliver the potions. I had successfully given the players reasons to do specialized tasks but there was never any incentive to switch between tasks, which made the gameplay super repetitive.

From that experiment I realized that allowing you to fan the flames around the cauldron was terrible for gameplay, so I took that feature out right away. That meant that player 2 had extra time left over, so they were incentivized to switch roles and help player 1 gather mushrooms.

I was getting closer, and player 2 had a more dynamic role, but there was still a problem: the optimal strategy still had player 1 gathering mushrooms the entire time, which was the most boring job ever. I had a number of different variables that I could tweak here:

After a while I realized that the way to get player 1 to do more than one thing was to make player 2's job require help. Putting ingredients in the cauldron was straightforward and didn't take a lot of time, but by changing the level layout by increasing the distance between the cauldrons and the potion delivery spots, I increased the amount of time taken by potion delivery. That gave player 1 a reason to go over and help player 2 while they were off delivering a potion.

We didn't end up using this level design at all in the final game, but it was still a valuable learning exercise for me to learn what exactly made the game fun -- ensuring that each person was able to do something different, but also that the players didn't get too comfortable doing any one specific thing. As with Overcooked, the main way to keep things dynamic is to make sure that there are more tasks to do than there are players. This was part of the reason that I introduced the enchanting station as a mechanic.

What didn't go so well

LD stuff

The Ludum Dare event itself was..."interesting" this year. This didn't affect us directly too much, but it's still worth mentioning as a small point.

Single-player learning curve

Although the single player design was fairly easy to implement and I actually had a ton of fun playing it and coming up with optimized strategies for high scores, I think a number of players probably weren't able to manage using both witches at once, as it does require you to be pretty good at multitasking and managing different things at once. It's unfortunate but I think for those players the real essence of the game isn't really there. The single-player mode is actually quite a bit more "difficult" than the multiplayer mode I think.

On the plus side as I mentioned, the second level forces you to switch between witches in order to do anything, so I think at least that part shoul be interesting no matter what. But aside from that, I think this is just the way that the game had to be. I could have somewhat alleviated the issue if I made all of the gathering timers longer (thus giving you more time to think about multitasking), but doing so would make the game more boring for those players who **are** good at multitasking and enjoy the challenge.

Design challenges

I'm pretty happy with how the game design ended up working out overall. However there were some icky design issues that I ran into while trying to come up with good gameplay and well-designed levels that I'd like to point out.

The first and main issue was just the overall movement and layout style of the game. Yes, I really wanted to see what it would be like to have Overcooked-style gameplay work with platformer-like movement. But as it turns out, if you want to have a game like Overcooked, it really does work much better as a top-down game. The platformer movement (sans jumping) that we went with worked, but having gravity means that you are essentially limited to horizontal movement without the aid of ladders. So not only is your movement mainly 1-dimensional, but you have to have all these ladders everywhere.

This means that overall the paths are much much more linear and that the spaces in general aren't very open. This quickly became a big issue in the later two levels where it became a challenge just to fit all of the different stations that I wanted into the level in the first place.

Another related issue was needing the teleporter in order to transfer ingredients across spaces effectively. While this worked (particularly in levels 2 and 3), Overcooked had a much cleaner and flexible design in that they allow you to place ingredients on tables -- which also form the walls and layout of the level itself. That didn't make sense with our platformer world, hence the need for the teleporters. But again, that ended up being yet another element that I needed to cram into the levels, which were already cluttered by all the different stations that were needed. (it didn't help that most of the stations were 2x1 blocks).

Yet another issue was with the teleporter itself -- you can put multiple items through the teleporter one after another, but they end up stacking over each other in the exact same spot and the order in which you end up picking them up on the other side is anything but obvious.

None of these issues were gamebreaking per se, and I don't think we really could have done too much about them and still made the game that we did. But they were issues that cropped up nonetheless.

Project scope, polish and amount of content

Oof, the biggie. Of course, it's not uncommon that people bite off more than they are comfortable chewing, but I do think that in the past I have definitely done better -- Melody Muncher, Rhythm Gunner, and even Nyamo's Adventure, for example, involved much smaller core ideas, and as such they ended up being more polished final products.

I think the issue is that coming up with a small concept always sounds great in practice, but anything interesting and worthwhile inevitably ends up being a really nontrivial amount of effort. At the point when we finally thought of the idea of the Overcooked-like game, we were also reaching the end of our wits on Friday night, as I kept on trying to think of new ideas but nothing was really coming to mind. Looking back on it, the connection of our game to "small world" is a bit tenuous, but I think that's fine in the end. The one other idea we had was a game about anthropomorphic pollen invading a person's nose. If we had made that game instead, everything would have turned out completely different! (haha...)

And so we settled on our idea, which ended up being a very fun one in the end. But I think the biggest issue with the idea was that it involved so many moving parts to come together before we really had the actual game on our hands. Before our game could really "take life" we needed all of these parts:

And of course even after getting all that done and having the "core game" there were still so many things left to do, like the game timer, endgame countdown, menu, instructions, level design, game balance, UI, and all of those such things. I think because of all of this it was very difficult for me to see the game coming together as a whole, even though in reality we were doing good work on all of the constituent parts. Working as the game designer it was quite concerning for me too, that I couldn't really tell whether the game was really going to be fun or not. I worried a lot that we would get too far in and then discover that the design wasn't really fun, and then it would be too late to make very many changes.

Of course another result was that we didn't have time to polish very many things and spend time on all of the details as we would if we had done a smaller idea. Fortunately we were still able to put in some very neat details like the ravens flying around and things like that, but we really wanted to do a post-game score screen that displays the potions that you were able to make, and also gives you some sort of awards for getting high scores. But there ended up being no time for that. Similarly, our tutorial screens were simple static images because we really had to rush through those. I'm glad that people were still able to understand the gameplay despite that.

In the end I don't regret taking on our idea, but I think in the future it's important to be realistic about expectations and understand that there is a certain higher level of risk when tackling such a large idea. It would probably help to outline all of the different parts that need to come together to get the core gameplay done before finalizing the idea, to see if there's any way we can strip it down, or at least to see what we're getting ourselves into.

I've written quite enough now, so this'll be the end of my write-up. Hopefully someone finds the retrospective interesting in some way. Hope to see you all next LD!

<< Back to "Articles"