Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
May 23, 2018
arrowPress Releases






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


How the QUBE 2 devs built a better massive 3D puzzle labyrinth

May 10, 2018 | By Jack Yarwood

May 10, 2018 | By Jack Yarwood
Comments
    Post A Comment
More: Indie, Design, Video



Designing puzzles for your next game is tricky business. Some of the biggest challenges you'll face include how to recognize your audience’s skill level, ensuring they understand the necessary mechanics for progression, and presenting the narrative to them in a way that’s easily digestible and doesn’t distract from the puzzle-solving.

While working on the follow-up to its successful first-person puzzle game Q.U.B.E, Toxic Games set a bunch of rules to make sure its approach to the puzzle design was an improvement over the original. This included limiting the number of mechanics, and keeping the story sections away from the puzzle areas.

In Q.U.B.E 2 players step into the shoes of Amelia Cross, a stranded archaeologist who must navigate an alien planet with the aid of a special set of gloves that allow her to place cubes. Along the way, she will discover the ability to place a number of different cube types. These include a blue cube that propels the player up into the air, a green cube that can produce a gelatinous cube, and a red cube that can be pulled out of the wall to create platforms.

The idea for making a sequel to Q.U.B.E came about because the team felt like there was more to explore with the core concept of placing cubes after the initial game.

 
" You want people to be able to discover [things] for themselves. I think they are more likely to remember it that way."

Q.U.B.E was our first game. We’d just finished university and we didn’t have a programmer on our team or an artist, so it was quite limited in what we could achieve," says Dave Hall, the creative director and the person behind the puzzles in the game. 

"So, we put the game out, and I think a lot of people liked the concept, but felt it was quite limited as a result of […] the budget and also because we just got into game development. We thought with a bit of extra experience we could take it further, because we felt like the concept had a lot of potential.”

Gleaning the cubes 

One thing that the team wanted to keep from the first game was the tutorial system. Unlike other games that include a set tutorial, Q.U.B.E and Q.U.B.E 2 allow players to experiment with the mechanics to get to grips with them.

In the second game, for example, you are introduced to each cube mechanic separately over the course of the first four sectors. Before you gain access to using the ability, you will need to play through a level featuring the mechanic in a set position, showing you what it does in context before you even get the chance to place it yourself.

“There’s a way in which most of the game is a tutorial, but definitely like the first four sectors were designed just to introduce the three place-able mechanics and then give the players a bit more freedom. And we felt it would be better to do it in game, rather than actually having a set tutorial that kind of has written text telling you what to do. You want people to be able to discover [things] for themselves. I think they are more likely to remember it that way.”

That being said, the game does break this rule on occasion. There are certain text prompts that were introduced in Q.U.B.E 2 to ease progress. These include things like button prompts to show players how to delete cubes or interact with the environment. These were later additions, however, after receiving some minor complaints from playtesting the game.

Switching from Kismet to Blueprint

The biggest fundamental change between the development of the first game and its sequel is the move to using the visual scripting system Blueprint in Unreal. On the first game, the team used Kismet to design the game, but, on the sequel, they switched to the much more versatile Blueprint, which gave them a much faster way of prototyping level layouts.

“The main thing with Kismet is that isn’t designed for making a game,” says Hall. “It’s designed for like level sequences, so everything needed to be created over and over again. So, everything you see in Q.U.B.E 1, like every red cube, every yellow cube, there’s a sequence we had to manually create for each one, which is just really time consuming.”

Blueprint, on the other hand, is class-based, which meant that Hall and the team could iterate on stuff far more easily. This was especially useful considering the team only had one programmer.

This wasn’t the only feature of Unreal that came in handy though. As well as this, the team also used BSP, which allowed them to block out and create quick drafts of each level before the artists were even brought on board.

Refining the concept

These tools helped Hall and the team refine the concept of the game and prevented the oversaturation of ideas that had occurred in the original.

Hall explains, “[In] the first game, there was a lot of different mechanics, so you could play from sector one to sector three and skip straight to […] sector seven. Everything in between there is kind of used once, so we felt that we needed to focus it a lot more.”

Features that were planned for Q.U.B.E 2 but were cut as a part of these experiments include more cube types such as one that had no gravity, the addition of AI characters, and a few action-orientated chase scenes.

The team decided to restrict the number of cube types as they felt that adding more upset the balance and overcomplicated the game. They ditched the AI characters and the more fast-paced scenes, on the other hand, because they believed death wasn’t worth adding for only a few sequences in the game and was contrary to the more cerebral experience that their fans expected.

Working in the story

One new addition that did make it into Q.U.B.E 2, however, was an overarching story. The original Q.U.B.E didn’t have a narrative, with the team retroactively introducing one to the game’s director’s cut. With Q.U.B.E 2, the team set out from the beginning to have a plot running through the game and so they decided to set some rules in place to ensure it didn’t hinder the puzzle-solving experience.

“The main idea with puzzle design in terms of story is you actually want to keep them as separate as much as possible, just because people can’t focus on two things at once," says Hall. "It is like if you’re trying to solve a puzzle and you have dialogue playing at the same time, you are probably just going to ignore the dialogue or you’re going to stop playing. So, we felt it was important to have these separate environments where the dialogue happens and all the narrative events happen. So, when people did get to a puzzle room, they could just focus on that.”

An easy to solution to this was to use the plot as a reward and a break from puzzle solving. The game is paced in such a way that you will solve a few puzzle rooms in succession before entering a separate area where you will be gifted with some dialogue or narration, allowing a brief respite from the mind-bending trials. This creates a welcoming rhythm that encourages the players to continue.

Knowing your audience

In spite of the game’s critical success and the team’s extensive preparation, the team do have some words of warning that they picked up from the experience of creating Q.U.B.E 2. The most important is knowing your audience. They tested the game at Bristol Games Hub, Cardiff University, and UWE in Bristol to an enthusiastic group, but didn’t screen players to check if they were already puzzle players. 

Hall says, “I think the important thing is you need to get the right players. Because sometimes we’d get people to playtest who weren’t really into puzzle games and they’d get stuck, and that was when we made it easier. But actually, we’ve made the game and our hardcore fans are now saying it’s too easy. It is a really difficult balancing act.”



Related Jobs

Powerhouse Gaming, Inc.
Powerhouse Gaming, Inc. — Sacramento, California, United States
[05.22.18]

Game Integrations Engineer
innogames
innogames — Hamburg, Germany
[05.22.18]

(Senior) UI Designer for a New Mobile Game
Giant Enemy Crab
Giant Enemy Crab — Seattle, Washington, United States
[05.21.18]

Level Designer
Wargaming Seattle
Wargaming Seattle — Redmond, Washington, United States
[05.18.18]

Design Director









Loading Comments

loader image