Welcome to the twenty-fourth devlog!

Last devlog marked the release of v0.2 of the game, with MANY changes to the gameplay. In this devlog I want to explain what was changed and why I did it. Hopefully you learn a lot about game development, and if not, you’ll at least see the progress I made in the game.

After the playtest

When I playtest the game, I do the following things:

• I perform a screen capture of the whole thing
• I sit back and watch the others play (I try to interact as little as possible)
• After the playtesting (sometimes halfway) I ask some questions. Not questions like “did you like the game”, which is always answered with “yeah yeah”. No, questions like “which level did you like the most and why?” These actually generate interesting and truthful answers.

After my first few playtests, I noticed the game was still a bit too difficult to start playing. The tutorial explained too many things at once:

• Moving around
• Button to jump
• Button to pick/drop packages
• The delivery system (which is actually more complex to explain than I thought)
• Falling off the field
• Most importantly: the main idea of the game

Even for seasoned gamers, this might be a bit much. I really needed to improve this before I could continue working on other parts of the game. Look at this! I explain 3 different buttons (6 on keyboard), the delivery system, AND the buttons in-game within the first few seconds of playing the level!

(I'm still experimenting with the best workflow for uploading footage to devlogs. This is a GIF hosted on Imgur.)

My Solution

For the past few weeks, I’d already done a lot of research (reading articles, watching videos, experimenting with small prototypes) on co-op and puzzle level design.

One of the things everyone kept mentioning, is how puzzles are usually as simple/small as possible. Puzzle games take a single mechanic and try to get as many levels as they can out of that single mechanic. Only if they’ve exhausted absolutely every option, they’ll introduce a new mechanic.

So, that night, an idea dawned on me: “what if … we only start with movement?”

The first world only introduces the move key/stick (on controller). The second world introduces jumping. The third world introduces grabbing packages, and so forth. This solved many problems in one go:

• The game would be very easy to get into. (Just one image about which button to use, and you’re playing.)
• The restrictions would surely lead to interesting and out-of-the-box level design.
• I could create the first few worlds (and iterate on level design) more quickly.

So that’s what I did!

It greatly simplified the level design and instructions/tutorial needed. Now, I show a single image on the campaign screen that explains movement on controller/keyboard, and that’s it. (Of course, this will become prettier in the final version of the game.)

Now, when I tested the game, people needed absolutely no introduction or explanation from me. (They did, however, occasionally ask things like “but when will we finally be able to JUMP!?” But that was meant more as a joke.)

Moving packages

Now, the question on your mind is probably: “but if players can only move, how will they deliver packages?!”

The solution presented itself immediately when I turned off the “package grab” code in my engine: players could just push the packages!

Things seemed to be going well. I created almost 10 new levels in which the only thing you could do is move the player. By adding trampolines, height differences, push buttons, and other elements I could keep the levels varied and challenging.

But then I ran into problems again …

After the playtest, again

After a few playtests, with different people and different versions of the game, I ran into a HUGE problem: players were getting frustrated. The fun from the first few levels quickly turned into frustration.

The main reason for that? You guessed it: the package pushing.

It was hard to control, very unpredictable, and felt a little slow/sluggish. Players were fighting with their controller and getting more and more frustrated about not being able to move a package properly over a short distance!

Because players couldn’t jump anymore, and they couldn’t grab packages, the game felt a lot more finnicky, out of the players control, too difficult to handle.

Sometimes, you pushed a package and it did exactly what you wanted. The other 50% of the times, the package turned away from you, or bounced a little too far, or moved too much towards the edge (which meant players had NO way of getting the package to the delivery zone anymore). It came down to VERY precise movement, which isn’t just hard, it’s also not the type of game I want this to be.

Look at me (the CREATOR of the game) having an extremely difficult time pushing a package over a small distance:

The Golden Rule(s)

Puzzle games have a sort of “golden rule”: The puzzle should be hard to solve, challenging, even require out-of-the-box thinking.  But once players know what to do or have a plan, it should NOT be hard to execute. 

My game was doing the exact opposite: players knew they wanted to use the trampoline, but they just kept jumping past it. Players knew that a package needed to be dropped from a certain platform, but they kept accidentally throwing the package off the edge.

Although this game isn’t strictly a puzzle game, it did result in lots of frustration.

There’s also another “golden rule”: Succeed slowly, fail fast

This basically means that the feedback/retry loop of the game should be very short. Successfully delivering a package should be challenging, but if you make a mistake, you should very quickly be able to reset and try again.

Again, my game did the opposite: sometimes, if you just mistimed a jump, it would take a good 20-30 seconds to get back to your position again and be able to do something useful.

As I write this down, in hindsight, it’s always hard to believe the choices you made. With the knowledge I have now, I really don’t understand why past me (from, like, 3 weeks ago) decided that pushing packages was a good idea. But hey, we learn a little every day.

My solution, again

Solving this problem didn’t come down to a genius idea popping into my head. It came down to making a list of possible solutions, and testing them one by one:

• Heavier packages: although it felt nice to have some weight to the packages, and it gave some more control, it only made the game slower
• Secretly move package with the player: whenever a player touched a package, I would add player velocity to the package, which meant it subtly followed the player around. Although this was one of the better solutions, it still wasn’t ideal and failed in many cases.
• Increase angular damping. “Angular damping” controls how quickly a rotation on the object slows down (or, how much force is needed to get an object to rotate). By increasing it (quite dramatically), packages wouldn’t turn away from the players as they pushed them. This was a fine solution, except for the fact that it looked unrealistic, and now pushing packages from an angle was near impossible.
• Hands around the player. I added small cubes (“hands”) at the left and right side of the player. If you walked to a package, these hands would fit around the package, and make the package follow you as you moved/rotated. The problem? Players moved/rotated too fast, which meant packages glitched through the hands. It also looked silly and introduced other problems.
• Not pushing, but kicking: this was the solution I choose! It speaks for itself: when a player runs into a package, it kicks it away (in the same direction as the player was running).

When I implemented the kicking system, suddenly everything fell into place, and I immediately felt gameplay was much nicer.

Here's a video of me playing the new level 3, which has a glue powerup mechanic. This also neatly solved the issue of not being able to grab packages in World 1: by glueing packages to players, they retain lots of control, while at the same time using a very fun mechanic! (Sorry for the choppy frame rate, otherwise GIF size became too large.)

And another video of me playing the new level 2 (with ... conveyor belts), just to illustrate the kicking mechanic on its own, and how it interacts with other forces in the environment.

The kicker

But why was kicking the best solution?

• It gave players full freedom of movement => you weren’t constrained by packages around you
• It gave players much more control => by running into packages from a certain angle, you could control precisely towards where they would be kicked
• It was much faster and more responsive => packages flew faster, you had immediate feedback on your kick
• It’s just fun to kick stuff around a level with realistic physics :p

I quickly created a few levels with this system, tested them, and voila: problem solved. Players were loving the game even more than before. (No really. This might seem like an exaggeration to sell the game or anything, but I was genuinely surprised. The next day, some of the players even walked up to me to say “that game you made was actually really fun”)

Of course, things weren’t perfect: kicking was a bit too strong and sensitive, the levels could be much prettier and interesting, etc. But things were already looking really good. It gave me lots of new ideas (and motivation to work on the game even faster!)

The core of co-op

After all this playtesting and experimenting, I learned a lot. Not only about level design, and code, and making things clear visually, but also about how to make a co-op game.

All the levels I’ve created thus far, were “single component” levels. The game created the package for you, including all components inside, and you just needed to deliver it. This is very useful for tutorial levels and keeps the game clear/streamlined when you first start … but it’s not enough for engaging levels.

Out of all my research, I realized that timers and multi-components were absolutely necessary to make all parts of the game click.

• With timers I mean that certain parts of the process take time. For example, you might need to “gift wrap” the package, which takes 10-15 seconds.
• With multi-components I mean that you need to combine multiple things inside the same box, before you can deliver it. For example: Someone ordered a table? Well, then you need wooden planks, a hammer, and a building manual. Collect these from all corners of the level.

Players even started asking for it or expecting it:

• A: “But … do we need to put something IN the package?”
• Me: “Nope, only need to deliver it.”
• A: “Seriously? That’s easy.”
• B: “Is that in the next level?”
• Me: “Nope, not even in the game yet”

At first, I planned to add these in later worlds. Maybe world 2 or 3, the game would finally have deliveries with multiple parts.

But I decided to move these to the front. The whole first world is a “tutorial/training world” (don’t worry, there’s a story which makes it interesting and logical), and the last few levels will already have different components that require time.

Here's some rough sketches I made. These changes/systems will surely be in the game when the next update rolls around.

Conclusion

That’s exactly what I’m working on right now! It’s a lot of work, because I need to rewrite/modify huge parts of the core of the delivery system. (And I need to create icons for the different components, plus models for different zones/houses where these components will appear.) But once it’s done, I can finish world 1, and within a few weeks I hope to announce v0.3!

So that’s what happened these past few weeks: the game changed a lot, now you know why. It’s astonishing how something so simple (pushing or kicking packages) can make a difference like night and day. But I’m glad I eventually cracked the code to making this game work.

Until next devlog,

Pandaqi

P.S. I’ve been noticing a trend in these devlogs: I explain how I did something … and then redo it … and then redo it again, explaining why the previous idea is bad. I hope this isn’t confusing (and doesn’t paint me as someone who just cannot make up his mind) – it’s just the way development works. By iteration, by prototyping, I can find the golden nuggets of gameplay mechanics.

As I am rewriting parts of the core code, I am able to HEAVILY optimize it and clean it up. Remember: I wrote this code completely by myself 1-2 months ago, and there’s already lots to improve. But if I hadn’t written this “bad code” to begin with, I would have never improvement up to this point. “Fail faster”, as they always say.