Welcome to the seventh devlog!

Now that the game doesn’t lag anymore – at least, not with my small and basic level 1 terrain – we can start iterating on the design for level 1!

Because great plans always fall apart at the playtesting stage :p

I had made a working prototype of the first level, tried it a few times with different people, and noted the following results:

• Walking is boring. The dropzones (that’s my name for the different package destinations in a level) are too far apart, and because we’re in level 1, players have no faster method of movement.
• Getting onto the platform (connected to the crane) is sometimes too difficult: the physics are too loose, which regularly cause it to bounce around like crazy.
• I need to work on a good delivery timing system: sometimes all the players have nothing to do, while there’s also times were packages are just stacking up and everyone is too busy to do something with it.
• It’s fun to fail, it’s fun to see your friends fail. But it’s not fun if you only keep failing, or if you fail because of something that wasn’t within your control.

 This might make it seem like the first prototype was a gigantic failure, but that’s not true. It works and looks fine, better than expected even, and my playtesters are still happy to try again after I updated. (We’ll see how long that lasts.)

So, how do we solve this?

NOTE: You might be asking: why are you stuck at level 1? Aren’t there many other parts of the game you could already work on? Yes, that is true, so let me explain. I always do a “feasibility test” at the start of a project. I need to know if something is going to work, if it’s going to be fun, what the timeframe is for completing, etc. I need a (somewhat) finished level 1 to test the game idea and improve the fundamental systems before I start making all the other levels/assets/systems. I need a strong foundation to build on. So, for the moment, I’m only implementing features and creating assets for level 1.

Solving the walking speed

I found a rather nice way to solve the first issue! I’ve been thinking about movement speed in the game since day one, because there were some issues:

• I don’t want players to be super fast, because then levels need to be extremely large (which wouldn’t work for several reasons), and vehicles become worthless.
• I don’t want players to be super slow, because moving wouldn’t be fun and the game would feel “wrong”

How did I solve this?

• I created a golden rule for my level design: keep it small and compact.
• I made players move fast by default, but move much slower if they’re holding a package (or anything else – the speed might depend on the weight of the object you’re holding)

This way, you’ll have fast movement most of the time, but slow movement when it matters most – when delivering packages. It requires you to work harder and cooperate more, because you don’t want every player walking their package to the destination individually. At the same time, because levels are very small, they will generally fit on the screen and not bore players with huge walking distances.

After looking at my level design for far too long, I found ways to make it smaller. In the end, I won 2 tiles at the X-axis and 2 tiles at the Y-axis, which means around 40 tiles were removed from the level!

Additionally, I placed the buttons for the crane closer to the center, which means players don’t have to walk a long way to use them.

Solving the physics bounciness

This one wasn’t that exciting. I had already added a “stabilizer” to the platform, so it wouldn’t flip over when a (unrealistically heavy) player or package landed on it. I just needed to add more damping to the rope itself (that holds the platform in the air) and limit the impulses it can give.

As always with game physics: fiddle with all the parameters until they fit well together.

Solving the delivery system

This isn’t really an issue with level 1, but a system I need to work on in general.

At the moment, the delivery system is updated once per second. In that same function, I can do the following:

• Check if there are fewer deliveries than players. If so, there must be a player doing nothing (or at least walking around empty-handed). Add a new delivery!
• Check if there are more deliveries than players. To keep the game flowing and challenging, I allow 1 extra delivery => with 2 players, you can have at most 3 deliveries simultaneously. Anything above that is simply not allowed.
• Calculate a reasonable time for each delivery: find the distance to the nearest player, and find the distance between the pickup zone ( = where the package starts) and the drop zone ( = destination). Now that you now the minimum distance the package must travel, simply divide it by walking speed, and add a certain (rather large) buffer for players screwing up or being inefficient. And now you have the timer for this particular delivery!

These features are still being worked on, but won’t take too long to complete.

(I’ve experimented with using a pathfinding system to procedurally calculate the shortest walkable route between zones. But that was a failure, as the Godot Engine doesn’t really support my use case, and writing it myself will surely slow down game performance. Instead, I’ll probably input these numbers myself for each level. Which is fine, because I can gauge the shortest distance between zones with my own eyes in 5 seconds :p)

Additionally, I thought the following rules would be nice:

• Some packages are “special”. They are extra hard to complete (because of obstacles, or because of a shortened timer, whatever). But if you get them, your profit from them is doubled! I’ll probably use a big star or glow to signal these important deliveries.

I am in doubt, however, about using this in level 1. It would mean even more information to convey to the player, and I don’t want the game to be too intimidating! It could work, but maybe if I just don’t explain it, but use visuals to suggest the importance of the package. (The packages get icons/symbols to show they are somehow special and important, and when you deliver them, you get a large “x2” particle effect that shows that profit was doubled. I think that’ll be enough for most players to get it.)

(This is how special deliveries look at the moment, but they'll surely be improved down the line.)

Is failure fun?

The last issue is really a balancing act. I had some places in the level where, if you slightly mistimed a jump or walked to close to the edge, you’d fall into a black pit and be out of the level for 5 seconds. It’s really not that funny or instructive, so I removed those places.

On the other hand, two of the dropzones can only be reached by walking over a few wooden planks. It takes some skill to not fall off them, but not too much. The failure rate is low, but when it happens, it’s really funny/exciting (especially if someone was holding a REALLY important package).

In the end, I just removed some annoying obstacles, but expanded on the better ones. I made level 1 less hard and less punishing, but more fun and educational, which is a good trade-off in this case.

NOTE: A special remark goes to the issue of “players will do ANYTHING to break your game” I built the level in such a way that two dropzones could only be reached by walking the wooden-plank-obstacle-route. One of my players showed me how wrong I was – by just jumping from a weird angle and actually (barely) making it to the other side.

It’s good to know this: test your own levels for anything players might try, or anything you might consider “stupid” but new players might consider “hey, that seems like the way to do it”. If they actually succeed, that not only breaks your level design, it also teaches them the wrong lessons. (“Well, in level 1 I could just jump to everywhere, let’s try that again every time!)

Conclusion

Level 1 is much better now. It’s smaller, it’s more engaging, it’s less frustrating, it’s more balanced. I’ll probably do another iteration once the whole first “world” is complete, but this is enough for now.

That’s it for the seventh devlog! Next time, I’ll talk a little more about some extra optimizations/decisions I added to my workflow, and why I needed to completely rework the player code.