"The Red Stare is a VR Experience in which the player takes the role of a detective on a stake out in 1950s New York"
|
Roles: Technical designer & AI Designer
Development Team: Play:D Team Size: 18 Platforms: HTC Vive Engine: Unreal Engine 4 Development Cycle: September 2016 - July 2017 |
Winner Dutch Game Award Best Student Game Design
(2017) Winner Dutch Game Award Best Student Art Direction (2017) Winner NHTV's Best Design (2016-2017) |
|
|
|
My work in The Red Stare
I worked as a technical designer in the Red Stare. I made prototypes for several features at the start of development. I designed and programmed the first two iterations of the AI, which is the base for the final AI. It started out as a small way point AI, which would just go from one point to the other, and became a AI that would make decisions based on the environment.
Most of the animations were integrated by me, with the proper blend spaces and state machines to make sure both the player and the NPC's were animated properly.
Other features I worked on were; stabilizing the movement of the camera, the logic of checking the answers the player gives, interactive items in the room, and the fax machine.
The project was divided in four blocks, each lasting about ten weeks. At the end of each block team members could join or leave. I was part of the group that was in the project for all of the four blocks.
Most of the animations were integrated by me, with the proper blend spaces and state machines to make sure both the player and the NPC's were animated properly.
Other features I worked on were; stabilizing the movement of the camera, the logic of checking the answers the player gives, interactive items in the room, and the fax machine.
The project was divided in four blocks, each lasting about ten weeks. At the end of each block team members could join or leave. I was part of the group that was in the project for all of the four blocks.
Developer stories
Developing the AI
Waypoints
When the project started out, it was a linear game where the characters would play out their part and then at the end the player would have had to figured out what happened. The AI only had to be simplistic, walk here, play animation and occasionally react to something the player did, but never do something that could break the script. The original design was done using waypoints. Go there and do this, then go there and do this. Simple and functional, but not without problems. Having all the characters synced up was a enormous task and could take hours for minutes of playtime.
Schedule
The next step became more convoluted. The AI had to work according to a schedule. Instead of having getting the info from a waypoint, the AI had to decide how fast and when to start moving to their next task. (e.g. Go outside and talk at 10 am and then at 12 be back inside). Here I only designed the AI, and did not develop it.
After some problems within the team, and redesigns that occurred, the AI had to be changed again. Six weeks after the change we still did not have any sign of the new AI, and with the redesigns most of the work from those six weeks was redundant.
Rules and environment
The next step was that the AI would be moving according to rules instead of a schedule. For example, only certain characters could go on the roof, while others would not smoke outside. The system had to feel somewhat organic, like the characters were just acting out their daily lives, with some having some secret activities hidden in there.
There were two caveats. The programmers that were in charge did not have the time to create this branch, and the deadline to present our new design direction was in ten days. In order to allow for implementation, testing and iteration, I needed to have the basics done that same week.
I designed the system around the following. Each character could be given a different set of rules to follow. The characters would look for areas to go towards instead of waypoints, and would choose a semi-random location (preferably in the view of the player) there to do their task. The tasks would be decided by the rules and random chance. (E.g. Character A has 20% chance to smoke.) They would follow these rules unless they had something scripted happening. I managed to make a prototype of this AI in three days, which managed to convince our supervisors of our new design direction. Afterwards I handed it over to our new programmer who improved and rewrote my system.
When the project started out, it was a linear game where the characters would play out their part and then at the end the player would have had to figured out what happened. The AI only had to be simplistic, walk here, play animation and occasionally react to something the player did, but never do something that could break the script. The original design was done using waypoints. Go there and do this, then go there and do this. Simple and functional, but not without problems. Having all the characters synced up was a enormous task and could take hours for minutes of playtime.
Schedule
The next step became more convoluted. The AI had to work according to a schedule. Instead of having getting the info from a waypoint, the AI had to decide how fast and when to start moving to their next task. (e.g. Go outside and talk at 10 am and then at 12 be back inside). Here I only designed the AI, and did not develop it.
After some problems within the team, and redesigns that occurred, the AI had to be changed again. Six weeks after the change we still did not have any sign of the new AI, and with the redesigns most of the work from those six weeks was redundant.
Rules and environment
The next step was that the AI would be moving according to rules instead of a schedule. For example, only certain characters could go on the roof, while others would not smoke outside. The system had to feel somewhat organic, like the characters were just acting out their daily lives, with some having some secret activities hidden in there.
There were two caveats. The programmers that were in charge did not have the time to create this branch, and the deadline to present our new design direction was in ten days. In order to allow for implementation, testing and iteration, I needed to have the basics done that same week.
I designed the system around the following. Each character could be given a different set of rules to follow. The characters would look for areas to go towards instead of waypoints, and would choose a semi-random location (preferably in the view of the player) there to do their task. The tasks would be decided by the rules and random chance. (E.g. Character A has 20% chance to smoke.) They would follow these rules unless they had something scripted happening. I managed to make a prototype of this AI in three days, which managed to convince our supervisors of our new design direction. Afterwards I handed it over to our new programmer who improved and rewrote my system.
The red circles indicate the center of an area. Some characters are only allowed to stay in the middle, while others can go up. Only one is allowed to be on the middle block.
Running a marathon
The Red Stare is the longest project I have worked on. This is a project which I worked at least 40 hours a week on, and often a lot more. Working on a project for that long brings all sorts of difficulties with it. First problem I encountered were the doubts.
Is the project any good? Am I wasting my limited time here? Am I keeping the rest down? The longer a project runs, the more doubts start to seep in. Aside from the doubts, I started to get frustrated with the people on the team. Halfway in the project I wanted to quit, find another project to work on, and spread my chances. Through some chance I stayed for another block, which meant that I was in there for three out of four blocks. In the last block it is almost useless to switch teams. From this point I just had to finish the project and make the best out of it.
After that the everything became better. New people joined the team, and motivation went to an all time high for everyone. We were suffering from bad morale and problems before, and now that we had overcome that, we were stronger than ever.
Later when I talked to people from other teams it became clear. Every team has its problems, and everyone wants to quit at one point. But finishing your project and working through the problems is the road to a good game.
Is the project any good? Am I wasting my limited time here? Am I keeping the rest down? The longer a project runs, the more doubts start to seep in. Aside from the doubts, I started to get frustrated with the people on the team. Halfway in the project I wanted to quit, find another project to work on, and spread my chances. Through some chance I stayed for another block, which meant that I was in there for three out of four blocks. In the last block it is almost useless to switch teams. From this point I just had to finish the project and make the best out of it.
After that the everything became better. New people joined the team, and motivation went to an all time high for everyone. We were suffering from bad morale and problems before, and now that we had overcome that, we were stronger than ever.
Later when I talked to people from other teams it became clear. Every team has its problems, and everyone wants to quit at one point. But finishing your project and working through the problems is the road to a good game.
Technical design
I was mostly working as a technical designer in The Red Stare. Some of the things I did were major features (like the aforementioned AI), while simpler tasks like integrating assets into the game. One of the tasks I was in charge of were the animation integration.
Due to our limited team size, we were forced to try limit our workload. In order to do that, we imported animation assets from other sources. One of the problems we faced, were the skeletons. Our skeletons were not made for the imported animations. I researched the topic and found the best method of re-targeting the animations to our skeletons. The left shows what the animations look like without proper re-targeting.
Due to our limited team size, we were forced to try limit our workload. In order to do that, we imported animation assets from other sources. One of the problems we faced, were the skeletons. Our skeletons were not made for the imported animations. I researched the topic and found the best method of re-targeting the animations to our skeletons. The left shows what the animations look like without proper re-targeting.
|
|
|
I also made sure that the animation of the hands work. Every object in the game can be tagged to have a certain pose. When the hand picks up said object it will shift to that pose. The system allows for an near infinite amount of poses without losing any functionality. Additionally, the fingers have additional animations, such as moving the thumb in relation to the position on the Vive trackpad.
|
|
|
Another system I worked on was the fax machine and the intel that is supplied by it.
The fax machine has two roles. First is that it supplies the player with information by printing what we want it. It knows when to print which set of papers, depending on what the player currently has to do. The papers are made by combining a couple of variables, such as the text on the paper, and the image on the paper. In the newer versions of the game, the information is baked as texture on the paper. Allowing for it to look authentic, and also bend.
The fax machine has two roles. First is that it supplies the player with information by printing what we want it. It knows when to print which set of papers, depending on what the player currently has to do. The papers are made by combining a couple of variables, such as the text on the paper, and the image on the paper. In the newer versions of the game, the information is baked as texture on the paper. Allowing for it to look authentic, and also bend.
|
|
Bend paper
|
The other thing the fax machine does is check the information that is contained on the picture, and references it with what the player is supposed to submit. The fax machine knows what pictures already have been submitted and can have multiple assignments active at once. An assignment can have multiple correct answers, and the puzzle designers can customize how many they need to find in order to complete the assignment.
About The Red Stare
The Red Stare is a room scale virtual reality game in which you are a detective on a stakeout. During the 1950s the American population was afraid of the threat Russia posed. The player tries to uncover the identity of a KGB spy that has hidden in this New York neighborhood, before they get away. The only play space the player has, is the apartment, which has a perfect view of the neighborhood and the inhabitants.
I was almost immediately involved with the development of The Red Stare, which started in early September. As a technical and AI designer I worked on making the tools and systems on which the mystery is based. The characters have certain actions they have to do and can do. Based on this information and the information you receive from other sources, the player can deduce who in the neighborhood is who.
This is the first time for me to work for such a long time on one project. The project has gone through so many changes because of its longer development cycle.
This is the first time for me to work for such a long time on one project. The project has gone through so many changes because of its longer development cycle.
The Red Stare started by embracing the limitations of room scale VR. Where other games fight those limitations by teleporting around the levels, we chose to have the entire game set in one apartment. Based on the Alfred Hitchcock movie "Rear window" the player never has to leave their home in order to solve the mystery of the neighborhood.
The game is still in development, and we hope to release a version of the game in July 2017.
Contact
|
|