LANCE FREEMAN _GAME PROGRAMMER

Summary:
Prototype Roll: Graphics and Gameplay Systems Programmer

Production Roll: Lead Programmer and Systems Programming

​

SCORCH was the passion project of our lead designer Edison Estes. His vision was to make a multiplayer first person shooter where stealth was not only viable, but it was the optimal way to play. The way he sought to achieve this was a high contrast lighting system which would consist of white lit areas, and pitch black shadows. Granted in the end we created a single player experience, the light based stealth system was a huge focus on the project until the end.

​

I was on the original development team consisting of only five members. During that time I took on the responsibilities of getting our shader in order, and getting the basic FPS gameplay features into the game. At this time we still wanted to possibly shift to multiplayer if we made it through the selection phase. With this in mind, I was trying to develop systems which would be as networking friendly as possible. The first task I worked on was making a component based gun system which would allow for easy designer modifications using weapon templates. Each player would have a gun handler, which would at the beginning of a game use a given gun template to set the variables associated with the weapon. This would mean the same system would be able to handle anything from a single shot highly accurate sniper shot, to a high recoil max spread automatic machine gun. The next thing which I worked on was the shaders which would be utilized in order to give SCORCH its emergent stealth system, as well as its aesthetic. This was achieved through two shaders. The first was a toon shader, which we removed any step in shadows, so that shadows would be harsh cut offs, rather than fall offs. This made all objects in the scene that were lit become white, and anything else would become black if blocked from the light. The second shader was a post processing effect to outline the edges of objects to give definition to the scene and help with object context.

​

After presenting the project, we were lucky enough to be selected to continue working on the project in the next semester. This meant the team would expand, now to fifteen members. This was also the point when we decided to switch to a single player experience, since we had proven our single player model in the prototype, but hadn't proven the multiplayer viability. As one of the two original programmers on the project, I took up the roll of Lead Programmer. For the next few months I was working with the other four programmers, as well as the other leads on the team to bring the vision of SCORCH to life. Now that we had become a single player game, we needed to craft the systems to allow for a narrative to be told, while having single player progression. Of these tasks I was responsible for the save system, objective system, and evidence systems for the game. The objective and evidence systems were sort of intertwined, as the targets you needed to eliminate in the game were the ones who would drop the evidence. Utilizing the hit registration components on the AI, upon death if the AI was given evidence and set to be a target, it would increment the objective, as well as drop the evidence upon death. The objective was simple, kill five targets and return to the starting area. Apart from the planned two cutscenes at the beginning and end of game, there was no dialog to tell the story. So we took the approach of making the story a background piece, one which the player could invest in through the found evidence giving clues about the ending, or focus on the gunplay and never see the twist coming. The last major system I worked on was the save system, which would allow the player to respawn after death without needing to return to the beginning of the tutorial every time. While a simple reset the player and put them into position would have been fine, we wanted saving to be a bit more meaningful, and save your progress. So the save system would also take a snapshot of the currently dead enemies, collected evidence, and objectives completed. Upon a players death, they would be put back into the state just before they saved. Meaning a player couldn't just kill the same enemy five times and make their escape after dying repeatedly, or collecting the same evidence multiple times.

​

Apart from those systems tasks I was trying to manage the work flow of our shared repository. With fifteen people working on one project it is just asking for trouble, especially when some of those people aren't well versed in using version control. So I would often make myself available to teach other members of the team about how to go about accessing the repository. I also enforced guidelines on how the repo should be accessed, and when and where certain changes should be made. With a major push from our Lead Artist Jodi Moore this was further improved with a asset implementation schedule. This schedule would list the times when artists or designers would be working in the repository and putting in new assets, or making changes to the scene. This was put into place after a few instances of multiple members of the team making modifications to the scene, resulting in merge conflicts, which needed to be resolved manually, since Unity scene merge support is near non-existent. With all these measures, some of which were implemented later in the project, the project came to a smooth conclusion. 

​

In the end I am really proud of how SCORCH turned out, but I wouldn't mind taking the lessons we learned from our first go around to take another crack at it.