Aug 11, 2015

SHE - AGBIC 2015 entry (Postmortem)

2:58 PM Posted by Lucas Izumi , , 2 comments
SHE is a game I developed for the "A Game By Its Cover 2015" (AGBIC) game jam. It's a puzzle game where you control a girl who is trapped in a unknown location where you have to solve puzzles in order to advance. A quick game description:

SHE is trapped in a unknown world. SHE wants freedom. Help her reaching her goal by solving puzzles and advancing through levels! Plan your steps wisely as you progress, this world is not as inoffensive as it seems. Will you be able to unveil the mistery behind SHE? 

You can play the game on the link below:
I've been using Game Jams to help put to practice the theory I studied for years. And I try to push my limits in every one of them, choosing different game mechanics to work with each game I design. So far all the Jams were a great source of experience, with this one being one of the greatest. It helped me a lot to get better in designing puzzles. I think these were the most important things I learned:

- If a puzzle can be solved by just pressing random buttons until a solution appears, it's not a good puzzle. If players don't understand what they need to do at first hand, they will start to experiment, and if during that proccess they happen to find a solution by accident, it will not be fun to them in any way.

- I think it's mandatory to have people to test your game when working with puzzles. Since you designed them, you may always know the answer and this can make thinking outside the box a little difficult. When other people playtest, you can visualize a whole new panorama. Playtesting is extremely important to any kind of  game but I think that for puzzle games it is essential.

Designing a Puzzle Game
I had a lot of reading (and watching) in order to better understand the puzzle design process.
This article, by Bob Gates (1997), helped me a lot during the creative process behind puzzle design.
This talk by Matthew VanDevander was also very cool.
Another great article worth to mention is "Fourstep Puzzle Design" by Ashen Einhorn. In this article, Ashen lists four basic steps to achieve success while designing a puzzle:

Step one - the player understands the objective.
Step two - the player discovers the puzzle.
Step three - the player works out a solution in their head.
Step four - the player implements the solution and solves the puzzle.

It may seem pretty basic but the correct implementation of each step changes everything.
Well, now, let's talk about the puzzles I designed for this game.
PS: Please note that, since some of the puzzles below were discarded, the images may represent their test prototype and not the final version.

The Clock Puzzle
A puzzle may sound good in theory, but totally fail in practice.

Recently I played Final Fantasy XIII-2 and went through the Hamiltonian path Clock Puzzle. After that I wanted to do something clock-related. A puzzle with clock-elements could easily fit in the scenario of my game, so I designed the following puzzle:
It consists of 2 pointers: one black and one white; and 3 levers. Each lever contains two numbers engraved on it. The first number indicates how many turns (hours-based) the black pointer will turn (clockwise). The second number indicates how many turns (also hours-based) the white pointer will turn (counter-clockwise). To solve the puzzle, the player needs to set the black pointer in a certain number and the white pointer in another one. In theory it seemed really nice. In practice, however... Soon, I noticed that by simple pushing levers arbitrarily, players could reach the solution. And no matter how difficult I defined the solution to be, This setting could sound really cool inside my head, but after implementing it, it failed as a puzzle. And you can't argue that the player is playing wrong, because he/she is not, it's simply that the puzzle was not a good one.

The Levers Puzzle
A puzzle not only needs to work, it needs to keep the player engaged.

The Levers Puzzle consisted of a certain kind of maze with levers scattered all through it. There were lots of holes as well (represented by red retangles) and the levers were connected to theses holes. By using one of them you could create a bridge over a hole and advance. The puzzle was simple enough and there were room to create more complex ones. I had plans on creating settings where by pushing a lever, you created a bridge somewhere but also a hole somewhere else, creating a situation where the players would have to plan their moves in order to succeed.
However, after testing it a couple times I realised that most of the solutions would consist in the player walking, and walking, and walking... I even reduced the size of the walkways several times to try to banish this feeling that "I only walk in this game". When I made them as short as possible I called some friends to test it. The puzzle elements were there. They could still try to do things arbitrarily, but this time they would reach a point where they would need to think. From all my friends, the feedback was the same. They were getting a feeling of "okay, let me finish this puzzles fast so I can see what this game is about" without realising the game was about solving those very puzzles. That made very clear to me that they were not engaged. Even if they had to think to solve it, it was just an obstacle to them and not one that they would feel proud to overcome.

The Panels Puzzle
Don't be afraid to try out ideas. Everything is learning.

