Making TESSELATE - Part 1

01//a new hope

Erickson's prototype consisted of four main elements:

1. The Player
2. The Cube
3. The Receiver
4. The Door

The Player must Place the Cube into the Receiver to Activate the Door.

Good, clean, easily modifiable code.

if (CUBE == RED)
ACTIVATE the DOOR

The way it worked was that it asked for a specific RED tag. I expanded the code for it to accept TAGS defined by the designer, in the editor. (jargon)

Basically, I added three more colors.

So now we have Red, Yellow, Blue, and Green doors, cubes, and receivers. With these building blocks, it helped me visualize what the level could possibly be. I could imagine the journey that the player has to take through the level. What do they have to think about? How do they learn the mechanics?

I am the Player. What can I do?
I can pick up a Cube. What can the Cube do?
I can place the Cubes on these Receivers. What does that do?
It opens Doors.. to more Cubes.

The key to creating the level flow is to order the movements of the elements in the stage. The Player, the Cube, the Receiver, and the Doors all serve as objects for the narrative. The goal of the level designer therefore is to create a conversation, where the movement and actions of the Player cause other elements to react, pushing the Player forward. Walls acted as blockers to lead the player to different areas, separate the interactions, the encounters.

Scenario Alpha:
I can see a Red Door.
To my right, a Red Cube.
To my left, a Red Receiver.
I place the Red Cube into the Red Receiver, opening the Red Door.

Scenario Beta:
I can see a Blue Cube behind a Red Door.
To my right, a Blue Receiver and a Blue Door.
To my left, a Red Cube and a Red Receiver.
I place the Red Cube into the Red Receiver, opening the Red Door.
I can now take the Blue Cube and place it into the Blue Receiver, opening the Blue Door.

A simple puzzle like that (if you can call it a puzzle) contains all of the tropes we need to create the level. The conversation between the elements gets more complicated as the level progresses. Especially when you add more colors.

Something I believe is very important for the narrative to be dynamic is for the elements to work against the Player. The Player not only has to feel in control of the progression, they must also feel that they are at the mercy of it.

Sometimes, I'd make the Player -deactivate- a door. Closing off their access to certain areas if they wanted to progress. They'd have to give something up to move forward.

I'd require the use of the same Cube for different Receivers. This forces the Player to be acutely conscious of the placement of elements in the scene. They'd have to know where to go back to, to open the doors that they had to close.




















In the top right area of the map, I wanted to twist the door mechanic and came up with a bridge mechanic. It changes the dialogue, the words that the Player would use to understand the puzzle. Bridges wouldn't block the way, they now provide the passage.

Certain Platforms can only be accessed by Bridges, the Player would have to maneuver around and switch the places of cubes to get the correct order of activation. I had to expand the code again.

Previously, the door would Disappear when a cube was placed into a receiver.
But now I needed the door to Appear when a cube was placed into a receiver.

if(CUBETAG == YOURTAG)
SOMETHING the SOMETHING

I expanded the code to accept behaviors other than simply deactivating. Now it would do whatever the programmer or designer wanted it to do when a Cube entered a Receiver.

From a code that would activate a door.
To a code that would do something to something whenever something was placed into something.

Now SOMETHING could mean Deactivating, Displacing, Rotating, Anything.
The Doors could be replaced by any object and the Cubes could also be any object.
Now when a Player places a Cube into a Receiver a -Bridge- could -Appear-.

Bridges, Doors, Cubes, Walls, Platforms, Receivers. I had everything I needed.

I used Photoshop to erase the negative space in the concept art.

And placed the elements around the level.

Below is a video runthrough of the stage with all the working parts. This served as a proof of concept and gave us an idea of how long it would take to complete the level. In my runthrough, it took me 12 minutes with minor mistakes, but that is because I already knew where and what everything did. The Player could potentially spend tens of minutes trying to figure out what receiver activated which door.

At this point, the level was technically complete. We needed the Player to get from Point A to Point B after having gone through some puzzles. All of the gameplay was in place and the level worked, which is what we needed.

_________________________________________

I'm trying to bring to light some of the processes we went through to develop TESSELATE. I realize now that each of the levels kind of has its own story behind it. Level 04 actually took the longest because it was in making the level that we developed the approaches and techniques that sped up design for the rest of the stages.

This post got a bit more technical than the last, it even touched on some of my game design philosophy. I'm trying to avoid jargon and things that don't necessarily have to be explained, but still talk about the complexity of the problem and the mindset it took to overcome it.

If you've made it this far...

Thank you! I'm really really trying to force myself to write this all down, hahaha. If you're reading this, thank you so much for all the support! The next post will be all about scenery and presentation with... MORE PICTURES!!!
_________________________________________

to be continued...