It’s a little tough to pin down when exactly we started work on Level Squared, but it’s probably around about this time last year.
So, to celebrate, here’s a little selection of pics and highlights showing how the game has developed over time
First prototype:
First announcement:
We're excited to announce our redesigned game will be LEVEL SQUARED. Please follow for our progress as we get closer to PAX! #lvl2game 🤩 pic.twitter.com/7GIvKwYmKS
So there you have a very quick overview of how Level Squared has looked and changed over the last 12 months. We’ve put in a heck of a lot of work to get to where we are now, and we’ve had a lot of help from a lot of people as well.
Looking forward to finding out what the next 12 months brings!
This week I thought I’d go into a bit more depth on the level and mechanic design that I’ve been doing over the last few weeks. This will be exploring in-depth the design ideas behind one of the new levels for Level Squared, the problems I’ve been looking to solve with the design, and the issues that I’ve been designing around before sending it off for play testing.
The level I’m going to be looking into will be Level 4.2 of the new progression. (You might remember from last week that there are five sub-levels within each larger area, so this is the second level within area 4).
This level is the second level where the player has gained the ability to cast projections themselves. They have been run through the mechanics of projecting, and had a chance to cast a few projections themselves. The idea behind this level is to give the player a lot more projections to play around with, the ability to project the same objects a number of times, and to get to know the limitations of projecting a little better.
But at the same time, they have not yet learned the ability to undo projections. This is a bit of a barrier. It means that I can’t make any of the projections vital or too precise. There’s a good chance that the player will project a block up against a wall where they won’t be able to interact with the block any further. If that block is required to proceed, then the level is blocked and the player would need to restart. I need to avoid that at all costs.
So those are our parameters. And here’s a view of the entire level:
The player will spawn at the bottom left, and exit through the green square at the top right.
You can see that the first thing that the player will encounter are the three yellow blocks that are blocking any further progress. The player has already encountered these types of blocks in previous levels, so knows that they are projectable. From the central platform, every projection angle will result in a successful projection. However, it is possible for the player to move to an extent that the projection is not possible. In this case the projection lines will turn red. As shown below:
(Eventually the camera will zoom out to show where the projected block will land. It’s just not up and running yet.)
Once the player jumps up to the next level, we can see that it is possible for the player to block their way forward with one of their projections. However, there is plenty of clear space beyond to ensure that the player can project again to clear the block out of the way. In addition, the player can climb to either the right or left side of the level, so even if they block one side and don’t think to project the block away, they can still climb on the opposite side.
And you can see that this is repeated the whole way up the level. The player always has multiple paths forward.
Another consideration is the use of the blocks as stairs.
The player can cast the yellow blocks into a set of stairs that they can use to leap up to the next area:
However, I have made sure that all of the jumps within the level are able to be completed by the character without requiring that the blocks be used as steps. If the player projects the blocks too far away, or into the wrong position, they will definitely still be able to progress. And if they cast the blocks into stairs, they can use those to jump up and feel very clever for solving the stair puzzle!
Finally here’s a video of me playing through the level in a pretty inefficient manner, making sure I can’t break or block anything and still make it all the way through – enjoy!
Following on from last week’s Level Building blog, this week I’m going to go a bit further into specific puzzle design and introducing new mechanics to the player.
A poor joke.
One of the new mechanics that we are seeking to introduce to the player is passive projection. In this, we have a block within the world that is able to cast a projection, and that is operated by the player stepping onto a button.
It looks like this:
We’ve based this idea of the way that players are introduced to portals in Portal. The gun is placed in a fixed position and sends out portals to set locations, allowing the player to understand what is going on, without giving them too much power too early.
So what I’m trying to teach the player in this particular puzzle is that standing on a button will cause the projector to fire and create a projection of the yellow square. And that the projection will be completed when the player steps off the button.
The first version looked like this:
The button is located behind the projector, and is directly in front of the player upon them spawning into the scene. However, in this setup, the projection of the yellow block ended up being cast outside the right hand side of the screen, and this meant that the player wouldn’t know what their action was doing. The fact that the yellow block is moved to the new location is one of the core principals of projection, and it is important that the player realises that this is what is happening.
So I moved the button to be between the projector and the block. But this caused problems at first, because the player could get caught in the projection:
So I adjusted the level so that the button was lowered further below the projector until the player was out of the line of effect.
No the player can see that the button has to be pressed to continue (having already learned that in earlier levels), and when they step onto the button, the projector fires, casting the yellow block to a new location. The player is in a position to see where the new yellow block is placed. And the player learns what these blue blocks do.
That’s a very simple run through of introducing that mechanic to the player. I’m building levels in sequence at the moment that will gradually introduce new mechanics to the player, over a five level series as follows:
Introduce a new mechanic in a simple version
vary the operation of that mechanic so that the player learns how it works.
Introduce a secondary mechanic.
Show a couple of puzzles with both mechanics combined
Finally, a larger challenge level where the new mechanics are used in different ways that require the player to think a bit harder about how to progress.
And then I just have to do that around six to ten times for all of the various mechanics and puzzles that we want to use. and by that point, we should have a pretty reasonable game length!
Hey folks. Development of Level Squared continues apace! The pipeline has been in full force and we’ve been pumping out new levels at a good rate. We’re in that really good place where we’re making some good progress, we’re making some good content, and it looks good and works well, and we haven’t shown it to anyone yet, so we can still operate under the assumption that it’s good!
After writing last week’s post, I felt like going a bit more in depth on the specific way I go about designing levels and then building them in Unity, to give a bit more insight into that part of the process.
First thing I start with is an overall purpose for the level. At the moment I’m still working on levels from near the start of the game, so usually the idea is to either introduce a new mechanic, or iterate on that mechanic to give the player an idea of what it can do.
So – here’s the design document entry for a level I was working on last night:
The purpose of this level is to introduce the player to the concept of projecting physics blocks – blocks that will react to gravity and fall to the ground rather than remain wherever they are projected to. It is also using Passive Projectors – blocks that can project other blocks and are operated by the player jumping onto a button. These were introduced one level earlier, so are still quite new to the player.
Usually, the first thing I do is sketch up an approximation of what I think will work. This doesn’t always end up looking like the final level, but it helps to get an idea of my starting point, and to get an idea of what will fit within the level, and what the flow of interactions will end up looking like. Now, I didn’t do that in this case, but as a general guide for how useful those sketches are here’s one for a later level:
It’s fine, I totally know what all this means…
The reason I didn’t do a sketch in this case what because I had already made a prototype version of this level earlier, so I already had an idea of the mechanics that I wanted to use. I’d made this a few weeks earlier before we had everything set up and ready to go with the level building pipeline, so it looks a bit different to the current levels.
This prototype doesn’t use the basic layout that our levels are built on, nor does it make use of many of the prefabs that we are now using to build levels. However, it was useful for me to play around with the mechanics and get an idea of how they worked and what was required to get them to work properly. For example, I learned that you need to raise physics blocks into the air when projecting them, in order to drop them onto a button. If everything is laid out in a line, then the blocks are projected inside the buttons and everything fails.
Then once I have these basic concepts worked out in my head/on paper/wherever I jump into Unity and build out the level, using a method I call ‘trial and error’. And I recorded myself building a level last night, which you can watch below (I sped it up – a lot, I am nowhere near this fast don’t worry).
Things you may or may not notice in this video:
I forgot to turn the colliders on in the first playthrough – I do this Every. Single. Level.
Buttons and moving walls don’t really work properly in this video – these will get fixed up in the programming pass later on.
I do a lot of drawing in blocks then erasing them without testing. I’m kinda just freestyling this whole design, so I get halfway through trying something out then change my mind. There’s also things I already know won’t work. For example, the player needs a certain amount of head room for jumps to work. I know how big this is, so if I notice I’ve blocked it, I go back and try again.
One thing I’m trying to balance is having enough open space within the level with having enough black space for the art design. This is a tough thing to balance and I often second guess what’s right or wrong.
So there you have it, that’s the method that I use to create our first draft levels. I’m trying to get around five of these done each week so that we have a big ol’ bunch of them to test in a few weeks.
Next week I’ll go into a bit more detail on how I think about introducing mechanics, and how I try to guide the player through what needs doing and what happens as a result.
