Solveland - Graduation Project

Project Information

Project Description

Solveland is a first-person puzzle game, wherein you have to solve big-scaled puzzles in order to progress further. The goal is to solve puzzles to create new paths and find the exit of this abandoned ancient city.
  • Role: Graduation Project
  • Project Type: Game Project
  • Project duration: ±16 weeks
  • Duties: Project planning, prototyping, High-level planning, agile development with Scrum, tracking tasks, organizing meetings
  • Software used: Unreal Engine, 3Ds Max, Photoshop, Illustrator, Trello, Google Drive Software

Devlogs and playable build link

Core Gameplay Features

My Work

Details about my work

Graduation Project Plan

For my graduation assignment, I wanted to create a small game with a relatively compact system that I could use in different manners. The reason for this is that I can focus on multiple aspects of the project since I also wanted to improve on my level design and Unreal Engine skills. My interest in puzzles helped me find a direction that I could pursue. I started thinking about multiple puzzles and how I could translate a part of that is something interesting. The widely considered world’s best-selling toy came to mind, the Rubik’s Cube. The idea was a first-person version, wherein the player can rotate big chunks of the environment to create a path to the end of a puzzle. The core feature of the game is called Cubes, with this, the player can rotate a single block either to the right or to the left. Based on this core idea, I created 3 more features; Contiguous Cubes, Extended Cubes, and Altered Cubes.
 

Project Planning & Prototyping

I started off by creating a schedule and roadmap of the project. I knew when I had to deliver a product and where I was. The core features were written down and tested with a paper prototype. Those features would still need to be tested in-engine, but the vision was there. I created deadlines every 3 weeks, on the Friday of the deadline I would write a devlog and post it on the itch.io page that I had also created.
For the prototype, I wanted to create the core feature of the game, the cubes feature. I was going to need this system multiple times and I was going to need to make the other features based on this. Therefore, this system needed to function effectively. Meaning, that I wanted to be able to paste this around in the scene and still be functional. I shouldn’t need to add the connected cubes to the system by hand, the system should be able to do that on its own.
 

Map Layout Design

The map layout design started off with a Google Sheets table, showing the difficulties and the different combinations of the features. Once I had that, I transformed that into cells in Photoshop and with those cells, I could make a bubble diagram. This diagram represented the level flow throughout the whole map. This was extremely helpful and it really helped me create the map layout. I started off on paper and once I had a sketch that was satisfying to me, I went to Photoshop and made the map layout in there. The original map layout was way over-scoped, but there was plenty of room for me to down-scope it to a size that was achievable for me.
Based on the map that I made, which shows where puzzles with specific required features had to go and on which difficulty. Once I had a puzzle, I drew the starting position and the end position of the puzzle with the steps of the solution. Then I created the puzzle in Photoshop. Once I had 4 of them, I could combine them and make a level. I recreated the level in Unreal Engine, implemented the rotational pads and the obstacles. At this point, I can fine-tune the puzzles and tweak them if needed.
 

Art Direction

I have done some research on the visual direction. Since the game is about rotating cubes, I thought it would be fitting to go with something cubical as well. I aimed for texture-less assets with flat colors and the details would come from the number of assets. One of the things that I didn’t want, is to have hard edges around the assets.

Project Reflection

Satisfaction with puzzles

Looking back at the end product and knowing that I had to cut some corners during the development, I am still very satisfied with the puzzles, the systems behind the puzzles, and the overall end product. The concept was very fitting for my time frame, my personal goals, and the learning opportunities it gave me.
 

Not enough focus on UX

One of the topics that I could and should have focused more on, is the user experience. At a certain point, I was just creating the puzzles and implementing them in the game. Even though I did have a couple of players playtesting the game, I haven’t spent much time focusing on the UX of the game and how new players are experiencing the game. Looking back at the project, I could have spent more time giving the player more direction. I could have done this by more clearly stating and showing if the player did something right or where the next puzzle is. Furthermore, there are some small mechanics that I could have brought into the game, like a puzzle reset button, an overview board of each puzzle or level, decreased the height of the ruin walls (because they can be blocking the view).
 

Missing SFX and VFX

If the player is making some progress with a puzzle, the game should give some feedback to the player. This can be done with visuals effects and sound effects. This ties in with my previous point, but it would have increased the overall player experience sufficiently. Adding in a dust particle around a rotating cube with a small screen shake would give a much more rewarding feeling. Additionally, adding some sort of click SFX when a cube is being rotated in the right position would add a tremendous amount to the overall experience.