As the project began all the components of the team developed and pitched their idea to all the team. Each one of us had the occasion to receive and give feedback and, in the end, we decided to not choose a single idea but to combine part of them to have the "perfect" result.
This way "Ruhi" was born. We decided it to be a Legend of Zelda-like so I had to do my research about Legend of Zelda games since I only played the remake of "The Legend of Zelda: A Link to the Past" for the New Nintendo 3DS.
I've done my researches trying to understand the main focus of the game and how they manage to stay always on top for such a long time, even if I knew that the story wasn't a main pillar for the series.
My two main findings of the game design, focusing on gameplay and level design, where:
I loved how the team moved consistently and in harmony so much that this brought us to don't make a scope that was too much bigger and that would make us overloaded with work during all the week.
We did a pitch to decide the idea and we went for a Legend of Zelda-like so I studied the main features of it since I didn't play a lot of them before.
At first, the development of the core mechanics consisted of making the player able to move in four directions and attack. Also, the basic interaction with other NPC was built.
Right after I as the designer started creating the main puzzles and, considering that we were running late, we decided to not use gadgets to solve puzzles but instead, we focused on the mechanical switches that would make things happen.
So, I started creating the puzzles using 2 main obstacles: moving platforms and holes shooting arrows as hazards.
The main idea around these puzzles was that they should introduce the player to the mechanics of the puzzle slowly. The first one had the intention to show how the switches worked letting the player understand that, when pressed, they would show some platforms where the player could walk on.
The second puzzle would show the player that the platforms could move and also that some switches could make appear platforms in other rooms also.
The last one would ask the player to make use of the knowledge acquired since then and also add a level of difficulty by adding hazards. The hazards would also leverage the fact that the platforms were moving to make the level more difficult.
During the development of the mechanics needed for the puzzles the programmers encountered some problems in the development so, in the end, we decided to transform moving platforms into standing still platforms and hazard into enemies. Here can be found all the transformations of the puzzles due to the lack of time to develop such mechanics.
In the end, we all managed to present a part of the game due to lack of time but I'm proud to say that since most of the team members had other important things to do (such as attending university lessons or a full-time job) we didn't crunch to deliver this result.
Also, I'm happy with the result we had with the design of the puzzles. Even if they might seem too simple in the end, I think that for the scope of the game they fitted good into the game. Also, having to tweak them and remove/transform some parts due to the lack of time we had represents a really good experience: not only during game jams but I think that also during the development of games with a bigger scope everyone in the team should understand that there might be some constraints. We all wish we could have all the time (and by doing so, money) to develop games but ofter I think is not like that, so learning that by doing little projects is important to me.
With this project I learned a lot about design but mostly how the design part should work consistently with the other teams, making a central role at the beginning of the project, during all the projects but also for coordination.