Game Designer
Robert Åselid
Rouse
ROLE
UI Design and Puzzle Design (Puzzle part got cut unfortunately)
DESCRIPTION
Rouse /rauz/
Verb: Cause to stop sleeping.
Is a school project spanning over a total of about 7 weeks. Where a team of 14 people, my self included worked together to create.
Rouse is a game that takes the player on a journey inside the dreams of the main characters little brother.
The goal of the game is to solve puzzles by using the so called Blunderbuss. which is a gun that you can use to manipulate certain objects.
You complete different levels and get narrative in between them. And hopefully, you will find your brother in the end, wake him up and escape this nightmare.
The Piano
I did make a piano puzzle where the player had to press a button. See the piano play X-amount of notes. And then the player had to play the same notes in the correct order to pass the puzzle.
I do like to start off working with pen and paper as I feel it is easier to visualize and in all honesty a faster way (at least for me to work out what is needed for something to work).
I started off with just the layout of the puzzle, and then went on to the programming/blueprinting part of things by listing the information the piano would need to keep track of.
When the list for what information that would have to be monitored was done, I started making a prototype.
First I made the piano play the 3 different songs when player pressed a button.
After reaching this stage I had to step back a bit as I couldn't really start with the other part (player playing the piano). The player was meant to push big "boxes" down on the notes to play them.
But the Pushing mechanic was still being worked on, so I instead started making a blockout of this isolated "Piano Level". which was to be more of a story beat level than anything else really (therefore the size/complexity).
After this the pushing mechanic was functional and I started to work on the next step of the piano. (Letting the player play the piano to match the song that was played).
After completing this part, I jumped on the task to make the piano keep track of the notes played, as well as the order they were played. And then the same thing for the notes played by the player.
When the amount of played notes are the same as the song played by the piano it would then check if the notes were played in the correct order.
If this was the case, the player would clear this song and move on to the next song if there were any. (If there was no songs left to play the puzzle was complete).
And if not, the piano would reset the players notes, and the player could try again.
This concludes the piano puzzle part unfortunately as it after this got cut as the scope of the project had to be trimmed down.
In Game UI
As mentioned earlier this whole piano level and puzzle had to be cut later and I jumped on the In game UI part of the project.
Anyhow, The Blunderbuss a.k.a gun that the player uses, have 3 different kinds of ammunition. And each type of ammunition also have a different number of objects that can be manipulated at the same time.
So I started once again with a more paper like approach by taking a screenshot of the game, and started drawing different ideas of how it could look like. Think I stopped at about 9 different once and then consulted the team one which one they liked the most.
These are 3 of the ideas I came up with.
In the end the first picture on the left was the one that got chosen, and I started to work on the functionality of it right away.
Being kind of new to animations in widgets my first thought was to just use Timelines to move the objects on screen. Which I've done many times. For widgets, this was not the case however, as widgets don't support timelines.
So I had to learned how to do easy animations in widgets. This took some time to learn, but eventually a result that was functioning and I was happy with.
This Power & Ammo wheel as we called it was done, it just needed to be hooked up with the ammo system when the programmers were done with it. And of course replace these placeholder cubes and lines with art made by the artists later to make it look good.
So while waiting for these things to get done I jumped on the next thing on the to do list.
I started making widgets and functionality for pop-up windows with text and videos. As well as some voice over recordings that was to play, tell & show the player both how to play the game, and narrate the story of the game.
First draft of one of the first info windows.
The 2 boxes with text are to contain vidoes on loop.
I continued to make the rest of the widgets for the tutorial messages, as well as keeping a dialog with the narrative designer if there were any places he wanted some narrative to be woven in together with the tutorial.
When all the widgets was done, I started making the videos' that was to play, as well as starting to make the voice-overs for the game using AI voices from Replica.
I continued to make the rest of the widgets for the tutorial messages, as well as keeping a dialog with the narrative designer if there were any places he wanted some narrative to be woven in together with the tutorial.
When all the widgets was done, I started making the videos' that was to play, as well as starting to make the voice-overs for the game using AI voices from Replica.
It was just before I got done with this that all the art and ammo mechanics was completely done. I helped the programmers with hooking up the ammo system they had made with the power wheel, and then I added the art the artists had made. And if I do say so, I think it all looks really good in the end.
And this concludes this part.
For anyone that would like to take a deeper look into the blueprints for this you can find them here below. Feel free to look around, move, zoom and get a good look.
Code related to the power wheel.
The Main Menu
For the main menu it started off with a lot of research of other similar games menus as well as a lot of dialog with the artists of how the main menu might look like.
Later on the actual content of the menu was discussed within the whole team. (Things like what menus to include, different functionalities and other)
And after this it got decided that the menu would be in 3D.
This could put a lot of pressure on the artists making even more assets, so to prevent this we chose to re-use other assets from the game in the main menu as well.
And after this it got decided that the menu would be in 3D.
This could put a lot of pressure on the artists making even more assets, so to prevent this we chose to re-use other assets from the game in the main menu as well.
I did however find out that you could use the particle system in a widget with a free plugin. So an idea of a smoke like "poof" effect when changing between the menus took root in my mind, and I started trying it out.
This looked okey, but as I started adding more of a void kind of feel to the menu it ended up not being used in the final version.
First draft of the new menu.
This looked good in my eyes, but the artist wanted more contrast and distinction between the "buttons". So after some back and forth, we ended up with the final version.