After abandoning the puzzles I mentioned above, I started to think of a new mechanic: one that I could expand and increase its complexity. The first thing I thought was a hologram switch. By standing over it, the player would create a projection in some place of the screen (this place would be inacessible otherwise) and would be able to control it. There, he would have limited movements to do something. I actually implemented this system. However, with limited movements you have limited options to work with. It was becoming very hard to design a real challenge to the player so I decided to try something different. But all this work was not in vain.
I had created some special tiles so the projection could walk and I could count its movements. By looking at them I started to think in another kind of puzzle: the panels puzzle. It consists of a series of panels gathered togheter on the floor. They have two distinct colors and each color has its properties. Let's call the first color Green and the second color Red. By stepping into a Green panel, the adjacent panels in its vertical would also become green. As for the Red ones, by stepping onto one of them the adjacent panels in its horizontal would become red. With this simple system I can create very basic puzzles and very complex ones. I defined the win condition of each puzzle to be a defined disposition of Green and Red Panels.
For Example, to solve this level you need to make the green panels resemble a H.
Yet, the cool thing about it was that I could use elements of the original idea and mix it with the puzzles (alternate solutions, collectibles, environment elements, etc). The feedback on this puzzle was much better than the previous ones. This locked room setting helped a lot to keep the player focused. One of the great flaws of the Levers Puzzle was that there were many elements on the screen and because of that the player could feel confuse about what to do next. In this one, the panels are the highlight and quick look in the scenario is enough to tell players what they need to know.
I'm confident enough to say that this puzzle contains all four steps mentioned by Ashen Einhorn.
1) The player knows they have to open the exit. (Player undestands objective)
2) They check the exit and see that it's not working. They see a cable linking the exit to a terminal, and this terminal contains a certain disposition of colored panels displayed on the screen. The player knows that there are several colored panels on the floor. (The Player discovers the puzzle)
3) By stepping into the panels, the player can change them and make they look exactly like it's being displayed on the terminal. However, every color has an effect, so they need to think in order to color them right. (The player works out a solution in their head)
4) After thinking about the solution, the only thing left is apply it! (the player implements the solution and solves the puzzle)

Development process: what went right
One of the things I'm most proud of is that once I decided to make this game, I set a few elements that were a must and I managed to put every single one of them in the game. Even though I discarded all the first puzzles (that had some relation to these elements) they still fit with the new puzzles. They were connected to the essence of the idea. If I couldn't implement them, then choosing that cover art would be in vain.

After designing the panels puzzle and deciding that would be the puzzle for the game, I had a few problems with its mechanic and the players movimentation. I was using and 8-direction movimentation and that were giving the player way too many freedom. That way using the panels was extremely painful, because your movements needed to be very precise, otherwise you would make a mess. I quickly though about implementing a grid-based movement and surprinsingly I could make it work really quick, solving all the movimentation issues.

Development process: what went wrong
Once again I decided to create a game using Construct 2. I love this engine, it's very simple and you can obtain results very fast. However, I'm owner of a free version... so I'm limited to 100 events only. I first designed this game to have 20 levels, 5 secret levels and 2 endings. When I finished the first 5 levels, I already had reached the 100 events. Most of them were taken by the base mechanics of the game, elements towards the puzzle, etc. I then started to delete all my groups within the software (created purely for organization) which created a chaos in my code. Facing this I had to make the game with only 8 levels. But as I said earlier, since I could place all the elements I wanted in the game, I'm cool with that.

Credits and Special Thanks
Lucas Izumi (Game and Level Design)
Mariane Saito (Concept Art)

A few months ago, my friend Lucas Folle composed a song to a game we never finished. Since the song fit in this game, he let me use it (it's te main menu song).
I found two great tracks in the website Freesound.org which I used in the True Ending cutscene and Game Credits. They are credited to the awesome guys below:
Iwan 'qubodup' Gabovitch (www.freesound.org)
sepal (www.freesound.org)
Speedenza (www.freesound.org)

And I would like to thank Willy Oliveira and Matheus Ferraz for being ferocious testers of this game. Matheus has been testing every game I create since the first one and he is very good at ALL of them! It's funny that, in this case, I just sent a link to the game's page to him and said "Check this game out, I'm still polishing it but everything necessary is apparently working" and half an hour later he sent me a message: "I just finished it. It has 3 endings, right? Also there's a bug when I do X, and another when I do Y". This guy is amazing. (There's actually 2 endings, the supposed third one is just the game over screen)

I also would like to thank Mariane for joining me in this Jam. In addition to her amazing art she was also very supportive and helped me a lot in making this game better.
For last, thanks in advance to everyone who plays and who'll play SHE! I hope you all enjoy it, and if you do, please spread the word!

2 comments:

  1. I have just completed two endings of this game, and found it extremely enjoyable on a number of levels. Figuring out how to get the alternate solutions was a very satisfying "Aha" moment only triggered by the way your glitch mechanic carried over through level resets, and the overall structure of the puzzles- Never easy enough to stumble across the answer, but never so difficult that I didn't see what I'd done wrong when I ran out of colors in a column or row- was engaging, challenging, and overall quite fun. And I'm glad that She got out in the second ending; the narrative grabbed me, for some reason I don't fully understand. Reminds me of the design choices that went into Portal's companion cube. I loved this and will be recommending it to people as what good game design looks like, especially with this document attached.

    ReplyDelete
    Replies
    1. It makes me very happy to see "SHE" delivering this kind of feeling. It was a challenge to design this game and your feedback makes me glad that I was able to achieve some of the results I wanted. Thank you for playing and for the recommendation!

      Delete