Welcome to the seventeenth devlog!

Last devlog, we finished level 1. I wrote that devlog a week ago, and this week … I realized I needed to create a different level 1 and rethink my strategy for designing these levels.

Why?

• I asked my parents to test the game as well, and that’s when I found out that level 1 was still too overwhelming/complex. Especially for people who don’t (regularly) game.
• I started design on level 2 (and the levels after that) and noticed that I started way too big. At this pace, level 5 would have been huge and all mechanics I’ve invented would already have been introduced.
• As I was designing future levels, and thinking about future mechanics, I realized I needed to change a few rules. If I didn’t, these mechanics wouldn’t work.

In short: the first level is more suited for level 5 or something. I need to start much smaller and simpler, making the game accessible for everyone.

So, this week I’ve been doing everything necessary for the switch to these new systems: designed a completely new level 1, introduced a tutorial overlay, and made deliveries simpler and more forgiving.

The old level 2

Let me show you a clip of the old level 2, as I was developing it. I think it will immediately be clear why this level was too big and too complex for a level 2.

This level had:

• A huge catapult in the middle (that took several steps to prepare for a single shot)
• An elevator at the back, controlled by a seesaw in front.
• Scaffolding of different levels, which were easy to fall off of
• Dropzones that were completely disconnected from the rest
• Thunderstrikes that turn off all the lights, which you need to turn on by pressing a button that’s ALL the way to the other side of the level.
• And even more stuff …

Way too much for a level 2. (Maybe even too much for any level.)

It looks nice, sure, but it’s too much.

Rethinking the level design

I moved my current level 1 and level 2 to a folder called “future levels”, and started from scratch.

I thought: what’s the absolute SMALLEST level I can design, that still teaches the mechanics well and needs some cooperation. The level I came up with has already been featured a few times throughout these devlogs, but here it is another time:

The huge crane is still in the center, but now it rotates by itself (no need to push buttons or anything), and it has two platforms.

These decisions weren’t immediately obvious to me – the first design still had buttons, and only a single platform. It took a few iterations before I realized I could improve the level even more: by removing the buttons, the level was less cluttered and I needed to explain fewer mechanics. By adding a second platform, using the crane to transport yourself/packages become a more viable option than walking.

Around the crane are two small islands. Each island has a single spot where packages start, and a single “dropzone”. (As you can see, I completely removed the idea of “pickup zones”, and replaced them with the little houses you see here. I’ll explain why in a minute.)

Most importantly: packages ALWAYS need to go to the other side. This forces players to always be on the move, to work together if they don’t want to walk long distances. It’s really simple (just a few lines of code), but it improved the level immensely.

After that, I just played a little with my physics parameters (how fast the crane moves, how stable it is, how fast players can move with packages in their hands, etc.) until it felt right.

I’ve playtested the level countless times, everytime improving a certain aspect of the level or the game in general, until I felt I had a good start. I learned a lot about designing good levels (like “separation of players” and “placing the thing you need the most all the way on the other side of the level”), which I can use when designing all the other levels.

NOTE: To make sure the crane didn’t block the view, I made the ropes a lot longer. This also made the platform more “swingy” and “unstable”. For now, I’m fixing this by “angular locking” a few rope pieces at the top of the chain => this simply means that these pieces cannot rotate, but will stay fixed instead, which essentially reduces the movement freedom of the rope.

NOTE 2: At first, I had a single scene for the construction crane, which allowed both ROTATION and ELEVATION (moving the platform up/down, like an elevator). But this proved a very annoying task for the physics engine, and I decided to create two separate crane objects: one that can only rotate, one that can only move the platform up/down.

Goodbye zones, hello houses!

From the start of the game, deliveries used two zones: the “pickup zone” where each package started, and the “drop zone” that represented the destination of the package.

As I tested the game, I noticed that the dropzones worked well, but the pickup zones were problematic:

• They looked too much like dropzones, creating confusion.
• They cluttered the level even more, because packages could spawn at any position within the zone’s rectangle. So if you waited a little bit, the whole level was littered with packages.
• They took up WAY too much space.
• They were boring, lifeless, unintuitive.
• In the future, I want to create levels where packages consist of multiple components. For that, I need some way to grab individual components, instead of complete packages. That mechanic, and some other mechanics that are on my mind, are not compatible with the pickup zones.

The last bullet point says it all: I needed something that allowed you to grab a package of a single type. In the future, a delivery might say “hammer + wood”, and you would need to grab these two components at different locations.

