Welcome to the second devlog for “Package Party”!

The first thing I did was experiment with the level layouts. What’s the style? How will the terrain look and function? How can I make the world invite players to try new mechanics and deliver packages in exciting ways?

After some research, I decided on a grid-based low-poly terrain.

Below is a video of one of the first tests:

(NOTE: It’s certainly not the first prototype. There’s already a car and a package. No, the first protype was a mess of grey blocks, which I wisely didn’t screen capture.)

Why did I decide this?

• I really like this look and always wanted to make a game with it. (As a kid, I played games like Rollercoaster Tycoon to death, and I still like grid terrains more than actual smooth/realistic terrains.)
• It allows for precise levels with precise physics. (With this terrain, any surface is either perfectly flat or at an angle of 45 degrees. This makes movement and sliding really predictable, as opposed to a terrain which could have any angle or number of bumps.)
• It fits the whole “package” theme: the packages are boxes, the world is a set of boxes.
• Again, Godot does not have great 3d performance, and this style is easier on the GPU.

How is this level created?

Godot has a node called “GridMap”. The documentation has a good explanation on how to turn 3D models into “tiles”. Once you insert this “MeshLibrary” into the GridMap, you can just paint the level, cell by cell.

In doing so, I realized a few things:

• Painting a level like this is sloooow and unintuitive.
• Performance on GridMaps especially isn’t amazing.
• There’s a lot of “wasted space”. In the video above, there were many cells that you couldn’t (fully) see – because they were behind/underneath something – but which were still rendering and checking collisions.

After more research, I decided to write my own “terrain editor”. It will have tools to raise/lower the terrain equally, or to flatten it, or to create holes/islands wherever necessary. Once I have this, I can optimize performance immensely, by only drawing and colliding with things that are actually visible.

But … creating something like this takes time. As I write this, some of the tools are already working (raising/lowering; creating nice hills and valleys), some are not. The first few levels will probably still contain the “GridMap”, but I hope to switch to my custom terrains before I’ve finished designing the first world.

Camera

Because this game is a couch co-op, with at most 4 players running around the world simultaneously, I couldn’t allow the camera to rotate around the world. The camera angle is simply fixed, while the camera itself moves with the players to keep them (roughly) in the center of the screen.

This allows some optimizations in the terrain: e.g. faces at the back don’t need to be rendered, because you’ll never see them.

But there’s also some drawbacks:

• What if a player stands behind/underneath something? How do we show where this player is (and what his surroundings look like)?
• What if the players spread out too much?

I thought about this a lot and tried various things.

• Minimap: like many games have, a small minimap at the bottom that shows the whole world. Worked “okay”, but I decided against it, because performance was bad, it took up too much screen space, and it didn’t fit with the game vision. The game is about experimenting, finding new ways to deliver packages faster, cooperating even if you're far apart. If you can see the whole level all the time, that aspect is quickly lost.
• Hiding “obstructing objects” => make them transparent: completely hiding them is overkill, but making them transparent works. It’s a little resource intensive, but nothing I’m too worried about at the moment.
• Splitscreen: when players are too far apart, the screen splits. A 4-player splitscreen was out of the question (it’s disorienting and intimidating, and it’s heavy on the PC). But a two-sided splitscreen might just work: the left side is always the left side of the level, the right side always the right side.
• Silhouette see-through: whenever you’re behind something, a silhouette pops up that displays on top of everything. This is really cheap to compute, usually looks great, but you can’t see your surroundings.

For now, I’ve only implemented the splitscreen, which will get its own devlog article later. (For the most part it’s working great.) But the other options (besides the minimap) might all be implemented later and work together to make the game as easy to play as possible.

How terrain influences layout

This style I’ve chosen, and the way the camera works, have a huge influence on level design.

For example: anything at the front of the level needs to be small or low (or you can’t see what you’re doing), while anything at the back looks better if it’s high and big (because it creates a nice backdrop and height difference)

I decided that this was okay. It puts some constraints on the level design, but as an artist I know the golden rule: constraints = creativity :p It simply forces me to think a bit harder about designing levels where every part is visible, but early tests show it’s not a big issue. (Even huge slopes or tall buildings weren’t a big problem, as long as I kept the one or two tiles behind it relatively empty.)

NOTE: Of course, by pulling the camera upwards (and looking at the map at more of a top view than a side view), I can show these areas easily. Which is exactly what I’m doing at the moment.

That’s it for the second devlog!