Spring 2016 (9 Weeks)

Summary

Azimuth is a Capture The Flag (CTF) style First Person Shooter (FPS) set in alien temple where players control an advanced race of alien warriors and attempt to resurrect their god. Pulling similarities from the aesthetics and mindsets of earth’s Aztec Indians, the characters and environment blend ancient energy, temple rock, and Sci-Fi metal. Set at the onset of a rare equinox, two teams of four warriors scour the temple to steal the enemy’s totem and resurrect their own god before the equinox ends.

Roles and Responsibilities

Job Title: Lead Programmer

• Work with faculty advisor and team to create technical direction
• Create and keep planning documents/sections current: GDD, ADP & ADB sections
• Code game components
• Keep Scrum Board current
• Generate the build at the end of each milestone
• Approve code assets
• Generate tasks and time / effort estimates
• Keep aware of technical issues & find solutions for team to use
• Adhere to the Asset Database for file formats, size and naming conventions
• Use Perforce to manage all artifacts and work from the latest build
• Apply unit testing to all assets created before checking into Perforce
• Adhere to the Build Plan asset locks
• Test game as part of the build verifications
• Use Issue Manager to record bugs and checks for assigned issues at the start of the workday
• Prioritize tasks according to the Scrum Board
• Complete Peer Evals
• Serves as go-to technical support person (e.g., Perforce)
• Support game networking needs and delegate networking tasks
• Leading departmental meetings
• Attend leads meetings
• Gather and communicate programming concerns from other departments

Total Manhours: 114.6

 

Features

Main Menu

In this shot, you can see the game’s Main Menu. As the Lead Programmer, I made sure to take on the smaller but important tasks of the game so that my fellow programmers can focus their attention on bigger tasks, like our Weapon’s Charging mechanic. For the Main Menu, I worked on the Host Game and Join Game functionality, which allowed players to create and connect to Azimuth matches.

 

Meteor Launcher

In this shot, you can see the weapon that I worked on: the Meteor Launcher. It has two fire modes, a shotgun and a charged meteor shot.

The shotgun fires a randomly distributed spread of bullets in a cone in front of the player. The bullets deal enough damage to instantly kill an enemy should they get too close.

The secondary mode fires an explosive Meteor that deals a large amount of damage in a radius of the explosion. Fragments of the meteor go flying after it collides with a target. The longer you charge the shot, the farther the meteor will go.

The challenge I faced when developing this weapon was not the functionality of it, but the networking. Many times during development, a weapon or feature would look perfect when tested locally. However, once you added another player, the second player’s view of the weapon or feature could be vastly different than what was intended. To fix this, the programming department and I researched Unreal Engine’s Replication properties and learned that we must tag specfic variables and components as “Replicates”, then choose the correct Replication mode. The correct Replication mode could be either “Run Only on Server”, “Run Only On Client”, or “Multicast” which runs on both client and server. While this may seem simple at first glance, the complexity lies within the intertwining of the Replcation modes, as some features may be Client Only up until it needs to send something to the server. Proper knowledge of what Replication modes to use can save a lot of time debugging during development.

Kill Tracker

In this shot, you can see the Kill Tracker I worked on. On the top right of the screen, any time a player is killed a message is sent to the server containing the data of the killer, the victim, and the weapon used. The server then maintains the time to show for each message, and prints out the same message to all of the clients.

The challenge I faced when developing this feature was designing the correct infrastructure for the messages. My first attempt involved sending the Player Character reference in a Struct, but after some painful debugging it was soon discovered that the Player Character reference gets removed upon death, leaving the messages with an unreliable source of data. The solution to this problem was to break down the data at the moment of the kill, and store the relevant information in it’s raw form (such as Killer Name, Killer Team ID, Weapon Used, etc.). By doing this, I could ensure that the data would not be tampered with once stored, and I can easily add or remove kills to the list without confusing the conveyance of the data.

Download