Welcome to the tenth devlog!

As I am playing and testing the game even more, I keep finding small ways to make the delivery system more fun to use.

Delivery Pending

For example: when you deliver a package, it doesn’t mark the delivery as a success immediately. Instead, a timer pops up, that tells you the delivery is pending. If the package is STILL at the destination after three seconds, the delivery is officially a success!

This system works really well:

• You need to think a little about where you put the packages, because you don’t want them to fall off within those three seconds.
• There’s some REALLY tense moments as you see your package wobble, fall over, and barely stay on the zone for the three seconds.
• It’s fair and balanced. (If I made the pending period 5 or 10 seconds, it’d be annoying. If I made the pending period shorter, it’d be worthless, because even badly dropped packages can stay on the zone for 0.5 seconds.)

(It’s been in the game since day 1, so that’s why I hadn’t mentioned it before.)

There is, however, a problem: what if the delivery timer runs out as the delivery is pending? That feels unfair. You made the delivery on time, if only you had 1 extra second, you’d have scored the full points! The package was right there!

How do we fix this? I saw two options:

• If a delivery is finished, but the package is pending, simply mark it as a success.
• If a package is pending, temporarily pause the delivery timer.

I chose option two: it’s easier to implement and doesn’t allow any “cheating” (by making a package hit the zone at the last second, which will be marked as a success anyway, because the delivery was pending when the order ran out of time).

In the video below (from a different level, but the idea is the same), you can see how the package is "pending" once I've dropped it on the correct zone.

Our perception of time

Okay, that heading might give you the impression that I’m going to give a philosophical talk about time, but no worries, I just want to talk about the delivery timers.

Deliveries all have different timers. An “easy” delivery, like one that has a short distance, will have a short timer. A “hard” delivery, like one where you need to make some difficult jumps, will get a longer timer.

However, if I start the timer for each delivery as full bar (100% width), this will become confusing very quickly. For delivery X, 100% means 15 seconds. But for delivery Y, the same 100% means 90 seconds!

Players want a constant and consistent perception of time in a game.

The first thing I did, was set a maximum time on deliveries, and instantiate new deliveries with the proper width. (The current maximum is 90 seconds, so a delivery that has a timer of 90 will start with a full bar, but one with a timer of 30 seconds will start with the bar only filled 1/3.)

The second thing I did, was divide the timer into fixed segments.

• Once the timer is calculated, it is rounded upwards to the nearest multiple of 15. 
• The delivery interface also has the bar divided into segments. (Six, to be exact, because 6 * 15 = 90, which is our max length)

Now players can quickly see the segment a timer is currently in, and have a good estimate on how much time is left. (I still need to make it look better, of course. But so far, playtesting has shown that this is an intuitive system that everyone can work with.)

NOTE: I explained the calculations that determine the timer for a delivery in Devlog #7, in case you want to know.

NOTE: I also decided to fully support the “special delivery” system. A special delivery will glow purple, get extra time (based on how difficult I think it is), and extra reward if you make it.

Falling off the field

You can’t “die” in this game. But, you can fall off the field, which is for most players akin to dying. So I’ll use the same terminology, because it’s shorter and easier.

You die if:

• Your player goes outside of the level bounds. (Normally, this shouldn’t be possible, unless you REALLY try. But I programmed it just in case.)
• Your player falls below ground level. (This occurs very often, as you can fall into holes, off cliffs, etc.)

What happens if you die? Well, you should get some sort of penalty, but you should also return to the game pretty quickly (it’s still a fast-paced couch co-op where levels only last a few minutes).

Eventually, I decided on the following system:

• Throughout the level, I manually place “spawn points”  (When the game starts, players start at these points. Usually, they will be close to the pickup zones, but they don’t have to be.)
• When you die, you reset to the nearest spawn point. (My previous system reset you to headquarters, but people started using that as a cheat, because you could “teleport” to the other side of the map.)
• A timer is displayed, at the location where you will reappear, that counts down from three seconds. (My first guess was at five seconds, but that kept you out of the game for too long.)
• Additionally, right when you die, there’s a penalty to your score: “-30 points” Without this penalty, players can still use the death system if they want to move somewhere quickly. But now, if they lose 30 points every time, they need to think twice.
• If you were holding a package, you’re allowed to keep the package. (Losing the package was WAY too harsh: you got -100 points, instead of the potential 100-200 reward for delivering it. And in later levels, packages will consist of multiple components, which means it might take a full minute to combine a package and actually deliver it. Losing all of that because of a single misstep is just frustrating.)

Again, the video below is from a different level, as was stupid enough to film these things for the wrong level. But the idea is exactly the same.

I want to note that I’m not against “cheating” the system. I want players to experiment, to try things, to think they have found a shortcut or loophole. Even with the system above, there might be situations where dying on purpose is far better than any other option. I want to keep it that way – there just needs to be a proper balance.

Conclusion

With all these systems into place, we’re nearing a fully playable level 1. Just a reminder of what the actual level 1 looks like:

These are the last items on the to-do list (for level 1):

• Create level surroundings. (Now it’s just solid colors, as if the level was floating in space, and it doesn’t look nice.)
• Make sure the level is fun for all player counts. (I still need to support a third and fourth player, and I need to think about a good solo play system.)
• Finalize the physics (and look) on the pressure buttons and construction crane.
• Iterate on the look/functionality of the dropzones and pickup zones.
• More work on the campaign system

The next devlogs will talk about these in any order I see fit. (I usually do many things simultaneously, as all the systems influence or depend on each other. But that’s quite chaotic to read in a devlog, so I try to make a cohesive story for each devlog that focuses on a single system/mechanism.)