The Red Stare
Spy on your neighbours from  your apartment in roomscale VR
Team lead, puzzle designer, UX designer
(2016 - 2017) Play:D & NHTV

Fact sheet

Title: The Red Stare
Platforms: HTC Vive, Oculus (3 sensors)
Engine: Unreal Engine 4
Genre: Roomscale VR, puzzle
Time:  September 2016 - July 2017
(I joined Feb 2017 - July 2017)
Team: Play:D
(18 members while I was present)
Awards / recognition:
​Steam - Released July 2017
NHTV - Greenlit for year long development
NHTV - Best game design Y3
Dutch Game Awards 2017 - Best Student Game Design
Dutch Game Awards 2017 - Best Student Art Direction

Description

​The Red Stare is a room-scale VR game about spying on your neighbours, to figure out who may be a communist.
​
In The Red Stare you act as an american agent in the 1950s on a stake out. Gathering evidence on your neighbours and figuring out what role they play, with the goal of identifying which one of them is a communist spy. You do all of this from within your apartment, receiving information from your phone and fax machine, using intel from files on your desk, and taking pictures which you can fax to your handler to prove suspicions. You’ll have to use a number of different ways to identify people ranging from descriptions of their appearance, to items that can be found in their rooms, to behaviour only specific members of the communists’ ranks follow.
Relevant sites:
Theredstare.com
Steam page
Facebook / TheredstareVR

My contribution

Team management
One of the main tasks I needed to fulfill in The Red Stare was managing the team, making sure everyone had something to do, was working towards the same goal, and was motivated to do so. This went extremely well, to the point where we are fairly sure we have been the most motivated team for the entire half year I was part of it. Most of the credit for that goes to the team, they were incredibly good to work with and put everything they had into the game, making sure it was something to be proud of. I do take a bit of credit as well though, as I spent a lot of time preparing the daily stand-ups to make sure the entire team was informed of what we would do next. And of course I worked with the other leads to make sure we planned everything out and ​worked towards milestones properly. We managed to avoid a lot of communication issues by simply keeping each other updated on anything important going on.
Fleshing out gameplay
One of the problems with The Red Stare before I joined was that the gameplay was still not really worked out. There was a good foundation with numerous ideas in place - but what exactly the player would do and how we would make our puzzles work is something I still spent a lot of time on. One of the things I did was prototyping small areas of our game design and playtesting them using a google slides presentation. After testing this I worked with fellow designers on creating a system to easily set up what suspects (the people the player is observing) would do throughout a day. While this worked alright at first, I really wanted to focus on more dynamic and interesting things happening throughout assignments, so I ended up doing a lot of scripting instead. This took a lot of time, but gave the assignments a lot of interactivity, and gave me a lot of control over what happened throughout them. On top of that, I worked with my fellow designers to develop the interactions and mechanics we would use both for gameplay and immersion purposes.
Foto
Prototype presentation to test the puzzles
 Foto










A small gameplay element I added - staring at the clock to speed up time.
Puzzle & narrative design
I spent quite a while trying to figure out how exactly the puzzles should work. I made some prototypes in documents and spreadsheets, as well as the slides presentation linked above. This left me with a good high-level overview of what I wanted each assignment (A puzzle or small combination of puzzles) to show the player, and how they fit together in the overall scenario (the entire play through). After having figured out I was going to script the assignments, I set up a lot of functions and macro's to make it easier for myself later on, and started scripting out the assignments. It proved to be a bit of a tougher task than I expected, as what we were going for relied on a lot of scripting and as it would be released, I had to get it done before the deadline. I was able to get everything done, but I learned to be a lot more wary of tasks gradually increasing in scope in order to avoid going too far into the night in the future. I also figured out that making a puzzle game in VR with very limited access to VR devices is a nightmare for playtesting. I think I could have improved the final bit of polish with more playtesting in VR. In spite of that I'm very happy with how my puzzles turned out, as I've been able to put some interesting logical challenges, dynamic responses to players, and even some branching narrative into the game.
First iterations of the puzzles - docs and sheets
Blueprint scripting to bring the puzzles to life
Odd jobs
On top of managing the team and doing puzzle design, I worked on a number of smaller tasks that ranged from marketing, making the trailer and creating presentations, to gameplay systems, such as the system to make sure things outside of the player's reach return to their original position. I even ended up recording audio with one of our voice actors, and doing a bit of voice acting myself. There were a lot of these smaller tasks to go around and it was often quite nice to do something and finish it up within a couple of days, after which I could return to my main tasks.