Light of Alariya
A 3rd person, open-world, puzzle, and exploration game.

Project Details

• Role: Level Designer

• Client: SMU Guildhall Capstone Project

• Platform: PC (Steam / Epic Game Store)

• Tools Used: Unreal Engine 5

• Development Time:  18 weeks

• Team Size: 27

• Playtime (main story): 1-2 hours + (full exploration): 3-4 hours

Description

Players sail across the vast desert dunes of the planet Alariya, seeking forgotten temples. Players must realign the temple's ancient crystals to activate the celestial powers of the gods so they can resurrect her dormant people.

Key Responsibilities

Temple Level Design

White boxing

In the early stages of development, I was responsible for creating block-meshes for all three temples and then replacing them with our mod kit. I collaborated closely with the puzzle/temple and art teams to develop a mod kit that we used all throughout the development process. Our goal was to make something flexible that can adapt to diverse layouts. I also worked alongside the open-world team, who were responsible for making significant changes to the landscape as they were busy creating blocking-out side quests and points of interest that were secondary to the critical path. Although we sometimes got in each other's way, we could communicate any significant changes because we worked in close proximity to each other.

Throughout the game's development, our temples had no natural interior; they were built in a single open landscape. To establish points of interest and landmarks, we utilized data layers and the world partition system in UE5. However, since these points of interest and landmarks often shifted after playtesting milestones, we had to move our temples accordingly.

Layout

Later in the development cycle, each puzzle/ team member took over one temple as their primary responsibility. My responsibility was the temple of Jiach. The temple of Jiach is the first temple for the player on the critical path and where the player is taught the complexity of the main gameplay mechanics.

During development, this temple of Jiach layout underwent numerous iterations and was designed by all three temple/puzzle team designers simultaneously. Initially, we wanted to make the temple "open," where the player could freely travel from the open world into any part of the temple space. Making the temples "open" was one of our biggest mistakes. Through playtesting, we learned that the critical path felt ambiguous to players.

Another mistake was the size of the Temple of Jiach. In the beginning, it was significantly larger than our final result; we quickly realized we needed to rescale the size of the temple. This sped up development and helped us to focus more on refining gameplay and puzzle mechanics to "find the fun."

Gameplay Mechanics

Failed Mechanics

The game's primary levels are the temples, which incorporate parkour and puzzle-style gameplay mechanics to teach players about objectives and puzzle mechanics.

Early on, we decided to develop a secondary gameplay mechanic that expanded upon the protagonist's swinging whip. We agreed on a physics cube where players had to use their whip to drag onto pressure plates. 

Initially, the narrative was that the pressure plates would trigger mechanisms in the temple to restore power. However, the cubes proved cumbersome for players, made it hard to prevent soft gating during playtest sessions, and were tedious for programmers to develop. 

We then considered removing pressure plates due to unreliable physics and the high cost of implementation. We spent a lot of time on this, and it cost us a lot of time early on in the process. We liked the idea initially because it allowed the player to view the space they were in like a spatial puzzle, and it also felt like an extension of the swinging whip the main character used.

Our stakeholders encouraged us to look for new gameplay mechanics. Thankfully, one of our talented designers in the puzzle team pitched a light-emitting system, and after successful playtesting, we pivoted toward that.

Conveyance On Where To Start

As a team, we finally achieved the correct scale, created engaging gameplay with the new light-emitting system, and laid out a linear path for our temples. However, we still faced issues communicating to the players about where they should begin interacting with the light-emitting system in the first chamber of the temple of Jiach. We knew we wanted them to experiment and explore, but not feel overwhelmed and lost. This conveyance problem led to my eureka moment, which helped establish the pacing for each temple.

Gating

At this point in development, we realized how naive we were in our scope. Our scope issues caused us to question what we were creating and whether we could deliver it on time. However, through playtesting and development, we gradually understood and refined our gameplay systems. Our challenge now was communicating these systems effectively to players through our level design.

During the early development of the Temple of Jiach, stakeholders expressed concerns about the difficulty of navigating the temple. We removed some open spaces where players could enter and exit the temple at any point, but we maintained an open environment inside the temple to support the game's narrative.

After conducting playtests, we realized that the temple's open-ended design was still too convoluted for players, making it difficult for them to engage with the light-emitting system. Players tended to move from one room to another without fully exploring one area of the temple, which resulted in little motivation for them to commit to the space.

