Welcome to the fourth devlog of “Package Party”!

Last devlog, I explained (in broad strokes) the delivery system and the corresponding interface. I also stressed that this was the backbone of the game. That’s why I took my time to playtest this and optimize it, before I began adding more content.

And that’s when I hit the “Problem of Packages” (or “Package Paradox” – as long as it’s an alliteration, I’m cool with it.)

The Problem

The Problem: In a frantic, stressful couch co-op game … who’s going to carefully read the labels and instructions on the packages?

One time, there happened to be TWO packages that had the same destination. My players were completely baffled from that point onward. They couldn’t really see which package was which, it somehow felt “unnatural”, and it really threw the game off balance.

Why is that? I asked some questions, playtested some more, and got the following results:

• People are always seeking patterns and are very confused when something doesn’t fit their pattern. In this case, players had (subconsciously) made the pattern that every package needed to go to a different zone. I mean, why have different destinations, if multiple packages can go to the same one?!
• Because the colors were the same, the interface just didn’t work and people couldn’t read it quickly enough. In a slow, strategic game this would be fine. Not in a game like this.
• The same was true for icons: if there were two packages that contained “tools”, but they needed to go to different destinations … how did players know which one to pick and where to drop it?
• Lastly, the levels are generally designed to make every destination equally “hard” to get to (in its own way). If you get three packages in a row for the same destination, that saves you A LOT of work, and throws the game off-balance.

As I stated earlier in development: restrictions = creativity. I also want to add: simplicity = GOOD.

So I created a two new game rules that govern the whole delivery system …

Package Uniqueness: there can NEVER be two deliveries with identical contents. (Of course, once a delivery is finished, it’s removed from the list, so that “type” can appear again.)

Destination Uniqueness: there can NEVER be two deliveries with identical destinations. (Again, once a delivery is done, the destination becomes “available” again for future deliveries.)

This works wonders. The next playthrough, there was absolutely no confusion about the packages, their destinations, how much time a delivery had left, etc.

(It also simplifies the code, but I won’t get into that here.)

Essentially, by removing a large part of the “possibility space”, the game became much better and more fun. Sometimes, freedom is actually not what the players want :p

 (This is mostly a random picture to break up the text. At the top left, you can see two deliveries that have a different TYPE and COLOR. This makes it easy to tell them apart. A bit of a shame that the packages landed right on top of each other, as you can see at the bottom :p)

The Second Problem

So, dropping random packages (which are cubes with a texture at this point) is easy. Allowing the player to recognize them and pick them up is easy. Making the player hold the packages and drop them somewhere else is the hard part!

Before we get into that, some extra Godot explanation:

• The player is a KinematicBody, with an Area in front of it. The area detects if anything is within a certain distance in front of the player. If it finds something, and it’s a package, it becomes available for grabbing.
• The player rotates to face the direction your Joystick is pointing. To make this look more realistic, I use a Quaternion to interpolate between the player’s current rotation and the desired one. Once this direction is set, the player just moves in that direction at a predefined speed.
• Underneath the player is a RayCast, pointing downward. This detects if the player is standing on ground. If so, it is allowed to jump. Jumping just means setting the Y-velocity to a certain value.
• The packages are RigidBodies with no custom logic. They collide, bounce around, slide, etc. like they would in real life.

That last sentence is important: the packages behave realistically. This is desirable, and works very well 99% of the time, but there are some issues.

• When the player is holding the package, we want to disable these physics. We don’t want the package to fall down, or collide with the player and stop its movement, etc.
• But if we disable physics … then the package can just go through walls, as long as you’re holding it.
• And then when we drop it, we want to enable physics again, but the package is so close to the player that it will collide and do nothing!

I was completely frustrated with this for a good few hours. I thought: how difficult can it be?! Just apply an impulse to throw that thing away! It took me very long to realize the points I described above.

NOTE: Below is a video I recorded much later than when I wrote this devlog. If you're reading these devlogs in order: spoiler alert! I won't be talking about this particular level and the systems it uses until like devlog #20 or something. I'm sorry, I always forget to take regular videos of my development progress. Anyway, it shows how a player can pick up and drop a package. But most importantly: it shows that packages have no collision shape, and thus move through everything.

This is how I fixed the issue in code:

• When you pick up a package, its collision box is completely disabled. It teleports to your hands, resets all its properties (such as rotation and velocity).
• From that moment on, it keeps teleporting to your hands, whatever you do (jump, rotate, run, etc.)
• Important: I calculate the size of the package, and the size of the player, and use this to set the minimum safe distance. As long as the package is further away than that, it will not collide with the player when you throw it. That … simply worked.
• When you drop the package, it enables the collision box, and resets the properties again.
  
  • (Important: bodies aren’t meant to be teleported. The physics engine can’t handle that. So, when you teleport it, it interprets that as if the body was moving with that velocity. If you press the DROP PACKAGE button, the package will fly off in a completely different direction, because it thinks it has a different velocity. The lesson: reset those properties, or don’t teleport bodies.)
• Finally, it applies an impulse to throw it away. The longer you hold the button, the further you can throw it.

Yes, packages can go through other objects when you’re holding them. Is this a problem? I don’t know. At the moment it’s a great benefit, actually. It makes all the actions very fluid and responsive.

In the future I might add an extra CollisionShape to the player if you’re holding a package. If the player has the collision shape, and not the package, there’s no problems, and we get realistic physics. The real question is: do we want completely realistic physics in this game? :p

That’s it for the fourth devlog!