It was time to start building: I was happy with my movement and had quite a few level chunks to work with, so I started building one of three planned areas: The Catacombs.

They're planned to be exactly as we know them: cramped, mysterious, and maze-like. These characteristics were considered heavily in my design.

The Catacombs are not the player's first experience with the game. However, since the game is planned to be open-world, it's possible the player has not yet been exposed to certain concepts, like breaking wooden walls. So, I wanted to have a dramatic entrance that illustrates this (note that I have not yet built the lighting):

Here's an applied and tweaked version of the chunk you might have seen in the previous post. Here, the player is forced to learn about wall jumping if they haven't already (this will be useful if I release The Catacombs as a standalone demo). If they don't wall jump correctly, then they'll learn about the water (which pushes them back). I have plans for players to be able to use the water to their advantage in other areas.

Here's an overhead view of the "turbine" section you might have also seen in my last post. The player enters through the duct at the top, and must navigate counter-clockwise until they can get to the duct on the right.

So in my previous post, I mentioned that I could begin prototyping movement and start designing level "chunks". I'm just calling small bits of a level that involve a particular idea or challenge that.

Part of why I started working on this project was to work on my level design skills (I usually focus more on the programming side of things). So, I grabbed a stack of index cards and started scribbling. Here are a few:

These by no means represent what actual gameplay will be like, but are merely ideas.

I admit that coming up with a huge world composed of level chunks using only the mechanics I had in place from prototyping (wall riding and jumping, bounce pads) had proven difficult. So, I added some more easy-to-implement mechanics such as flowing water and platforms that topple, and designed more chunks.

I've made sure not to get too carried away with this, since I don't want too massive of a world or create a larger demand for graphical elements, since this is a solo project and I have other projects already underway.

Keeping it detailed just enough to get everything that's happening in the chunk was the goal for these. I wanted to leave room for change and only illustrate a basic idea of what type of "gameplay moment" the player would be experiencing.

Marbelous at its current stage is set to be a collect-a-thon platformer that rewards players for exploring and thinking outside the box. It's heavily inspired by the old Marble Blast games and Banjo-Kazooie.

I wanted movement in Marbelous to be a little bit more stiff than in games like Marble Blast, only because I wanted players to be very deliberate with their movement. As a result, I predicted that players wouldn't be holding down the W key all the time, and instead holding it down only when they wanted to gain a lot of speed (uncapped speed was another feature I wanted).  However, aside from this deliberate "stiffness" I also wanted movement to be fun and expressive, which brings me to another feature I was dead-set on having: wall jumping!

I also added the ability to brake, allowing players to slow their momentum at high speeds.

With the previous in mind, I started to prototype movement in Unity3D (where I would build the rest of the project).

Getting a ball to move and jump how I wanted was easy. However, what I wanted was to be able to jump based on collision normals instead of just the ground, or even just one wall/normal. My goal was for the player's jumps to be divided among each collision normal for that frame. So, I needed to keep track of every collision the player is experiencing before it jumps.

I couldn't do this by getting each normal when it jumps, since separate collision events aren't easy to read from outside of the collision event methods. So, every time the player has a new collision, I'm storing the new normal in a list from inside OnCollisionEnter() (as long as it's not a duplicate) and clearing it at the end of FixedUpdate(). Doing this would also solve the issue of jumping twice off of one surface, if that surface was comprised of two different colliders.

An issue I ran into with this, however, is that floats aren't extremely accurate since they lack the precision that doubles have, so in the code I'm rounding off my calculations before checking for duplicates.

This isn't very pretty, but I'm not concerned with pre-optimizing the code in the prototyping phase.

This allowed me to begin perfecting my movement and ensure that movement feels great before continuing on. Afterwards, I could start prototyping what I'm calling level "chunks"—small, low-effort parts of a level that revolve around a particular idea or exercise.