Mechanics and Story

When talking about fun mechanics and story, coming up with the ideas wasn’t really the hardest part. Before the project started, we came together one night and talked about what we wanted to do. We did some brainstorming, wrote down what we came up with and tried to not say ‘no’ too much. Over the course of the project it often happened that someone would say ‘Oh boy, it would be so cool if … ‘. It’s just a part of being immersed in your project and caring about your little robot character.

The bigger problem here is choosing the right ideas to go on with. Due to the short amount of time we had, everything had to go fast. We had a huge list of things we wanted to put in the game and that list needed to get shorter.

To do this we spent the first 2 of the total 10 weeks on prototyping our mechanics. This meant testing out different robots and their features, trying different room compositions and the mechanics we needed for puzzles (buttons, doors, elevators, production lines). It also meant talking about the story and pinning down moments that were important to us. We tested out as many things as we could during these first two weeks. We had to give up on a lot of cool ideas, such as a robot that could sling form one point to another, but from the start, we all agreed that we needed to keep the list of features as short as possible because we were not going for quantity but for quality. During this period of prototyping, the programmers implemented mechanics as fast as they could. This involved dirty coding, chaotic blueprinting and bad naming conventions.

The artists then set out to design puzzle rooms. These rooms had no place in the story, but were just singular areas with the goal of ‘get to the next room’. Every time a new feature was finished, the artists could then quickly implement it in a room, to test its possibilities. As we were all technically schooled, even the artists could implement some small mechanics if they needed them fast. This meant we could test a lot of puzzles concepts really fast, practice doing game design and research decent working conventions. So if we talk about game and puzzle design, we have to emphasize the importance of this prototyping phase.

For the rest of the project we had one team member, Allan, that was dedicated to game and puzzle design. He blocked out all the environments and had final say over the layout of the game, the functions and puzzles in each room. He did a great job keeping a clear and coherent view on the puzzles and game layout.

Designing the puzzles was interesting. Knowing you had to create a puzzle that needed to be original and difficult enough for the player to enjoy solving was a challenge. The puzzles that made it into the game were actually designed during the creation of the rooms, we did not have/use any pre-designed puzzles that worked similar to the final in-game puzzles. This was because it was easier to create a challenging obstacle with the room already in front of you instead of creating a puzzle on a blank sheet.

The biggest test for Allan’s gameplay and puzzle ideas was letting other students playtest our game. We let around 20 people playtest Rewired while the team was watching them closely. We made notes from every playthrough and reviewed their experience afterward.

We soon came to the conclusion that people loved the atmosphere and the story. The puzzles were challenging enough to keep them interested and eager to solve them.