And so … the idea of the “pickup house” was born. I call them houses, but in reality they are “machines that produce packages”, and will have some significance within the story of the game.

Whenever a new delivery is created, they “spit out” the package of the correct type. The animation is funny, players find it more intuitive, and it creates levels that are much easier on the eye.

In the video below, focus on the little houses on the left/right of the dropzones. (Because I played solo mode, new deliveries mostly occurred right after I delivered the previous one. But sometimes, if you're unlucky, it doubles up and a new delivery is spat out while you're still busy with another one.)

Of course, there are problems

From the start of development, this game had a golden rule: there could NEVER be two deliveries of the same TYPE or with the same DESTINATION.

Yeah, that rule doesn’t work if you have only two zones or two pickup houses.

I tried a few different systems, and eventually decided on the following:

• The system prefers to create unique deliveries. If possible, it picks a type or destination that doesn’t have an active delivery yet.
• But if all possibilities are taken, it will just generate a random delivery.
• When you deliver a package, and there are multiple identical deliveries, the game automatically finds the one with the least time left and completes that one.

The last bullet point is a system to help the player. The game automatically marks the delivery with the highest priority (aka least time left) as delivered, so players don’t need to remember which package belongs to which delivery.

Implementing this system seemed like a nightmare, at first. When a package was dropped in any way (delivered, thrown off the level, etc.), I needed to check if it was the package with the highest priority. If not, I needed to switch lots of variables around and instead work with another delivery.

But … I found a better way! I will try to explain:

• Let’s say you drop a package on the correct zone. The delivery is successful! Let’s call this package “the old one”
• Then the game checks if there are multiple identical deliveries.
  • If not, it does nothing special.
  • If so, it goes through all active deliveries (of the same type and destination), and finds the one with the least time left => call this “the new one”
• Then … it simply swaps the ID of the “old one” with the “new one”. (I assigned all deliveries a unique ID myself in the code.)
• Now comes the most important bit: it only swaps the ID of the graphical interface. In other words, the package keeps its ID, the delivery object keeps its ID, but I just switch around the timers at the top, so that the correct one is removed.

I don’t know if this is clear. It’s a purely visual solution to a problem, and it feels like a hack, but it’s actually completely stable and simplifies the code immensely.

Sometimes, I like to use these kinds of “visual solutions” One of the first developers I heard about it was “2kliksphilip”, but there are certainly more.

What is a visual solution? Well, let me give the example from my own game:

• Every delivery has its own interface, displayed at the top left of the screen.
• In this interface, a timer counts down.
• Once the timer bar has a width of 0, the delivery is over.
• This is a visual solution. Deliveries aren’t defined in the code anywhere, there’s no timer actually counting down, there are no numbers involved, I’m merely making the timers shorter every second. And when the visual representation of the timer has 0 width, that means time’s up, and this delivery has failed!
• (I used this system because it simplifies some other mechanics I want to use. For example, if a delivery goes into “overtime”, I can just reset the width of the timer to a certain size, and voila – the delivery suddenly has 10 extra seconds left. Nothing else needs to be done!)

Hmm … still don’t know if this is clear. Maybe I’ll find a better explanation in the future :p

Why do you think this is a better direction for the game?

I always like asking myself these types of questions, just to make sure I’m making the right decisions.

I think the ideas above improve the game immensely because:

• The first level is less overwhelming: fewer mechanics to teach/explore, a smaller playing field, less places to pickup or drop packages, less steps to deliver something.
• Because of that, the levels after that can also stay smaller and simpler, and introduce mechanics at a better pace.
• But at the same time, gameplay has improved: players need to keep moving, they need to cooperate more, they still have multiple options for delivery (taking the crane themselves, walking the path, leaving the package for someone else, etc.), but the most boring part (“walking with a package”) has almost completely gone away.
• It gives some more feeling and life to the game. “Zones” are pretty abstract and boring. “Tiny, cute houses that spit out packages” is a lot better. It also gives me more opportunities for the story and the level design. (The houses take up less space, yet look more natural in most environments.)

Conclusion

The last few days I’ve been working very hard on creating the first playable demo (only level 1, for the time being). I created and refined the actual level, I created a tutorial overlay, I created a starting screen where people can assign controllers/keyboards to play with, etc.

As I write this, it’s finally done! The core game loop (select level, loading screen, play level, game over screen) works and contains almost all necessary ingredients. From now on, it’s all about designing the levels, squashing bugs (or just bad systems in the game), and of course (heavily) polishing the game.

Tomorrow, I will put the demo online and make an announcement. I would be more than grateful if you would try the game and give me feedback!