Wwise Interactive Music Demo by Jacob Pernell

Hey team,

Reposting this excellent video tutorial that Jacob Pernell (the extremely talented composer behind the music of Failsafe) made for an interactive implementation of music for one of Failsafe's tracks. It's fascinating and sounds delicious.

This is a demo track I wrote for a game called Failsafe and interactive music implementation of the track using Wwise. Failsafe (failsafegame.com/) is a parkour exploration/adventure game currently in development by Game Over (gameover.la/). For this track, my intention was to have your 'flow' increase in game the more successful parkour moves you chained together. As you increase your flow, the music fades in more layers and switches to more intense parts of the track. This video walkthrough is a proof-of-concept of that system. (Disclaimer: this 'flow system' and music track are not necessarily representative of the final product that will end up in the released game!)

Shout-out to Jordan Chin (twitter.com/jordanchinmusic) for the incredible acoustic guitar playing, Michael Evans (twitter.com/Vgcellomusic) for the awesome solo cello performance, James C. Hoffman (twitter.com/JCHoffmanMusic) for some mixing tips, and a special thanks to Steve Green for some last minute Wwise consulting (twitter.com/ShriekStudios)!
***
jacobpernell.com
twitter.com/jacobpernell

Failafe Devlog VI: Dynamic Limbs

Hey everyone, Evan Hemsley here!

We've been working hard on revamping the animation system. Since Failsafe is a game that is grounded in physical interaction with the environment, we have long felt that we would like our animations to be more reactive. 

Most first-person games use completely different animations for first-person and third-person. Imagine that you are playing a first-person shooter, where the main character is constantly carrying a gun. A major issue is that the gun points out from your character, so if you walk up to a wall, the gun will appear to be going through, or "clipping", through the wall. Most first-person shooters solve this problem by drawing the first-person model and animations after the rest of the world has been drawn. We have chosen not to go this route because we feel that it creates a disconnect when interacting with the world. We also don't need our character to carry large weapons or anything like that. Of course, having the player's extremities clip through walls or the ground is also very jarring. How do we prevent this from happening?

Here is our solution:

Every time the position of a hand is going to be updated, we perform a spherecast* from the corresponding shoulder to the location where the hand is going to be placed by the animation. If the spherecast detects a collision with the environment, we take note of the location of the collision, as well as the normal of the surface. Now we can place the hand at the point of collision, instead of at its animated position. The same procedure applies for the feet as well, except we use the corresponding thigh instead of shoulder.

The problem of rotation remains: we wish to align the character's hand relative to the surface of collision. We can think of orientation in 3-dimensional space as being composed of two vectors* - a forward-facing vector and an upward-facing vector. Imagine that there are two vectors emerging from your right hand - one pointing our from your fingers (the forward-facing vector) and another pointing out from the back of your hand (the upward-facing vector). These vectors describe the orientation of your hand. If you take your hand and place it on a wall, you will notice that the upward-facing vector will be the same as the normal vector of the wall. Our forward-facing vector points up towards the ceiling. Now we can use these vectors to describe a rotation that positions the hand neatly against the wall. 

There's a problem though - what if the surface against which we press our hand is slanted? What if we press our hand against the floor? Now our forward-facing vector should not be pointing upwards at all. To solve this issue, we take the vertical component of the surface normal vector, and use it to interpolate between the player's up vector and the player's forward vector, and then project that interpolated vector onto the collision surface. In simpler terms, the more horizontal the surface normal vector* is (i.e. with a vertical wall), the more vertical our forward-facing vector in the rotation needs to be. Now we have a rotation that properly aligns the player's extremities to any surface that they collide with.

Here's what the calculation looks like in Unity C# code


transform.position = environmentHit.point + (environmentHit.normal * (collisionCastRadius + 0.002f));
Vector3 forwardDirection = Vector3.ProjectOnPlane(Vector3.Lerp(player.transform.up, player.transform.forward, environmentHit.normal.y), environmentHit.normal);
transform.rotation = Quaternion.LookRotation(forwardDirection, environmentHit.normal) * Quaternion.Euler(collisionNormalRotationOffset);
 

The result is quite satisfactory.

*Spherecast: A procedure that projects a sphere of given radius along a ray and returns collision information if that sphere collides with an object.
*Vector: A mathematical structure used to represent data such as points or directions in n-dimensional space. 
*Normal Vector: The vector perpendicular to a surface at a given point.

Failsafe Devlog V: The Concept Art Workflow

Hi everyone! My name is Noe Leyva, I joined the Game Over team to help out on the art side of things as a concept artist for Failsafe. I’m going to talk a little bit about the process used in the creation of the concept art, as we narrow in on the aesthetics that will define the final look of Failsafe.