Gating using light emitting mechanic.

I suggested gating the players until they tested the new abilities that the light-emitting system provided them. Gating would help them focus on smaller parts of the gameplay challenges and build their confidence in the game's systems. When we implemented this, it worked well. We learned that gating encouraged players to concentrate on one challenge at a time, slowing down their progress and giving them a sense of agency in exploring the environment.

Using the light emitters to gate players, we established a guiding level design principle that worked well across all our temples. It allowed players to face one challenge at a time while progressing through each room rather than navigating the entire space simultaneously.

QA & Aesthetics

I had the privilege of contributing to the quality assurance (QA) process towards the end of the development cycle, just before the launch. Working closely with both the programming and design teams, I confidently tested the functionality of autosaves and identified soft locks in our temple and puzzle designs.

While working on QA, I created detailed bug reports, including videos and step-by-step tutorials on how to reproduce each issue. I then uploaded the tutorial to our bug-tracking system and followed up with the programming and temple design teams regarding any game-breaking bugs. Additionally, I addressed aesthetic issues our stakeholders brought up, updated the terrain around each temple, and added small props and decals to improve conveyance on the critical path.

Design Process

As one of the three temple/puzzle design team members, I was tasked with creating the puzzle temple spaces for the game's critical path and our puzzle game mechanics. Our team brainstormed and paper-prototyped various critical paths for each temple, and then we critiqued each other's temple designs, combined what we liked, and threw out what we didn't. 

For brainstorming, we used traditional whiteboards, but mainly Miro, since it allowed us to view each other's critical path ideas and main gameplay mechanics simultaneously.

Team Retrospective

What Went Well

Small Temple / Puzzle Design Team 

• Since our team was small, we could quickly discuss core game mechanics and bounce ideas off each other. We were very agile, which allowed us to communicate effectively and rapidly since we didn't have to speak to dozens of developers simultaneously. We also could iterate on those ideas rapidly. We designed together using Miro and agreed upon a visual design language that we could use to create rough-level design maps of temples.

QA and Checking for Soft Gating Early

• Since our game's critical path relied entirely on puzzles, we needed to test our logic and autosaves for those puzzles as soon as possible. We were able to test them quickly, and when we did, we checked for soft gates and did many iterative passes for aesthetics and other bugs along the way. 

Gating Core Mechanics

• Once we started to gate the player using the light emitter mechanics, the player was allowed to slow down and process one challenge at a time. It encouraged experimentation and exploration in the space they were in. 

What Went Wrong = What could be better

Overscopped

• Overscoping resulted in our game's identity crisis. It took away precious time we could have spent improving gameplay mechanics, bug fixing, and polishing. Most of our overscoping, besides gameplay, was in the scale and openness of the temples. This could have been prevented with a traditional linear path rather than trying to impress stakeholders. 

Poor communication practices and attempting to take shortcuts

• As level designers, we received a Power of Two modkit instead of a Power of Ten. We had to change UE5 grid settings multiple times and didn't receive tileable materials for our planes, which caused issues when our POIs would change and affect the temple's sightlines. We ultimately had to wait for the art team to provide us with the necessary assets to ground level layout, and when they finally did, it sped up development. The lesson learned is to prioritize communication to avoid costly mistakes and delays.

What I Learned = What I will do next time

No More Yes or No Questions

• As an extrovert, I learned not to ask yes or no questions to my introverted teammates but instead open-ended ones. Asking open-ended questions places me in a position of vulnerability. I let go of control and gave it back to my team members. If I ask yes or no questions, my team members don't feel invited to critique my idea but rather have the option of whether they approve of it; open-ended questions provide them with agency to bring up their ideas. 

Share Knowledge Early and Often

• As the designer on the puzzle team who was mainly responsible for creating the block mesh version of our temples, I quickly memorized essential UE5 shortcuts to create WB levels quickly and then shared them with my team. The shortcuts saved us time and improved our efficiency. Sharing knowledge fosters a healthy team dynamic.

Always Keep Gating In Mind

• In the future, I will always incorporate gating techniques when designing levels. This allows me to control the pace and flow of the player's movement through the space and gradually introduce new mechanics and challenges. This approach enables players to focus on one aspect of gameplay at a time, leading to a more purposeful and engaging experience. Additionally, gating allows me to concentrate on both the gameplay systems and layout simultaneously, resulting in a more cohesive and well-structured level.

Gallery

NEXT