The Dungeon Solves Itself | RLIZA’s blog

type

status

date

slug

summary

Design Background

The theme for this GMTK game jam was RoleReverse, meaning role reversal. Inspired by another project within our team at the time and the "Portal" series, we decided to set the portal itself as the controlled object. To rescue the hero who accidentally fell into the dungeon, players need to control the portal through various obstacles, collect the indolent hero's equipment along the way, reach his side, and teleport him out of the dungeon! In the end, we completed a platformer game with dragging as the basic operation, and I served as one of the designers of this game.

Design Approach

Control Method

We first needed to establish the control method after deciding to use the portal as the movable object. We wanted to present the object's motional characteristics in an intuitive way, making it both interesting and skillful. Conventional button controls require players to maintain constant input, making it difficult to focus on planning their next move. Additionally, we wanted to differentiate ourselves from the straight-line shooting portal method in the "Portal" series. Therefore, we decided to adopt a drag-and-release control method to demonstrate the portal's inertia and movable properties. This approach discretizes the movement operation, making players more attentive to the results of each action and the resultant risks—after dragging, the player cannot drag the portal again until it stops moving.

Gameplay Essence

After this, we needed to consider how to embody the fun of role reversal truly. Did reversing the active-passive relationship between the hero and the portal create an essential difference in gameplay? How could we showcase the unique enjoyment of having the portal as the controlled character? This was the biggest challenge in the design. With these questions in mind, we decided to first focus on the design of level elements to see if we could find some new inspiration.

Level Design

We first established several principles or goals for level design: teaching the basic 3Cs (i.e., Camera, Control, Character), following the RLD principle (i.e., Rational Level Design), and gradually introducing advanced techniques.

Basic 3Cs

To help players gradually become familiar with the drag operation, we designed some level elements to assist players in gradually understanding the 3Cs.

For example, in the tutorial chapter, we introduced black normal bricks to help players learn basic jumping operations and gain a general understanding of parameters such as maximum jump height and longest distance. Additionally, we added a panoramic camera, allowing players to browse the level map. As a result, players' learning of the basic 3Cs begins in the tutorial chapter and continues throughout all levels.

RLD and Level Elements

Through RLD, we aim to ensure that players can understand the function of each level element as much as possible, and guarantee that we can design and implement different level experiences. The specific method is to list all the level elements that appear in the game, and then mark the elements used in each level, which allows us to observe and estimate the approximate difficulty and complexity of each level, you can see details as illustrated in the table below.

LevelID

0-1

0-2

0-3

1-1

1-2

1-3

2-1

2-2

2-3

3-1

3-2

3-3

3-4

black normal brick

√

wooden case

ㅤ

√

ㅤ

√

white sticky brick

ㅤ

√

ㅤ

√

ㅤ

√

venom pool

ㅤ

√

ㅤ

√

ㅤ

√

black moving platform

ㅤ

√

ㅤ

√

ㅤ

white moving platform

ㅤ

√

ㅤ

√

ㅤ

√

spring

ㅤ

√

ㅤ

√

wooden door

ㅤ

√

ㅤ

√

button

ㅤ

√

ㅤ

√

item portal

ㅤ

√

In the first chapter, to demonstrate the benefits and risks of each drag operation, in addition to the black normal bricks, we also designed white sticky bricks that allow the portal to adhere to them. We introduced venom pools as a risk (falling into the acid will restart the level, serving as a negative feedback mechanism). This creates a climbing experience for players each time they use sticky bricks to cross over the pool, alternating between tension and relaxation until reaching the endpoint.

Create an experience similar to climbing.

After this, players understand that black corresponds to normal bricks while white corresponds to sticky bricks. We then introduced black moving platforms and white moving platforms, corresponding to non-sticky and sticky respectively. We use the difference in their stickiness to emphasize the inertia that exists after the portal is dragged - the portal will stop moving when it lands on a white moving platform, but not when it lands on a black moving platform. Therefore, players need to precisely control the landing point to ensure the portal doesn't slide off and fall into the pool.

Black moving platform, watch out for the inertia!

White moving platform, you could stick to it.

