This semester has been a blast! We got a lot of great work done, and I hope my team is proud of all the progress we have made within the scope of a semester. Here is the retrospect in which I discuss the outcome of the development process throughout the semester. 

Statistics

• Over the course of the semester 1,237 points were made for the project.
• 929 of those points were moved into complete.
• 308 points were left over in the backlog at the end.

Our average velocity ended at around 132 points per sprint. To reference the points left over at the end of sprint 7, there were a portion of them that were expected to be finished that were left incomplete. However, the largest section is due to scrapped ideas left sitting in the backlog earlier in the production process. Cards cannot be deleted from the Jira board, so there were a good few left over at the end that were not expected to be in the final product. 

What Went Right: 3D Models

There were no notable complications involving 3D modeling, everyone on the team did a great job! The game’s future funk art style and overall color scheme was maintained throughout the process, and many pieces had a good visual balance between futuristic and scrapyard junk. Here are a few of our favorites from each team member:

Rein Tice:

Tyla Chadwick:

Marcus Gill:

Alexander Britt:

What Went Right: 2D Art

There were a lot of great concepts that helped visualize the models and the world. All of the art stayed true to the desired aesthetic, and the poster, logos, and banner art represent the game perfectly!

Alexander Britt:

Janice Xiong:

What Went Wrong: Out of Scope

Expectations were unrealistic at the start. Many aspects of the game were out of scope, and it was not realized until later in the semester. This resulted in wasted time and unused models. There would be plans for tasks mapped out for each sprint, but if points were leftover it caused things to get backed up in the schedule. Over time things would get reprioritized and this resulted in half-finished projects that had to be scrapped due to time constraints and higher priority tasks. Here are a few examples of this issue:

• Attack bot enemy type - A 3rd enemy type was initially meant to be in the game.

• Variations of Enemies - There were supposed to be multiple different types of rogue bot enemies with different abilities. One of which being a bot that charges at the player and explodes.

• Interactable items in the scrapyard: The player was meant to be able to interact with most pieces of trash in the scrapyard and move it around. There are a few props here or there in the map that are interactable, but this was mostly scrapped due to time constraints.
• Functional Save System: Work was put into creating a save system for the first few sprints, but then it became apparent that our programmer would have to dedicate all of his time to updating the save system with new information after each sprint added in more changes. We decided to prioritize other game mechanics to ensure the core game loop would be present in the finished product. By the time we had a moment to potentially bring back the save system, there was too much work to be done for it and too little time. 
• Blueprints / Chassis mechanic: There was meant to be an entirely separate mechanic involved in unlocking new buildable robots. The player was supposed to go out into the scrapyard and find blueprints to robots, and once collected the corresponding robot would become available to build in the workbench. Again, due to time constraints we had to cut corners. Instead, the player can purchase more robots with credits from the dark web pc.
• Scrapyard Design: The scrapyard portion of the level was sized down significantly in order to ensure it could be finished within the deadline. Grand ideas of different scrapyard sections and environmental hazards turned to only about 3 different scrapyard zones. 

What Went Right: Level Design

Despite the large cuts made to the initial level idea, the design made was still a great end result. There was a clear vision of the map from the start, so when the cuts were made the designers were still able to work with the ideas for the remaining sections. The scrapyard design is very well done and feels like an actual future funk junkyard, and the workshop feels like someone actually lives there.

What Went Right: Animation

The animations done were small and simple, but very effective and helpful in adding a lot of character to the game. Without our animator’s hard work on the rogue bot enemy animations and player arm movements, the game would feel a lot more rigid and unfinished. 

What Went Wrong Unused Models:

There were 12 different buildable robots modeled throughout the semester, but by the final build, only 5 made it into the game. This was again due to time constraints and improper planning.

We did not realize how long it would take for robots to get implemented into the workbench for building. Ultimately, we had to prioritize bug fixes and a working game over more robots.

Unused robots:

What Went Wrong: Overworked Programmers

There was slow progress on most mechanics because programmers were often stretched too thin on multiple different mechanics at the same time. We should have taken this as a sign and cut things earlier rather than trying to have it all. The idea for the game started off way too large, we should have focused a lot more on the minimum viable product and built out from there once finished. Due to the scope being too overblown at the start, a lot of pressure was put on the programmers to finish mechanics in time for deadlines. A lot of the time things could not be completed within the deadline given. 

What Went Right: Programming

There was a lot of pressure put on the programmers, but the work they did create was very nice. They did a great job working together, communicating, and combining all of their work into one cohesive game. 

What Went Right: GDD

To give our game designer some credit, the game design document he created was very well thought out. It was an ever-expanding document that was edited throughout the semester, and it allowed the team to easily look to it for guidance whenever they needed it. It made my job as producer a lot easier as well, I could read the GDD when creating the backlog in order to accurately compile tasks for each sprint. By the end of production, the GDD was over 80 pages long. 

What Did We Learn?

• IMPLEMENT THINGS: We would have a lot more robots in the game if we had prioritized implementing them as soon as they were modeled. Should not have pushed it back so far.

• Completely finish one mechanic before moving on to the next. One thing 100% complete at the end of a sprint is better than 2 things only at 50%.

• Start at the scope of a minimum viable product. Be realistic.

• Have a clearer and simpler vision of the core pillars for the game from the start. Keep the core loop simple. Make decisions / changes early before it’s too late and time is wasted.

What Would We Do Again?

• Create a detailed GDD that covers the entire game

• Assigning programmers into designated features to prevent clashes (Enemies, Player, UI, etc…)
• Assigning 3D artists into different areas of the game (scrapyard assets only, workshop assets only, etc..)
• Trash cubes - this simple addition of a cube textured to look like compressed trash carried a huge role in the scrapyard’s feel.
• Clear vision for color scheme/ aesthetics from the start

Thank you!

Though the game is not as expensive as we previously hoped it would be, the end result of all of my team’s work is very impressive. To show how much work and progress went into the game, here is a side-by-side of the first build ever made vs. the final build we turned in a couple months later. Thanks for following us on our development journey! 

The start:

The End: