top of page
Mau Lundell
Technical Designer
About:
Hand of creation is an asymmetrical low-paced 3D puzzle game wherein you create objects with God's Hand of Creation to jump on, hold down buttons and build bridges over the shaky landscape of Limbo.
Details:
Roles:
Gameplay Designer, Level Designer,
Blueprint Scripter
Time:
4 weeks, August - September 2020
Team size:
9 (3 designers, 3 3D artists, 3 Programmers)
Tools:
Unreal Engine 4, Github, Miro, Discord
Workspace:
Online (Futuregames project with communication through Discord)
My Contributions
Gameplay Design
Core Gameplay
Balancing
Level Design
Prototyping
Paper Prototypes
Level Blockout
Gameplay Blockout
Gameplay Iteration
Playtesting
Blueprint Scripting
Placing Objects
Switching Object
Disappearing Platform
Main Mechanic Iteration
Not Creation?
Hand of Creation was during most of the development a game where you move objects around instead of one where you created them.
In the beginning, we wanted the player to move these objects around to build their path forward. So the main focus was to create physics-based puzzles with a lot of freedom.
But Why Change?
Having this open-ended mechanic could have created a very nice gameplay experience if a lot of time could be put into it polishing it. But we did not have the time needed with only 4 weeks of development.
This left us with 0 puzzles that the testers liked and we as designers were happy with. But determined to create a great game we decided to do something very risky; change the core mechanic far into production.
And so, Creation!
After thinking about the concept of God's Hand, we realized that creation was the perfect option. It was efficient because we did not need any additional assets and was easy to code.
It also meant that we as designers could easily design simple puzzle levels because of the simple concept. This made the puzzles feel coherent and fun to the players but still having depth in gameplay.
Finalizing the game
It was definitely a risky move to change core mechanics so far as the end of the second week into development but I definitely think it was the correct decision.
This change in the end made our job as designers a hundred times easier while not giving everyone on the team any extra work hours.
Main Mechanic Iteration
Level Design
Starting with
Paper Prototypes
The process started the moment we solidified the original main mechanic with the use of paper prototypes. Doing so let me think about how the player would think while waiting for an in-game prototype.
I tried to create as many puzzle ideas as possible to find the ones that worked the best, and then iterate upon them.
Paper Prototype
This was the paper prototype of the level.
First Iteration
This was the first version I created in engine
Final Iteration
This one was the one I was happy with, but something was not right. This level really made me accept that the main gameplay was flawed.
Paper Prototype
This was the paper prototype of the level.
1/7
Iteration, Iteration, Iteration
After testing out my designs with the in-game prototype I could easily find the ones I found proposed a good challenge for the players.
I picked the best ones from the bunch and built them up properly in-game. Then I let outside testers play them, I watched them closely and improved on the areas that didn’t hold up to the standards I had set.
A few iterations of a scrapped level, from paper prototype to final (scrapped because of Main mechanic change).
Level 4 Iteration
Evolving with Change
We liked the idea of traversing over pillars from an idea created before the mechanic change since it fit the overall feel of the game. But I had to find another key "Aha!"-moment for the puzzle because of the change.
Thinking about the core of our mechanic, that Objects disappear, the puzzle was built around the idea of placing objects in the correct order.
First Iteration
The first iteration made before mechanic change
Second Iteration
The second iteration made after mechanic change
Final Product
The Final Iteration of the level and the one presented in the game
First Iteration
The first iteration made before mechanic change
1/3
The final Version
I made the level so that usually the player isn’t thinking too much about their object placement the first time they played the level. This made it so they usually get the door shut in their face and need to rethink.
This I found made the players think about the way they placed objects in an interesting way which we found that the testers really enjoyed.
Level Design
Blueprints
I created some smaller blueprints that were needed to help the programmers out during this project.
Placing Objects &
Limit Checker:
I did the basics blueprinting when we decided to prototype the “Place block”-mechanic.
Blueprints
Place
Disappearing Platforms:
I created the disappearing platforms so that its properties could easily be changed in the editor to help us designers build puzzles with public bools.
dissapear
What I'm proud of:
Critical Decision Making:
Because of some team disagreements and bad planning we found ourselves in the position of having to make one of the hardest decisions to make in a project.
I definitely think the decision to change the main mechanic was the correct one since it made the game fun for the players.
But I’ve definitely learned how to identify these problems early on and will be quick to work them out so as to not cause too much problem as production goes on in the future.
Blueprints:
Having to make critical prototypes in times of need was something new to me and I was happy with the quality of them.
Level Design:
This was my first time in a project where I really got to work with an iterative process with my work, and I really felt like I was able to create levels that the players felt were intuitive and fun.
bottom of page