Most video game projects undergo a series of visual changes from the moment of inception to the very last stages of their completion. It is not very often that the consumer gets an inside look at these “visual steps” throughout the development process. Part of what makes it exciting to work for an indie game company is the transparency in which games are made. From a fan’s perspective, I consider that having an inside look at the game making process is a treat and a great source for education.

When I first joined Game Over, I was asked to create a piece that would serve as a point of reference for the mood and visual style for Failsafe (shown below).

Although, in its current state, Failsafe features a somewhat different appearance, many of the elements featured in this image are still called upon in the creation of current art.

If you check out past development logs by our awesome crew, you can see some in-game footage of Failsafe. What you see there, is a much more stylized appearance. In developing the aesthetics for Failsafe, taking inspiration from animated films and nailing down a more stylized animated appearance is a goal of ours. Although none of the art seen here is final, we hope to achieve a look that complements the narrative and scope of the project.

When creating a concept art piece, I often call upon the help of 3D aids to set up a scene. This is something that is commonly used and provides many advantages for artists and helps others visualize a 3D space in a clear manner. Shown below is a proposed waterway scene, that is quickly built in a 3D program. Here I can play with the camera angle and lighting, until a composition is decided upon.

3D scene

3D scene

Final composition

Final composition

After I choose a composition for the image, I export a screenshot from the 3D program and into a photo editing program where I add various details and decide on a mood that the scene will take.

Final concept scene

Final concept scene

As you can see, most of the elements were in place from the 3D render. By adding some environment details that further portray a sense of decay, as well as adding our main character for a better sense of scale, we can consider this image done.

It is both a pleasure and a source of great fun coming up with images that directly affect most aspects of the development process in Failsafe.I look forward to sharing more art as we continue work on Failsafe!

Failsafe Devlog IV

Hello! I’m Seiji Tanaka, the creative director at Game Over.

July was a pretty busy month as we had two public events where we exhibited our gameFailsafe. These were both small-scale events so they were perfect for showing our game publicly for the first time.

The first one was a collaboration between Riot Games and Glitch City where over a dozen indie teams were invited to the Riot campus to show off their games. The event was open to all Riot employees and a couple hundred outside people.

A collaboration between a tiny indie collective like Glitch and a financial behemoth like Riot might at first seem like an odd mix, but once you learn about the massive respect they have for the indie scene, it starts to make sense. I was excited to exhibit there, but I had no idea what to expect since I had never attended a gaming event of that nature. It turned out to be a great experience for everyone, and there was a lot of engagement with the players. One thing that really stood out for me was the fact that everyone was very willing to actually play the games. This might seem like a funny thing to mention regarding a gaming event, but at all other events I’ve attended, people were generally rather hesitant to pick up the controller, even when offered. Perhaps it is the fact that the audience was mostly game developers as well, so they were more interested in gameplay.

Also worth mentioning is that we managed to include Failsafe‘s new time trial mode, which Evan touched on in the last devlog. The key features of this mode was the leaderboard that stored the top 5 scores, a “ghost” of the top player, and a level designed specifically for competitiveness. As we had hoped, this created a level of engagement for the player with the game as well as other players. We saw many players attempt the time trial repeatedly to try to reclaim the throne, which gave us some reassurance on the replayability of the game.

I couldn’t give enough props to Riot for the amazing job they did planning, setting up, and running the event. They were incredibly accommodating, going above and beyond to make it as painless as possible for the devs. They provided each team with a table, two monitors, and a workstation for those of us who only had one portable machine. All we had to do was basically show up, plug our laptops in, and then at the end just unplug and walk away. Huge bonus points for their kitchen serving delicious food free of charge to everyone throughout the whole event.

I’m very grateful for the opportunity to participate in such a unique event and excited to see how Riot will continue to help indies strive in the future.

Exhibiting at Riot Games’ campus

Exhibiting at Riot Games’ campus

The second event was at a gallery space called Giant Robot 2, as a part of the bi-monthly Game Night event, organized by @AngryBananas. Here we had the opportunity to project our game onto the building’s white wall. Since the game was in the complete open, right next to a busy sidewalk, we were treated to a wide variety of players ranging from couples to groups of teenagers to families with children. Despite the array of demographics, most people were able to understand what the game is about without too much trouble. The build was not too different from the Riot version but the few improvements and tweaks that were included proved to be effective. Thanks to the Time Trial mode, groups of people who lingered would take turns trying to beat each others’ scores, having good laughs while they’re at it.

The highlight for me were when the children, around the ages of 8-10, were getting really into the game and kept coming back, watching and playing. One of the first people who played that night, who happened to be one of such children, regularly showed up to play again, was also the last player before I packed up. Often times, as a game developer, I experience self-doubt about the validity of my game, and nothing clears up that feeling like seeing the uninhibited joy and immersion of a child who is experiencing the game I created.

