My Personal Role: Production and lead programmer.
Client: Columbia College Chicago (Indie Team Capstone Project)
Client: Columbia College Chicago (Indie Team Capstone Project)
Aegis Colony is a first person shooter where the player is a tower defending a generator from oncoming machines. Toy robots move at the player's generator and attack unless the player blasts them away with their heavy cannon. The game continues until there are no more robots for the player to fight.
Players: Single Player
Controller: Mouse and Keyboard
Players: Single Player
Controller: Mouse and Keyboard
My Contribution
In this project I acted as a producer and lead programmer. I handled functionality across the project from enemy AI to player controls and was responsible for implementing all of the assets produced by my fellow team members. Away from the keyboard I also acted as somewhat of a lead during team meetings. I helped to distribute tasks and pointed out errors with assets to ensure the project was made smoothly, everyone knew what they should do, everyone's voice was heard and that all of the project meshed together as intended.
My TEam
Eric Andruszko - Eric was very devoted to this project. While his tangible contributions were mostly restricted to UI implementation and environment design he was active in every team meeting and passionate about carrying the project forward. He always had another idea to make the game better even if many of them couldn't make it into the final cut.
Joshua Duffy - Joshua got to have fun with this one, modeling and animating the "FloatBot" brute enemy and the player's own turret seen in the menu screen and in the main level. He is resposible for the art drawn for all of the UI elements seen in the final game as well.
Melina Espinosa - Melina was responsible for a lot of this project's direction whether she knows or not. Her decisions with color pallete as well as her model for the basic enemy and environment objects really populated the game with much of the style that it has. We didn't even know what we wanted for enemies until she arrived with the model for that lightbulb-headed bot.
Anthony Flores - Anthony was not on the project long before leaving for a new one, only about two weeks, but he still managed to make a lasting impact. He picked out a free package of particle effects on which we based every explosion and particle in the game, all were an edit on assets from that original pack.
Chris Bokowy & Greg Levinson - Chris and Greg were our primary contributors on the sound team. Every bang and ping in the game came from them. The sound team was largely detached from most of production due to there not being enough members to support how many capstone projects were going on in the school at the time, so I didn't get to see much of them at the time. Their contributions were pivotal to the project nonetheless, every time we added new sound it just brought so much more life to the project.
Macy Camille - I didn't get to meet Macy over the course of production but she was a composer in the school's music program who wrote the main level's music inspired by our description of the game's high concept.
Joshua Duffy - Joshua got to have fun with this one, modeling and animating the "FloatBot" brute enemy and the player's own turret seen in the menu screen and in the main level. He is resposible for the art drawn for all of the UI elements seen in the final game as well.
Melina Espinosa - Melina was responsible for a lot of this project's direction whether she knows or not. Her decisions with color pallete as well as her model for the basic enemy and environment objects really populated the game with much of the style that it has. We didn't even know what we wanted for enemies until she arrived with the model for that lightbulb-headed bot.
Anthony Flores - Anthony was not on the project long before leaving for a new one, only about two weeks, but he still managed to make a lasting impact. He picked out a free package of particle effects on which we based every explosion and particle in the game, all were an edit on assets from that original pack.
Chris Bokowy & Greg Levinson - Chris and Greg were our primary contributors on the sound team. Every bang and ping in the game came from them. The sound team was largely detached from most of production due to there not being enough members to support how many capstone projects were going on in the school at the time, so I didn't get to see much of them at the time. Their contributions were pivotal to the project nonetheless, every time we added new sound it just brought so much more life to the project.
Macy Camille - I didn't get to meet Macy over the course of production but she was a composer in the school's music program who wrote the main level's music inspired by our description of the game's high concept.
TakeAways
I got to work on a long form project with an excellent team. Communication was the cornerstone of our process and without my group members being so responsive and willing to listen to each other’s concerns and advice we would never have gotten as far as we did. We were only required 9 hours of active work on the project every week including meetings which means the final piece is about 16 work days of effort from each of us. I guarantee we exceeded that requirement, in fact I recall one week tripling that time just because I wanted to see some features realized. I got to solve deeper, more math intensive problems and work with making code accessible to other group members for balance tweaking in the editor. I do think we could have included more but we focused intensely on ensuring everything we put in the project was finished and easy to understand for the player and sacrificed some extra features to ensure that that happened.
Highlights and comments
I worked through a lot of problems on the project. I had to write code in a test level that could be easily transitioned into new environments as they were created, while in the current version we chose to forgo creating more levels in favor of improving the experience on the one we have I made a conscious effort to ensure that my script could be moved between scenes such that a designer just needs to drag a prefab into the new level and assign the variables and all objects and systems will function just the same as in the test level.
A unique issue was with the waypoint arrow. That was one of the only tasks that stonewalled me for a time. Fortunately most of the coding queries that come my way tend to be solved with ease but as it has been in most of my classes since starting my studies into programming, I was stumped only by a problem that also stumped my professor. He offered to help but trouble arranging meetings ended with me solving it myself.
That little Red arrow gave me so much trouble.
How I solved that waypoint problem (caution, coding jargon):
I used a modified version of a script I found online while looking up ways others have accomplished a similar effect, the waypoint in particular was difficult to find in unity, at least in a way that was well documented enough to learn from. The script I used was made to achieve that waypoint effect on a game where the camera does not move or rotate and as such experienced a problematic glitch when the camera would turn. The arrow would flip its x and y positions whenever the player faced more than 90 degrees away from the object it was tracking. After exposing variables along the steps of the calculation I found the flip was a problem with the WorldToViewportPoint function and though I couldn’t find anything in unity’s documentation about the actual calculation occurring with that function I was able to find a variable attached to it that is negative only when the flip is occurring and reversed the x and y coordinates of the arrow when that flip happened. Then after offsets and rotations I was able to get the arrow pointing at an object that I wanted with only a bit of hassle.
I used a modified version of a script I found online while looking up ways others have accomplished a similar effect, the waypoint in particular was difficult to find in unity, at least in a way that was well documented enough to learn from. The script I used was made to achieve that waypoint effect on a game where the camera does not move or rotate and as such experienced a problematic glitch when the camera would turn. The arrow would flip its x and y positions whenever the player faced more than 90 degrees away from the object it was tracking. After exposing variables along the steps of the calculation I found the flip was a problem with the WorldToViewportPoint function and though I couldn’t find anything in unity’s documentation about the actual calculation occurring with that function I was able to find a variable attached to it that is negative only when the flip is occurring and reversed the x and y coordinates of the arrow when that flip happened. Then after offsets and rotations I was able to get the arrow pointing at an object that I wanted with only a bit of hassle.
I have acted in somewhat of a production role in the past though Disco Fever Dream’s production ended up being something of a mess over events I could not control. This project gave me another shot at being a producer and I definitely felt like one this time. My professor’s advice was to concern myself with every problem that could be holding back the project and I feel that I did. I was leading group meetings, pointing out problems with the product whenever they were found. I distinctly remember one day I was giving advice to one of my artists about an animation they made having a skip. With little to no knowledge of 3d modelling or animation at the time I explained that a looping animation needed to start and end at the same frame. Though that care to detail would be useless were my group not so responsive and willing to listen to me, it was another problem solved in one day’s worth of effort.