BVW Round 5: Space Bar
When: Oct '18 - Nov '18 (3 weeks)
Where: Entertainment Technology Center, CMU
Roles: Rigging, Game Design, Animation, 3d Modelling
Team Size: 5
Platform: HTC Vive
Tools: Autodesk Maya, Unity, Perforce
'Space Bar' is an asymmetrical co-op bartending experience designed to entertain naive guests at Carnegie Mellon's 2018 ETC Festival. The main objectives for this project were replayability, intuitive gameplay and enjoyability. The experience was selected as 1 of 16 to be showcased at the festival.
What is BVW: BVW (or Building Virtual Worlds), is the premier course for first years at CMU's Entertainment Technology Center. It is composed of 5 rounds spread throughout 1 semester. For each round, you're put in a random team of 5 (composed of 2 programmers, 2 artists, 1 sound designer) and the team is tasked with creating a complete AR/VR experience in the span of two weeks. After the 2 weeks, teams are shuffled.
Above: A walkthrough of the entire experience.
Art: As artist, I came up with several character designs for crazy looking aliens with personality. Given the timeline though, we restricted ourselves to just one character in an effort to manage scope.
Above: Character design concepts.
Blob (pronounced Bob because the 'L' is silent) was the character I chose for the world. With Blob, I took the opportunity to implement a rig that supported squash and stretch. Blob's spine was driven by an IK spline which gave him realistic shoulder and hip movement. He was also given an FK spine for more minute control over different sections of his spine.
Once the basic skeleton, controls and IK handles were set up, I proceeded to add the stretch and squash. Basically, I wanted the spine joints to scale alongside the curve of the IK spline. Used 'Node Editor' for the IK spline's curve, created a 'Spine Info' node to get the real-time height of the spline curve. Dividing this value by the curve's original length using a 'MultiplyDivide Node', I was able to deduce the percentage change in length of the curve. Then, I simply applied this change to the appropriate axis of the scale value for all of Blob's spine joints. For volume preservation, I inversely scaled the other two axis of the scale value for Blob's spine.
Above: A showcase of the rig's squash and stretch functionality.
I animated the character and exported a single FBX accompanied by a text file with frame-by-frame breakdowns of all the animations.
Above: Walk cycle for posh Blob.
Above: Walk cycle for commited Blob.
Technical Challenges: My final task regarding Blob was to import him into Unity for the programmers. In Unity I faced what seemed to be an issue of double transformations in the scaling of my geometry mesh (compared to Maya), particularly for areas skinned to joints that had IK spline.
A check in Unity’s console revealed an FBX import warning saying “Scale Compensation is not supported by Unity”, and that “might result in scale imported incorrectly”, with a list of the affected joints. The solution was to “try disabling Scale Compensation in your file”.
After some research about the issue on the internet, I went back to Maya and turned off thr ‘Segment Scale Compensate’ attribute for all joints associated with the squash/stretch spine. That actually recreated in Maya the double scaling problem I had in Unity, and to solve that I went back to the Node Editor and removed the scaling I'd added to all the children joints.
This is because ‘Segment Scale Compensate’ (checked by default) tells the joints down a chain to ignore the scale changes of their parent joint(s). When it is unchecked, scaling the top joint in the chain applies the same scaling change to each joint down the chain, even though you don’t see the change in the scale value in the channel box. This is how Unity reads the scaling of the joints, which is why my geometry ended up scaling a whole lot more when I was scaling all the children joints individually in addition to the parent. The scale changes compounded down the chain of joints.
Game Design: We started out with having separate Vive Play Spaces for both guests. Each had access to a unique colored soda and garnish. They'd have to communicate to fulfill orders. With this version of the game, the division of labor seemed forceful and wasn't something the world absolutely demanded. Throwing garnishes all the way over to the other player's Play Space was also hectic and punished guests way too often.
We quickly switched to having both guests in a single Play Space and kept everything else as before. With this, the multiplayer nature of the experience felt unnecessary.
For the next iteration, we defined more distinct roles for each guest; 1 was incharge of the sodas, the other for the garnishes. The soda guest had too easy a time filling the glasses. To solve this, we moved the soda guest to a higher virtual location making the soda-dispensing more challenging. For the interest curve and making the soda guest's life more challenging, we had the garnish dispensers catch fire and become useless based on how good the guests did. At this stage, it was just a lot of iteration for balance.
Notable Experiences:
What is BVW: BVW (or Building Virtual Worlds), is the premier course for first years at CMU's Entertainment Technology Center. It is composed of 5 rounds spread throughout 1 semester. For each round, you're put in a random team of 5 (composed of 2 programmers, 2 artists, 1 sound designer) and the team is tasked with creating a complete AR/VR experience in the span of two weeks. After the 2 weeks, teams are shuffled.
Art: As artist, I came up with several character designs for crazy looking aliens with personality. Given the timeline though, we restricted ourselves to just one character in an effort to manage scope.
Above: Character design concepts.
Blob (pronounced Bob because the 'L' is silent) was the character I chose for the world. With Blob, I took the opportunity to implement a rig that supported squash and stretch. Blob's spine was driven by an IK spline which gave him realistic shoulder and hip movement. He was also given an FK spine for more minute control over different sections of his spine.
Once the basic skeleton, controls and IK handles were set up, I proceeded to add the stretch and squash. Basically, I wanted the spine joints to scale alongside the curve of the IK spline. Used 'Node Editor' for the IK spline's curve, created a 'Spine Info' node to get the real-time height of the spline curve. Dividing this value by the curve's original length using a 'MultiplyDivide Node', I was able to deduce the percentage change in length of the curve. Then, I simply applied this change to the appropriate axis of the scale value for all of Blob's spine joints. For volume preservation, I inversely scaled the other two axis of the scale value for Blob's spine.
I animated the character and exported a single FBX accompanied by a text file with frame-by-frame breakdowns of all the animations.
Above: Walk cycle for posh Blob.
Above: Walk cycle for commited Blob.
Technical Challenges: My final task regarding Blob was to import him into Unity for the programmers. In Unity I faced what seemed to be an issue of double transformations in the scaling of my geometry mesh (compared to Maya), particularly for areas skinned to joints that had IK spline.
A check in Unity’s console revealed an FBX import warning saying “Scale Compensation is not supported by Unity”, and that “might result in scale imported incorrectly”, with a list of the affected joints. The solution was to “try disabling Scale Compensation in your file”.
After some research about the issue on the internet, I went back to Maya and turned off thr ‘Segment Scale Compensate’ attribute for all joints associated with the squash/stretch spine. That actually recreated in Maya the double scaling problem I had in Unity, and to solve that I went back to the Node Editor and removed the scaling I'd added to all the children joints.
This is because ‘Segment Scale Compensate’ (checked by default) tells the joints down a chain to ignore the scale changes of their parent joint(s). When it is unchecked, scaling the top joint in the chain applies the same scaling change to each joint down the chain, even though you don’t see the change in the scale value in the channel box. This is how Unity reads the scaling of the joints, which is why my geometry ended up scaling a whole lot more when I was scaling all the children joints individually in addition to the parent. The scale changes compounded down the chain of joints.
Game Design: We started out with having separate Vive Play Spaces for both guests. Each had access to a unique colored soda and garnish. They'd have to communicate to fulfill orders. With this version of the game, the division of labor seemed forceful and wasn't something the world absolutely demanded. Throwing garnishes all the way over to the other player's Play Space was also hectic and punished guests way too often.
We quickly switched to having both guests in a single Play Space and kept everything else as before. With this, the multiplayer nature of the experience felt unnecessary.
For the next iteration, we defined more distinct roles for each guest; 1 was incharge of the sodas, the other for the garnishes. The soda guest had too easy a time filling the glasses. To solve this, we moved the soda guest to a higher virtual location making the soda-dispensing more challenging. For the interest curve and making the soda guest's life more challenging, we had the garnish dispensers catch fire and become useless based on how good the guests did. At this stage, it was just a lot of iteration for balance.
Notable Experiences:
- Implemented rig that supports squash and stretch in Maya.
- Learnt about Unity's limitation with the "Segment Scale Compensate" attribute in Maya.
- Successfully imported an animated squash and stretch rig from Maya into Unity.
- Themed an entire room to create a complete experience