LEVEL DESIGNER
Third Person Co-op
Specifications
-
2.5 weeks fulltime
-
Unreal Engine
-
Blender
-
Collaborated with Level Designer Stefan Groothuis and Animator Jacky Coh
Goals
-
Create an It Takes Two inspired level
-
Focus on cooperation between players with different mechanics in puzzles
Act 2
First puzzle of act 2, player gets introduced to levers that activate things to be able to proceed.
Platforming part between puzzles to create a breathing space between puzzles for players.
Part two of puzzle three. Skill gate, players need to solve part one to be able to proceed
Part one of third puzzle, where Kneedle also unlocks a second needle to use in puzzles
Second puzzle section, players need to pull on a lever to proceed, however this time they need to find a way to the level.
Pre production
Since this was a collaborative project between me, another level designer and an animator, the first thing we did was to sit down and brainstorm several ideas for co-op features. We settled on a needle, which was inspired by the nail feature from the level The Shed in It Takes Two. The other feature that would complete the needle was a thread.
The reason why we didn't want to take both player's mechanics from the game and then just build levels for the features was because there would be a risk of just copying what exists, we just wanted to use the game as an inspiration. However, having the base for one of the mechanics made it so it would be easier to create it in unreal.
To make a clear view over what our scope was and what we wanted to accomplish with this project, we created a backlog. In the backlog we wrote items as user stories saying what the players would be able to do in the game. From these items we created tasks in our scrumboard to be able to complete the item in question. These are tools we have learned in our collaborative game projects, and worked more than perfect in this smaller project too.
With the scrumboard as a tool and daily morning meetings to briefly update each other what we had been working on and what our plan was today, there were no issues with knowing what my other colleagues worked.
My pre production consisted of drawing rough sketches of some concepts for puzzles. The areas I sketched up were not used, however the ideas for the puzzles could be used in any context. This made blocking out the level easier since I had basic puzzle concepts done already.
Sometimes after doing a rough napkin design I refine the overview in a digital art program, such as Photoshop. However, for this project I left the drawn overview in a very rough stage and started blocking in Unreal Engine with the overview as a guideline.
Blockout
When building the first blockout, my mindset was to use Kishotenketsu as the level flow structure.
The first area, Ki, was used as an onboarding, to introduced the mechanics both players share and the individual ones.
The second area, Sho, was used to make the players get comfortable with the mechanics and features.
In the third area, Ten, the puzzles were made more complicated, to let the players prove that they have understood and can use the mechanics comfortably in any situation.
The last area, Ketsu, would wrap up the experience and let the players breathe and relax when finishing.
A bit in I realized that this level flow and how I had structured the areas so specifically did not really fit the kind of game we were trying to make. I focused too much on trying to make the players interact in puzzles all the time, the level ended up being centered around only puzzles and that there was no room to relax and just platform. The best thing to do in this situation was to scrap my blockout and try again.
Scrapping my blockouts was a good choice since it gave me a better idea over how I wanted the level to flow, and instead of using Kishotenketsu as a level flow structure, we decided to use a simple three act structure instead.
Brainstorming with my colleagues for new ideas, we settled on a child dreaming about a birthday party, which meant less limitation on how the world had to be connected and could almost float in a void and it would still make sense in this context. Since the setting of the level was based on a child's dream it made a lot of sense to use toys as different platforms and obstacles.
During the working process I struggled a lot with making sure both players got to interact with the world equally as much. That is why the balloon was made, it could both be swung from it and popped by a needle. This meant both players could interact with it, making gameplay more interesting.
Whitebox
Eventually in the process gameplay features started to come in and I could start building and testing the mechanics at the same time. I spent a lot of time tweaking distances between platforms together with the features.
Since I was the one playtesting a lot it made reporting various bugs to my fellow level designer a daily task, however, it was also important to keep in mind how the bugs could be avoided from a level design perspective
A thing we wanted in the level was for the players to experience some sort of progress besides getting closer to their main goal. This was something we had thought about earlier in the process but struggled to fit in. Since Kneedle, with their ability to throw needles, usually was a bit more passive during gameplay, we decided that they would unlock a second needle. This enabled me to create more complex puzzles, but also create a skill gate to show progess.
Building process of the start
Building process of the whole level
Modeling meshes in Blender
We wanted toy trains going on a rail in the game the Brio train toys were a perfect reference to use when modeling the train tracks. The sock was modeled for as a needle anchor, since our base idea was that needles could get stuck in softer materials. The balloon, gift, dresser, needle and train set were also modeled by me.
.jpg)
.jpg)
Conclusion
Starting this project I knew it would be a challenge making a level designed for multiplayer. However, that was exactly what I wanted, a challenge, to do something I had not gotten the opportunity to do during my two years at The Game Assembly.
The biggest struggle was to make sure both players had equally as much fun, so it would not get in a situation where one player solved all puzzles while the other one would just stand and watch. That is a part I'm not completely satisfied with yet. A type of puzzle I would have wanted to implement is where one player supports the other while traversing, and then doing the opposite by unlocking a new path that only the second player can go.
Apart from that I am content with the effort and love I put in this project. I got to explore the puzzle side of level design which was something I enjoyed a lot.