Welcome to the third devlog of “Package Party”!

In the previous devlog, I explained the basics of the terrain and level layouts. With that implemented, we can think about delivering packages. Most importantly:

• How can we make delivering packages fun?
• How can we make delivery harder/different each level?
• How do we clearly show the players what and where they need to deliver?

Before we continue, here's a video of the latest prototype for the game. (Because the rest of this devlog will be theoretical talk about making games as fun as possible, with images from many games except for my own game :p)

1. Fun

For most people, walking around with a package only to drop it a few pixels further down the road, is not an accurate description of “fun”.

Then I remembered some games I used to play a LOT with my family: the LEGO games.

(In this particular level, you're at the pirate headquarters, and you're basically running around trying to steal stuff from one pirate and bring it to another one, so he can unlock some sort of door. By the way: I love the way Jack Sparrow walks and runs in this game :p)

In many of the levels, you’re really just trying to find something and bring it to the right place (while SMASHING everything along the way). Yet, it was fun and didn’t feel like a delivery service. How? Because those games implemented platformer and physics puzzle mechanics.

There were jumps that you needed to time correctly, there were objects that needed to be rotated or positioned correctly for a certain effect to work, etc. This kept the game moving, made it feel alive and energetic.

I want to do the same for this game.

This game should basically be a platformer-puzzle, with the added benefits of being cooperative and the stress of delivering packages on time.

So I decided on the following core mechanics:

• THROWING: Packages can be thrown. How long you press the throw button determines the strength of the throw. If you press it normally (“quickly”), it just drops the package, like you’d expect.
• JUMPING: The players can jump, and the levels take full advantage of this. One of the first objects I created was a trampoline, and from that moment the possibilities were endless! (Elevators, catapults, etc.) Not only could players jump … if you threw a package on the trampoline, it would jump as well, allowing for new ways to deliver packages.
• VEHICLES: As you progress, levels contain more and more vehicles. By pressing a certain button, you can enter (or exit) a vehicle. When you’re in a vehicle, the control scheme switches of course: a truck will accelerate instead of jump, a plane will fly up and down by pressing buttons, etc.

These mechanics give players many ways to navigate the levels and deliver packages.

2. Difficulty & Diversity

There’s a limit to how large I can make cities. And after a while, you should be quite skillful at jumping and running around. I needed something more to keep the difficulty increasing, to present more variety.

That’s when I turned to Overcooked for inspiration.

… and subsequently ignored most of the lessons I learned, because they weren’t applicable to my game, but I still got some good things out of it!

NOTE: The next section will talk quite a lot about Overcooked and its level design. It will come as no surprise that Overcooked was the direct inspiration for this game. It’s just a really fun game, and it’s the only game where I can get gamers and non-gamers to be interested and play. I want my game to be like that too. (But I don’t want to copy too much from Overcooked. In fact, I am trying to be as different as possible, and maybe even improve some things I found lacking in Overcooked.)

First of all: Overcooked works with recipes. You can’t just pick up an ingredient and deliver it – no, you need to combine it with other ingredients, perhaps cook it/cut it/fry it, before it’s finished.

The same is also true for packages. There are multiple stages in the process, and there can be multiple different “things” inside the same package.

Mechanic 1: Build a system that allows packages to be built from multiple components.

There are several other things that Overcooked uses to great effect, which I think can be applied in my game as well:

Mechanic 2: Timed actions. Some parts of the process aren’t “immediate”. This means there’s never a clear, straight path towards victory: while you’re waiting for one thing to finish, you really should start doing something else, and that’s how great strategies fail :p

• For example, say you have to deliver a package, but it needs to be “gift wrapped”. Then you must go to the place where they wrap it (… a gift-wrapping station?) and wait a few seconds until it finished.
• Of course, random conveyor belts throughout a city isn’t great, and I think I can actually improve on the mechanic. How? With water currents! (This will be explained in detail later.)
• I’m already looking into weather effects, creating difficult terrain (cliffs, lakes, steep hills, etc.), creating “breakdown events” for vehicles, etc.
• For example, if you’re driving the truck, the gas might run out, which means one player has to go and fill the tank. It’s logical, it directly ties into your actions and what you want to do, but it also means you need to cooperate more.

Mechanic 3: One way streets. Most notably, they use conveyor belts that automatically transport stuff. This is genius: it takes some of the load off the player’s shoulders (by moving things automatically, in the background), but also forces players to strategize and time their actions well.

Mechanic 4: Random events/obstacles. Almost every level in Overcooked has some weird obstacle ruining everything. (The whole restaurant splits in two, you’re on a wobbling ship, etc.)

3. The Graphical Interface

If packages can become this complex (multiple components, multiple locations to drop off, etc.), the game will soon become overwhelming. Right from the start, I knew I needed to carefully consider my interface and how I wanted to show information.

At first, packages only had their icon. The player had to match this icon with the outstanding delivery (in the top left), to know where it should be going (and other information).

Sure, this was a challenge and a puzzle. But was it fun? No. You were constantly confused and stressed out.

Instead, I opted for as much clarity/information as possible. After some trial and error, I decided on the following interface:

Every “order” gets this little delivery interface, at the top left of the screen. It shows:

• How much time there is left
• Which package it is (by icon)
• Where it should be picked up
• And where it should be dropped off

When I was learning about design, I learned about redundancy: communicate information in multiple ways, to make sure players catch it. That’s why every location has a color, a shape and a name.

That’s also why the background color of the interface is the same as the destination. I’ve found this to be a huge improvement: once I did this, all questions like “but where should this package go?” and “which delivery is this?” from my playtesters were gone.

To connect this “delivery interface” with the actual package in the level, I added the same information on top of the package. It’s shaped kind of like the pinpoint symbol of Google maps, and I think that works very well actually:

That’s it for the third devlog! The next one will probably delve a little deeper into the delivery mechanics, because it’s the backbone of the game. After that, I’m ready to show you some more graphics and fun physics stuff.