Capstone - Semester 2 Week 7

By: James Keats | 02 March 2018

Hard to believe we’re just about halfway there! It’s easy to see that the game is starting to shapeup. Here’s what I did this past sprint:

Team Gameplay

New Team-Based Arena Art

One of the biggest changes this week was the addition of team-based gameplay to re[Mod]. This is something we’ve been planning since last semester, and never had a chance to get around to. The idea was always to have two separate teams, an orange team and a blue team. Currently, the two teams just fight it out in a team deathmatch, but if we get the chance, we’d like to add some sort of objective for them to work towards. Ideas for this include a point-based system where capturing stage areas wins extra points, giving those objectives more weight beyond just their value for legendary parts.

Implementing team mode turned out to be simpler than I thought. One of the core tenants I kept in mind during this process was that all game logic should be fully compatible with both standard deathmatch and team deathmatch. This lead to a lot of extra “if” statements and checks, but makes the backend game logic more flexible going forward. Based on the direction provided byCharlie, our lead designer, I set it up so that teams are assigned when players connect, all friendly fire damage is ignored, and players HUDs and first- and third-person viewmodels are updated so that they appear to be on the right team.

An orange player's HUD
A blue player's HUD

Team gameplay is going to add a lot to re[Mod] going forward, and I’m excited to see where we can take it with the point system we’ve discussed.

Face Animations

Another addition that we’ve all been looking forward to adding to re[Mod] was facial animations for the character. This has a much more minor impact on gameplay than team mode, but is still something we’ve all been waiting excitedly for. Tyler, our lead artist, provided me with a sprite sheet of faces to display on the player:

New Scorecard

Unfortunately, we quickly discovered there was no easy way to utilize this in Unity when an individual face needed to be applied to a model. We could’ve stuck a SpriteRenderer in front of the player’s face despite having a dedicated portion of the mesh and material ID for it, but that felt dirty. We could’ve split the texture into 9 different ones, but that felt wasteful. In the end, I ended up writing another custom shader that essentially acts as a SpriteRenderer but can be attached to normal meshes, as long as the sprites are evenly spaced and sized:

#pragma vertex vert
#pragma fragment frag
#pragma multi_compile_fog

#include "UnityCG.cginc"

sampler2D _MainTex;
int _SpriteCountX;
int _SpriteCountY;
int _CurrentSprite;

// input and appdata structs, and vertex shader go here

fixed4 frag (v2f i) : SV_Target
       // Calculate the UV size/range of each sprite in the spritesheet
       float newRangeX = 1.0f / float(_SpriteCountX);
       float newRangeY = 1.0f / float(_SpriteCountY);

       // Find the x and y position of _CurrentSprite
       uint xPos = _CurrentSprite % (uint)_SpriteCountX;
       uint yPos = (_SpriteCountY - 1) - (_CurrentSprite / (uint)_SpriteCountY);

       // Adjust our uv coordinate based on the sprite range and position
       i.uv.x = (i.uv.x) * newRangeX + (xPos * newRangeX);
       i.uv.y = (i.uv.y) * newRangeY + (yPos * newRangeY);
       fixed4 col = tex2D(_MainTex, i.uv);

       // apply fog
       UNITY_APPLY_FOG(i.fogCoord, col);
       return col;


Weapon Part Animations and the Gunpedia

The rest of my time this week was spent on more minor features, like weapon part animations and giving the “Gunpedia” a facelift. The former was simply a matter of hooking up animators, and the latter was just working with Charlie to rearrange some UI elements, so nothing of a particular technical note there. Keep an eye out for the weapon part animations in future videos! They’re most noticeable on the grenade mechanism, rocket mechanism, and minigun!

Back to blog