Spy on communist spies from your apartment window!
The Red Stare has been released for free on Steam on the 31st of July 2017. The Red Stare is a roomscale VR game for the HTC Vive and Oculus Rift in which the player plays as a private eye setup in a 1950's New York apartment stakeout. The player is confined to the inside of the apartment and has to use a variety of tools and gadgets to figure out what is happening outside.
The Red Stare has been released for free on Steam on the 31st of July 2017. The Red Stare is a roomscale VR game for the HTC Vive and Oculus Rift in which the player plays as a private eye setup in a 1950's New York apartment stakeout. The player is confined to the inside of the apartment and has to use a variety of tools and gadgets to figure out what is happening outside.
DETAILS
|
My Roles: Technical Game Designer, Gameplay Programmer & Build Master
Development Team: Play:D Team Size: 7 - 17 Platforms: HTC Vive & Oculus Rift (roomscale) Engine: Unreal Engine 4 Development Cycle: September 2016 - August 2017 Release Date: 31st of July 2017 Website: http://theredstare.com Steampage: http://store.steampowered.com/app/625470 Reception: The Red Stare is currently at a 95% positive rating on Steam. Additionally, multiple very positive gameplay videos were recorded with some videos reaching over 100k views. We are currently working on bringing The Red Stare to VR arcades across the USA and South-Korea. Awards:
Nominations:
|
|
MY WORK
On The Red Stare, I was primarily focused on creating and prototyping all of the different player interactions. Using rapid prototyping techniques I tested various possible implementations of mechanics, and ultimately created final gameplay systems.
Additionally, I worked on optimisation (making sure we hit a stable 90fps at a high level of super sampling), Steam Integration, Oculus Rift & PSVR support, and maintaining build stability by managing a Jenkins server (continues integration software).
For more detailed descriptions of some of my tasks expand the tabs below:
Additionally, I worked on optimisation (making sure we hit a stable 90fps at a high level of super sampling), Steam Integration, Oculus Rift & PSVR support, and maintaining build stability by managing a Jenkins server (continues integration software).
For more detailed descriptions of some of my tasks expand the tabs below:
Technical Game Design
As a technical designer on The Red Stare I worked on all major gameplay features related to player interactions. This role is very wide and covers all types of technical implementation and design work. My primary role as a technical designer is to design, prototyping, iterate on, and polish a large variety of systems. This is mostly done using Blueprints, and occasionally C++ (whenever C++ is preferable). Some of the systems in The Red Stare that I've worked on are: camera, pictures, fax-machine, phone, interior parallax, outline material (with occlusion) out of room fade, and many more.
Some development videos of systems I have worked on:
Some development videos of systems I have worked on:
|
|
|
|
|
|
A good example of how I like to work is the Interior Parallax system:
- Identify a problem: The other buildings will not have characters in them, but look somewhat strange without interiors. Modeling and decorating interiors would be needlessly expensive.
- Research solutions: There are techniques of faking depth. Mainly, interior mapping and interior parallax seemed like good candidates.
- Test Solutions: Rapidly prototype both techniques in engine. From this I concluded that interior parallax is the better option due to ease of use and flexibility. Interior mapping has limitations on the room size and shape and only works well with flat surfaces.
- Create and iterate on implementation: Creating a pipeline around easily capturing parallax mapping. Make it as easy to use as possible.
- Optimise: Make sure that the system does not waste any performance (static material instances, baked blur instead of real-time blur etc.), clean up blueprints to make possible handovers easier.
- Teach: Show how to use my system to the developers responsible for capturing and setting up the parallax textures.
|
|
Build System (Jenkins)
With long running projects the idea of build stability becomes much more important. Because of this, we wanted to have a very robust system that would allow us to always have a stable build ready, and immediately catch issues when they are created. Before I implemented Jenkins into our pipeline, builds were made less than weekly, and most of time time required someone taking time out of their day to wait for the build to be completed and resolve a whole slew of issues. This sometimes took hours!
With the current implementation of the automated build system, I poll the perforce project folder every 5 minutes for changes. When changes are detected, I download the changes and automatically start the build process. When a build succeeds it is compressed into a .rar file and added as an artifact to the build in Jenkins. When a build fails, it will send a notification that pings the people directly involved with the commits that broke the build. This means that at max 10 minutes after someone committed something game breaking, they will get a notification that they broke the build that includes the log file. This makes detecting and fixing issues very fast.
With the current implementation of the automated build system, I poll the perforce project folder every 5 minutes for changes. When changes are detected, I download the changes and automatically start the build process. When a build succeeds it is compressed into a .rar file and added as an artifact to the build in Jenkins. When a build fails, it will send a notification that pings the people directly involved with the commits that broke the build. This means that at max 10 minutes after someone committed something game breaking, they will get a notification that they broke the build that includes the log file. This makes detecting and fixing issues very fast.
Image 1
Image 1 shows what a build looks like in Jenkins. You can see the build number, the revision number, and the slack username of the person that made the change. Additionally, the description tells us how many errors and warnings there are, and shows us what the exact changes contained in this build are.
|
Image 2 shows an example of the notification posted in the #_builds slack channel. The people responsible for the changes are pinged, and the changes are shown.
I also implemented some extra features to make this system even more useful. Mainly I created custom slack slash commands that we can use to trigger builds. '/makedevbuild [(optional)build name]' triggers a build immediately (no matter if there are changes or not). This is useful for creating milestone builds. '/pushtosteam [build description]' creates a release ready build and uploads it through the Steam Pipe! This build is instantly set as the active build on the development branch of our Steam app. The steam build system is separate from the normal system so we get an extensive list of all the changes between each Steam build. |
Image 2
|
Because of this system QA has a constant pipeline for builds:
- Permanent link to the latest build (at max 10 minutes out of date).
- Steam development branch, updated daily/when necessary.
- Steam release candidate branch for testing release pak builds that might be released.
- Steam default branch, the live game.
Creating this system has been incredibly fun! I've learnt a lot about how computers and networks work internally, and how you can interact with a lot of different software from the command line. Additionally, I've learnt about a lot of different protocols, languages, and software such as Batch, Shell, Cygwin, Rsync, SSH, FTP, SteamPipe, Jenkins, unreal build system etc. The system is also a great help to the project in making sure that we can always test and show the latest revisions on a build instead of in editor.
The system also uses the Unreal Automation system to tests the builds created whenever possible, and makes these results available to team.
The system also uses the Unreal Automation system to tests the builds created whenever possible, and makes these results available to team.
Optimisation
As we are targeting the HTC Vive, running at a stable 90fps is very important for the best user experience. For this reason, we spend a lot of time profiling the game using various tools such as the Unreal Engine Session Front-end and the in-game/editor profiling tools. Constantly going through this process has taught me a lot about rendering such as when to use what rendering pipeline (forward/deferred), what AA methods to use, and the costs of different effects, and general optimization. And has allowed the game to run at a stable 90fps with 130% super sampling.
