Posted October 17, 2019 by Pandaqi
#godot #game design #physics
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: 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:
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)
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:
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.
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:
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!