In the second chapter, we wanted to emphasize the characteristics of the portal itself. For example, a portal always needs an input and output, i.e., an entrance and an exit. With the portal itself acting as the entrance, what would happen when it comes into contact with different objects without an exit? Based on these ideas, we designed two features of the portal: absorption/elimination and teleportation. Without an exit, the portal would "absorb" objects it touches, perhaps randomly teleporting them to some location due to the lack of an exit. This might be a reasonable explanation. In any case, it would eliminate some of the objects it comes into contact with. Based on this feature, we combined it with buttons, doors, and springs, allowing the portal to open doors simply by using its own weight to press buttons. The teleportation feature was then introduced in the next chapter.

Press the button to trigger the switch and open the door.

In the third chapter, we wanted to emphasize the portal's teleportation ability. Unlike the shooting method in "Portal", in our game, the portal itself serves as an entrance and cannot shoot an exit, how should we design the way to use the exit? After discussion, we decided to place some fixed portals in the level and let players choose one of them to connect, making it the exit. In this way, players can think about their strategy before taking an action, avoiding confusion. Utilizing the portal's speed to impart velocity to certain objects demonstrates a certain level of skill, as players need to adjust the dragging angle and speed to make the teleported objects reach the appropriate position.

Momentum is transferred to the wooden box to press the button.

Advanced techniques

Apart from the basic level elements, we also design some specific level modules to assist players in practicing advanced techniques. For instance, using the combination of sticky bricks and venom pools to help players learn how to do multiple climbing, utilizing the sticky brick groups to learn a skill similar to wall jumping; combining item portals, wooden cases, and buttons, and imparting objects a velocity to design more complicated levels and challenges. To sum up, we make every endeavor to gradually introduce advanced skills to help our players feel a certain freshness and joy in overcoming challenges.

Existing Problems and Feedback

The biggest problem in the development is the late implementation of the prototype, and the exploration of the interest of the core gameplay is slightly insufficient. We put too much effort into following the RLD principle, spending a lot of time guiding players through the basic 3Cs, but not enough on the most interesting part—the level design of item portals. Perhaps players might experience a bit of boredom during the initial stages of gameplay, this is because, during the design phase, there were no restrictions on the number of times certain level modules could be used, leading to a high degree of repetition and lack of compactness in the levels. Most importantly, the introduction of new level elements occurs relatively late, and there is a lack of in-depth exploration of the most interesting portal features. Additionally, we have not introduced a certain time limit to enhance the challenge (similar to the timed buttons in "Portal"), but there is still room to introduce many interesting level elements to further enrich the game mechanics.

Possible Iteration Directions

Due to time constraints, we were unable to further refine the game, but there are still the following ideas for iteration:

Condense the level that introduces the basic 3Cs, and introduce the core mechanics as early as possible.

Reduce the number of highly repetitive level modules to avoid long waits and repetition causing player fatigue.

Introduce more complex level elements and time limits to provide a greater challenge for players.

Further emphasize the portal's teleportation characteristics, such as the player's portal being able to teleport itself to the exit through certain portals, or being able to launch a portal as an exit, thereby introducing more interesting mechanics and gameplay.

Summary

Through this game jam, I further realized the importance of prototypes and iteration. It could even be said that whether a game is fun largely depends on whether rapid iteration of the prototype has been carried out—if it's not fun, just keep experimenting based on the prototype until it is playable and interesting. This could specifically be reflected in some level elements being inherently fun, or some special interactions between elements creating a wonderful chemical reaction, also known as emergent design. In short, it's crucial to iterate and experience as quickly as possible; otherwise, once the game development reaches the middle to late stages, the enthusiasm of the developers will greatly decrease, and the game is likely to lack fun. Also, returning to the initial question, whether reversing the active and passive relationship between the hero and the portal indeed reflects the fun of reversal, or creates an experience different from past games? I can't answer with certainty, because the game we made still falls within the category of platformer, or due to the relativity of motion, the exchange of subject and object only changes the direction of motion, not the essence of that. But undoubtedly, such a prototype can indeed bring some novel experiences and has given me some new thoughts in game design. In particular, the attempt of RLD (Rational Level Design) has taught me how to systematically introduce level elements and verify their playability, much like the method of controlling variables in experiments, continuously controlling variables and exploring the impact of one single factor on the overall system until its optimal value is found, which is virtually intriguing.

💡

Welcome to leave a comment to exchange thoughts together!