Week 1, Design

Hello everyone!

We are just about to start production on our game. But firstly, we needed to break down the concept.

The game is a 3D puzzle adventure game with horror atmosphere where you’re able to switch dimensions to solve the challenges ahead.

The concept was too vague for us to start working on so I laid down the base design of the game this week.

The problem with the concept was that when we were discussing what kind of gameplay there would be, we came back to the puzzles themselves, and they all ended up the same way. There is an object in the way of the player, the player press walks pass object and press .

Starting from this point, we decided to change up the design a bit compared to the concept.

We laid down the intended aesthetics and worked our way from there with the core mechanics.

We wanted to create a feeling of vulnerability with two types of gameplay.

Dimension 1: Vulnerable state after being drained of power

Dimension 2: Vulnerable because overwhelmed with power

So putting that into an MDA framework it would look something like this**:

GOAL:  A puzzle adventure where every decision is questioned.

DEFINITION:  That the player feels stressed in dimension 2 and paranoid in dimension 1.

SUCCESS:

* The player experience uncertainty in their decisions

* The player feels powerful but exposed

* The players failures depends on their decisions

FAIL:

* The player experience that their ability to make decisions are of less importance than their in game abilities.

* Atmosphere and environment does not convey intended dynamic of stress and/or stealth

* The player’s power feels disproportionate to the challenge

When we established our intended aesthetics, we started working on the mechanics of the game. During a previous period , our lead programmer got excited and had already created a prototype for the game for us to work upon.
In the prototype the mechanics available were: Walking, Running, Jumping and a physics based interaction system.
We decided to keep everything in the prototype as it laid down a solid foundation to work from.
But we were aiming for creating the feeling of never being safe. For the most part, the puzzles would be traps of some kind, so that contributed to the aesthetics. However the main mechanics did not contribute to the aesthetics up to this point.

To create a feeling of vulnerability we decided to use resources in the form of health. This resource was not only for the player to have a measurement of the state he or she was in, but serve as a pool of points to use when switching dimension and using abilities.
Abilities included:
* Teleport for the player to sacrifice a part of their health resource in order to advance quicker or safer.

* Interaction with heavy objects, also by sacrificing a part of their health to move objects that were not able to be moved otherwise to solve puzzles in a different way.

* Time spend in dimension 2 cost resources per second spent in it.

The reason we decided to go with health was that it is generally accepted to correlate with how capable the character is to perform X task.

The player would  have the option to progress in different ways depending on their preferred play style. But for the GGC demo, we decided to force the player into the 2 different dimensions to show off the whole product.
The core loop would therefore look like this, where gathering resources and using abilities is optional:

Explore -> Gather resources -> Use abilities ->Solve puzzles -> Progress -> (Repeat)

To limit the player’s control and contribute to the horror atmosphere, we decided to go with a handheld controller as our input device. This decision was made early on as it affected the way the puzzles could be laid out and how the game is played.
The decision was also made as a means to gather more people to our game at the conference we planned to attend and display our game at.
When playing a game at a computer with keyboard and mouse, the player needs to sit down and commit to the play session. When using a controller, it is easier to just pick up and play. The layout of a controller is also designed for playing games on, while the keyboard is not.
The use of a controller makes us able to intuitively teach the player how to play our game by setting up different scenarios and let the player explore all the buttons and its functions. That is simply not possible on a keyboard, as there are too many key combinations for the player to explore.

** Taking from our design document, with slight modifications

Talk to you next time!

//Oskar

About Oskar Kervefors

2015 Graphics

View all posts by Oskar Kervefors →