What Lurks Beneath

Introduction

What Lurks Beneath is a two-player co-op 3D puzzle game with light platforming playable with both keyboard and controller. The game has the players take on the role of either a small child or a big, burly monster. The child gets lost in this fungal world and the monster helps the child get back home to their world. I worked as level designer for this game and my goal with it was to have a level that could flow easily and be interesting to walk around in. However, it had to be simple and not too broad as it is not a game where you go exploring much. Worked in a team of 18 people over the span of 5 weeks and here is how it went.

The first map sketch made in Miro. Here the idea was to have a very linear level. While sketching I played around with different puzzle pieces such as buttons, levers etc. 

The puzzle items we ended up having is: Buttons(one for the child, one for the monster), weighted scale, punshable vines(works as triggers with timed actions), climbable objects, movable objects.

The blockouts

Here is where the two players start. To tie in the gameplay with the story of the monster wanting to help the child get back home. The monster in the beginning is stuck in vines and the child needs to release the monster by pressing a button, being represented by a mushroom. This works for the story but also as a very quick tutorial about the two characters and gameplay.

After coming out of the first area, comes the next area with their set of puzzles. Still working as a tutorial of how the two characters will work together to progress. Here an early version of a weighted scale was made. With a puzzle that just didn't make sense and also was something I misinterpreted from the project manager. Later on it would be changed to the vision they had and to a better puzzle.

We wanted early in development a puzzle with a crawlspace where you had to split up the two, gaining a split screen and then introduce a new camera. At first I decided for it to be like a cave you would fall into after climbing upwards. It would be a weird journey through a weird world.

A closeup for the blockout inside of the crawlspace. The monster would be able to see the child crawling whilst the child would be forced into a first person perspective.

Overview of the Blockout #1.

The start area remains the same. i didn't feel like it had to be more complicated since it's just the start.

For the second area the puzzles changed a bit. With a bit more for the monster to do, since we felt that the monster needed more things to do. Early I wanted two movable objects. One that served as a tutorial item that wasn't really needed (but could be). And the actual thing needed.

Here it changed a bit more with the positioning of the movable objects. Changed it to be instead just one movable object and making it so the child needed to activate a button(originaly a lever) for the other movable object to appear.

How you access the crawlspace room area has also changed. The game needed to be more linear to fit with the camera system we had in place. It was a stationary camera looking over the players. So having the players going down and needing to change camera would be tricky. So I moved the area upwards and changed the puzzle for getting in there.

Overview of blockout #2.

Blockout #3. I got feedback to change the position for the start area as it made more sense for it to be that way for the camera we have. The crawlspace at this point was becoming a problem as we couldn't agree to have it and not bother with the camera or scrap it. The first person camera system worked but we felt it took away from the rest of the game and we couldn't find another way to implement the crawlspace to other places due to time. The crawlspace room would change to another room completely. The empty platform on the right would become the last area with a portal taking the child home and ending the game.

Here's the start area with assets put in by our level artist. I worked with them putting in assets for the final area I was working on at this point whilst they worked on the new area that got swapped from the crawlspace room.

Second area with assets and changed layout a bit for the mushroom trees and the movable object.

Here's the scale puzzle up close. It took time to make this work as intended. Making it interesting but not too simple.

Here's the new area. It splits into two paths, the new puzzle instead of the crawlspace that we are facing. And to the right the ending room. You would need to go into the area on the left to get the block in the middle room to drop so you could access the ending area.

The new puzzle room instead of the crawlspace made by our level artist. The first person camera got scrapped but our programmers managed to make a smooth working split screen camera as well as a camera that would "face out" objects close to it so they wouldn't be obscuring the view for the players.

The ending room made by me. Here I wanted it to be a combination of most of the puzzles encountered during the game. Here I tried balancing the workload for both child and monster.

Map with a few assets still not in place.

Here's a GIF showing the progress from early development to nearly done.

Final overview of the map.

What I took with me from the project

Making puzzles is hard

The easy part is coming up with a scenario, the hard part is coming up with a scenario that is interesting and excecutable. You will be walking a fine line of making something very easy or too hard. And even when you think that it is obvious for how you would beat it. You don't know until you watch playtesters struggle or simply beat the puzzle in a way you did not intend.

Communication

Having good communication is key, and a set goal that everyone understands and can follow. I learned during this project that it is good to jump in between the different functions in the team to give them more insight than just letting people know during standups or the GDD. Both good things to have during the projects. But it benefits other, for my case the art department, if I can jump in with them and show them whilst I am working so they know what type of assets they need to work on beforehand so it doesn't get piled up in the last minute.

Accessibility

It can be tempting to put in a lot of stuff to make the level packed with stuff. But more often than not, less is more. By trying to build with an approach of "path first, surroundings second". You have it easier to put down things such as interactable objects that won't be obscured for the player.

Using Format