Barracuda III came together for this project. The way we found each other was based on our different skills. For this project I took two roles: programmer and Team Lead. 

As a programmer it was my job to implement features into this game and assure that there were as little bugs as possible. Additionally, I was in charge of the version control (Github Desktop) and responsible for solving any merge conflicts that arose.

As the Team Lead, it was my job to work with every department (art, design, sound, and programming) to guide the design decisions, moderate team discussions and maintain a cohesive vision of the game. Additionally, I was in charge of solving any interpersonal conflicts between the team.

Before we even decided that we would move forward with The Kalidax Farming Program, each member pitched a game using a powerpoint presentation. Our teammates, however felt that these visualizations were not enough for us to really see the vision behind the games.

We decided to create paper prototypes of our games. I created the prototype for The Kalidax Farming Program. I drafted up a few rules on paper, created a board using a dry erase mat for Dungeons and Dragons, and made the playable pieces using some Warhammer 40 000 miniatures I had.

During this stage we each playtested each other's games to get a feel for how each of them played, and we collectively decided that we wanted to move forward with the Kalidax Farming Program. 

To track our tasks we used Jira Project Management software. Additionally we followed Agile Development and ran through Sprints and Sprint Reviews every week. 

Because of the busy semesters, each teammate was only required to put in 3 hours of work on this project each week. This meant that we needed to lower our scope so that we could finish the project on time.

We used Unity to develop the project, we thought it was the best engine to make the small scale game. Additionally, our teammates have the most experience in Unity, so we wanted to put our best skills on display for this project.

Our team created a Game Design Document to log all changes and all the features in the game. In this document all the features of the game are written down and expanded upon so that each member of the team would understand that what they needed to do as they created the game.

This is what I am most proud of. This inventory system allows you to pick objects up from the ground, it stores those object's data within the container. The player can then move the objects around their inventory to organize it.

This inventory works as a tool that the Game Designer can use to expand and shrink the inventory size to improve the UX for the player.

There are two things that you can sell in this game in order to make money: items, and aliens. I created the framework to sell both. When the player interacts with the provisions drone (left) a menu appears, and if they press the sell button, all items in their inventory disappear. At the end of an in-game day, all the money earned appears back in the player's wallet.

I created a singleton script that doesn't delete itself whenever a new scene/level begins. This keeps track of when the player will receive their funds, and how many funds they gain.

We coined this term "gene splicing". In our games there are some aliens that wander around the world, there is an object called the Gene Splicing Pod where you can combine two smaller aliens to create a new bigger and more valuable alien. 

To achieve this, I needed to work with both scriptable objects around the scene, and I needed to create a list of all the alien game objects to assure that we can delete the objects that are no longer needed.

This endeavor was a combined effort between myself and the programmer who created the UI that you see in the pictures on the left. Each scriptable object has two things that that we needed for the process. On the front end, the sprites that you see on the screen are attached to our little scriptable object and that's what we put onto our UI. On the backend however, we are taking an ID that each object has to make sure that each one has the same ID. If they have the same ID and are not the same object, then we allow the merge to happen, and voila, there is a new alien created.