Released on
The Red Stare is a room-scale VR game about spying on communist spies from your apartment window.
In The Red Stare you act as an American agent in the 1950s on a stake out. Gathering evidence on your neighbours, figuring out what role they play with the goal of eventually 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.
In The Red Stare you act as an American agent in the 1950s on a stake out. Gathering evidence on your neighbours, figuring out what role they play with the goal of eventually 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.
|
|
|
My work
Dynamic VR Room-scale (Tool Programming)
I worked as a Tool programmer to speed up workflows and processes for the team. Being a room-scale VR game, one of the tools (and probably the most important one) I worked on is the 'Dynamic Room Scaling' system. This tool adjusts the apartment interior at construction/run-time to the player's playspace, meaning the game remains playable no matter how big or small the available space is.
It also prevents people from hitting their heads against their real-world walls, which is a serious issue that I would advise every developer to take very seriously!
It also prevents people from hitting their heads against their real-world walls, which is a serious issue that I would advise every developer to take very seriously!
Old art assets, but the system functions the same.
|
|
|
While working on this system, I closely communicated with the environment artists to establish a modular workflow for the creation of the apartment art assets, as well as making the tool as accessible and user-friendly to both the artists and designers. Without this tool, we would have been forced to either stick to the smallest apartment size possible (which is frustrating when more space is available), or create a multitude of apartment meshes for every possible room dimension; signifcantly increasing workload. In addition to reducing the workload, this system also prevents players from bumping into real-world, physical objects (such as walls); as the apartment is uniquely constructed to each player. In other words, the virtual walls align with the player's real walls. |
| ||
|
Out of bounds fading system
I co-developed an out of bounds system for the aforementioned system. If the player steps outside of the 'safe play area', the game fades to black and highlights the safe area and important elements. This is to discourage people from walking any further and colliding with their real-world physical walls or similar objects. The visuals were done by Martijn Dijksen. |
Dynamic Lighting at 90 FPS
|
|
|
The Dynamic Light System is my implementation of a fully dynamic day/night system in The Red Stare running at 90 frames per second.
History
One of the problems throughout development was the lighting quality, as the team did not have a dedicated lighting artist. Despite the many high-level ideas and some ground-work done, it had always been the main factor of the game not looking remotely as great as it could.
In the last 2-3 months of development, I completely took over responsibilty of the lighting, having no prior experience with lighting in a serious manner (I am not an artist), but I was confident in my ability to fix this on-going issue.
History
One of the problems throughout development was the lighting quality, as the team did not have a dedicated lighting artist. Despite the many high-level ideas and some ground-work done, it had always been the main factor of the game not looking remotely as great as it could.
In the last 2-3 months of development, I completely took over responsibilty of the lighting, having no prior experience with lighting in a serious manner (I am not an artist), but I was confident in my ability to fix this on-going issue.
|
Approach
To resolve a lot of the problems and speed-up workflow signifcantly regarding this, I wanted to create a fully dynamic, physically-accurate lighting system that runs at 90FPS. One of the main aspects I wanted to immediately address was the lack of any sense of progression. Previously, the lighting artist worked on 2 different 'lightmaps': 1 for day, 1 for night. Although lightmaps are advised for VR games (as they are precomputed / offline-rendered, hence quite inexpensive), the problem this caused was both performance and gameplay (stuff needs to be rendered in <= 11ms in VR!). Because lightmaps are static, they have to be manually loaded. Previously, we would swap between the day and the night lightmaps at run-time. Since a lot of data had to be loaded onto the memory, swapping between these would cause significant frame hitches, resulting in a very poor experience (the player would get booted out of the game for several seconds!). On top of this, there was also the question at what moment we would swap between the two lightmaps. Since there is no seamless transition between the two times of day, the game instantly switch to day OR night. There were some suggestions to mask this, but most of these were very unwelcoming to the player (e.g. manually close the blinds? swap when the player is not looking outside?). From a gameplay point of view, the time of day was also very important for events to happen. The puzzle designers could decide that at sunset, NPCs have to gather in a specific spot. This would have been impossible to reflect with a static, binary system like this. |
A very early performance test
|
Research
As mentioned earlier, I am not an artist, so I spent a fair amount of time on researching physical models of natural lighting (since I wanted physically-accurate results).
With my inability to not stop working on the project, I would go outside and take pictures early in the morning and late at night as reference for how I wanted the lighting in the game to look. The main aspects I was observing while doing this was shadows, lighting colour, skylight colour, indirect shadows, and general intensity.
As mentioned earlier, I am not an artist, so I spent a fair amount of time on researching physical models of natural lighting (since I wanted physically-accurate results).
With my inability to not stop working on the project, I would go outside and take pictures early in the morning and late at night as reference for how I wanted the lighting in the game to look. The main aspects I was observing while doing this was shadows, lighting colour, skylight colour, indirect shadows, and general intensity.
|
|
|
|
|
Optmisation
Performance was a The Red Stare is a virtual reality game for HTC Vive and Oculus, hence the game needs to run at at a relatively consistent 90 frames per second. Optimising this system usually resulted into "what can we do without?" situations: what parts of this mesh don't have to cast shadows? This was the first time I did any serious work with lighting and cloud simulation, so I spent a lot of time on observing and researching the sky and the sun. I would wake up early in the morning to take photos of the sky and see its features, then recreate that in the game. As a result, the lighting in physically-accurate. |
|
Distance Field meshes for optimised shadows
|
Clouds I experimented a bunch with raymarched (volumetric) clouds. While visually these were very realistic and interesting, they were very taxing on performance (as we need to hit 90 on VR HMDs!) Instead, I decided to make the cloud simulation much cheaper, and as a result, more subtle. |
|
Serialisation / Save Management
|
|
|
As the project got further in development, the puzzles becoming more advanced and expansive, and the game being VR, it became very apparent that we needed a serialisation / save management system.
The most challenging and important aspect of this was the serialisation of the pictures the players can take of suspicious activities. This was quite important for gameplay reasons, as pictures of events that happened earlier in the game may be needed as evidence for assignments later in the game: so there was no way to get away without a save system.
|
Render Targets
The Camera object in The Red Stare uses a render target, which is a memory buffer where the video card draws pixels for a scene that is currently being rendered. This is applied to material plane on the Camera, which is the little image display on the camera. The moment the player takes a picture, the render texture creates a dynamic material instance of the current scene, which is then applied to the polaroid picture object. The player now has a polaroid picture of the thing that they made a picture of. |
Render Target on the camera.
Dynamic Material Instance created on the picture.
|
|
Storing 2D Textures to Disk
Just before the player quits the game, the game gets all the actors of BP_CameraPicture and gets each material (what is actualy on the picture) and stores this onto the disk. The system is structured in such a way that is differentiates between a number of parameters and stores the 2D textures in their respective folders. It first generates a folder based on the UserID (to ensure players on the same system using different Steam accounts don't overwrite eachothers saves). It then differentiates between what scenario is currently activate (ScenarioOne or ScenarioTwo) and finally stores each picture as a string value that is incremented: generating a result as seen on the right. It also serialises data such as all Picture transforms, current assignment, and data structs on each picture which is used to see if the player has faxed in the correct picture to progress to the next assignment (i.e. identity, location). |
|
Getting and Serialising all the colours in the material. Base system written by another programmer. I had to refactor some elements.
|
Serialising all in-game objects
|
Storing the material and colour array as a 2D texture to the disk and generating the correct file paths and names.
|
VR Physics-based interaction
I worked on a physics-based interaction system for the game. This system prevents objects the player is holding from clipping through geometry and walls. Additionally, it helps increasing the immersion of the game and its interactions.
It became very clear over the course of development that a robust system was needed to prevent important entities from being lost to the player if they happened to push an object through what should be a solid boundary in the real-world: walls for example. It's a very interesting example of dissonance between VR and real-world affordances.
The system went over several iterations:
It became very clear over the course of development that a robust system was needed to prevent important entities from being lost to the player if they happened to push an object through what should be a solid boundary in the real-world: walls for example. It's a very interesting example of dissonance between VR and real-world affordances.
The system went over several iterations:
- Trigger volumes that spawn/teleport objects back into the apartment if they happen to go outside of it. (hack)
- Force the held object to be dropped if it's halfway through geometry. (less hacky)
- Physics-based, collision detection, and impulses if an object is held. (final implementation)
Default implementation
|
Physics-based interaction
|
Shaders and Render Textures
|
Organisation of information is key to the gameplay of The Red Stare. For this, I developed the BlackBoard, which allows the player to both place pictures and draw onto it.
This was done using render textures and drawing dynamic materials on to it; the technique is pretty similar to how footsteps in snow or watersplashes are rendered and deformed in a lot of games nowadays. |
| ||
Details Status:
Platforms: HTC Vive & Oculus Roles: Creative Director, Technical Designer, Gameplay Programmer Developed by: Play:D Release date: July 31 Official website: http://www.TheRedStare.com/ Steam page: http://store.steampowered.com/app/625470/The_Red_Stare/ Team size:
Development cycle: September 2016 - present Engine: Unreal Engine 4 Duties: Gameplay systems implementation, lighting Awards:
|
|
|
|
|