Showing at Giant Robot 2 was uniquely invigorating, as showing your game with a refreshing breeze of a cool SoCal evening is not something you get to do often, and the generally relaxed atmosphere kept my stress level very low throughout. Many thanks go out to@AngryBananas for inviting us, and we are definitely down to do it again in the future.

Failsafe projected at the Giant Robot Game Night

Failsafe projected at the Giant Robot Game Night

Failsafe Devlog III

Hello everyone! I’m Evan Hemsley, a designer / programmer on Failsafe.

Once our time trial system was implemented, it seemed like an obvious decision to add some sort of replay function. It’s nice to be able to watch a really great run that you pulled off. One of the best things about racing games is being able to race against ghosts. Improving your time trial score is like competing against yourself – replay ghosts make that sense of competition a lot more tangible. Ghosts let you compete against other players as well.

How do you go about implementing a replay function?

The easiest way to implement a replay function is to simply capture video and then play it back. Unfortunately this has huge drawbacks in terms of file size – if the player’s rendering resolution is high enough, even short replays would take up hundreds of megabytes of space. Furthermore, if the player wants to race against themselves, there is no way to accomplish this with recorded video.

Essentially, any game is just a type of simulation environment – the program exists in a certain state, and the program’s state is updated based on various rules driven by inputs from the player. So, when you want a replay, what you really want is for the character’s state to change in the same manner as it changed when you were playing throu gh the level.

Our first attempt: on each frame, we capture each element of the player’s input – which buttons they were pressing, holding down, or releasing, and the axes of the joysticks. Then, we just replay those inputs in the same order as they were entered. Unfortunately, our player character’s movement is driven by the Unity physics engine, and the Unity physics engine is not deterministic – this means that even if you perform the exact same inputs on two different runs, the behavior of the player character might differ between the two runs. With this system, our replays would usually desynchronize and become inaccurate.

To get around this, we record the player’s input except for movement-related inputs. We then store the input data along with the player object’s position and rotation data on each frame. On playback, we set the player’s position and rotation on each frame, and update the player’s state (jumping, swinging, etc.) by replaying the button presses. Voila! A perfect replay!

Failsafe Devlog II

Hey y’all, Uli here.

The team at Game Over has been developing our current game Failsafe for the better part of 7 months now. It’s gone through several different identities and iterations, but it’s only been a couple of weeks that we have something in our hands that’s in a state that can be called “fun.”

So why wasn’t it fun from the start? What was the magic sauce that we put in the game to make it fun? No idea. Was it just the latest mechanic – swinging – that we implemented? Not necessarily, because mechanics within a game do not exist in isolation. The swinging wouldn’t work without the other parkour elements, and THOSE wouldn’t work without all the fine tuning we’ve done in and around the player motor. Fun is too ephemeral and fleeting of a feeling to nail it down in a design document with any certainty. It’s something that emerges from all the aspects of your game put together.

At least, that’s what I thought until very recently. On one of our test maps, I whimsically decided to create a brutal section at the end that I like to call the “Tower of Terror.” Yes, I know there’s a Disneyland ride with the exact same name, but it’s a tower and it’s terrifying and I really hope nobody sues me.

The way I created the ToT was haphazard and dumb; the only way to get to the Tower is to make a gigantic leap with a swing that – honestly – I wasn’t even sure was possible when I placed it. There are other swing blocks rising up around it that eventually lead you to the top where you need to hit a Mount Midoriyama-style button to finish the climb.

The Tower of Terror is unnecessarily difficult and badly designed. I didn’t even modify any part of it after I created it, I just tried the jumps until I knew they were possible and called it a day. It should be the shining example of something that is definitely NOT fun.

Then, we implemented a time trial. And a scoreboard. Since then, we have been having a ridiculously fun time around the office just trying to one up each other’s Tower of Terror times. Does that mean that, after a certain threshold, competition is the only ingredient for making something fun? Is Dust2 in CounterStrike GO really the best multiplayer map ever made, or is it just played so often that people have come to romanticize it? Will we ever be able to quantify fun?

I don’t know. I’m just a lowly gameplay programmer. With a TTT (tower of terror time) of 38 seconds.

Failsafe Devlog I

Thank you everyone who’s been keeping an eye on our work for the past few months. We’d like to share a bit more about the project we’ve been working on here at the studio. Let’s get right into it.

Failsafe is a first-person adventure game that stars Isra (voiced by Ashly Burch) and her companion, “the Robot” (voiced by Dante Basco). You play from Isra’s perspective, utilizing aMirror’s Edge-esque parkour movement style to navigate and explore an abandoned subterranean robotics facility. As you progress through the overgrown ruins of the facility, your Robot companion will help you navigate environmental puzzles by manipulating the facility around you, making it more accommodating for Isra’s agile movements.

In the video below  you’ll see an example of Isra’s movement mechanics in a speed-run prototype. Enjoy!

This footage is taken from an early prototype and is not reflective of the game’s final quality.