SCRAPS

SCRAPS POSTMORTEM

Introduction:

​

Three months ago we began down the road to SCRAPS. At first, we began small, building control stations and windmills, learning the tools of Unity. Then we began creating a game level by designing a map. There was simple instructions, choose two mechanics such as pressure plates or mechanical levers and create three interactions for each. Once we were finished and happy with our levels, guess what. Toss it away. Why? Because we were now introduced to our teams for the project and had to create brand new levels for the game SCRAPS. In SCRAPS, the player controls a junk salvager in a post apocalyptic world where most of the world has been destroyed. The wealthy few that could afford to survive, created massive super structures called Bastions. The people who live in the Bastions are now called Basts. The player, known as the Scrapper is tasked to gather items from the wastelands. The levels we were now instructed to make had to have this task in mind. After we created our new levels, we had to bring them together into one large scene, which brought about the next task of creating a seamless experience for the player to traverse through all our scenes without interruption. This three month project took us through the entire process of planning, designing, building, and shipping a complete game.

​

What went right:

​

1. Team formation.

In between month two and three of the SCRAPS project we had an additional class that covered game pitches. This class provided us with a randomly generated team. The students that we met during that month stayed together in the third month of SCRAPS, where we were able to choose up to three other people to form a new team. Each team had six available slots, and you could choose up to four members of the team from either online students or campus students. The other two slots, in our case campus slots, were left open for any other students to join our team if they wished, or in the case of a student who was not invited to a team, for the instructor to place into any team that had space. We entered the final month with meeting times prearranged and discord chat already set up. This was a huge benefit as we were able to begin working on bringing our scenes together immediately after the class started. We already knew each other from the previous class so there was no introduction period. We were able to hit the ground running.

  2. Testing.

The final month of the project was broken down into three weeks of work, the first being Alpha version, the second being Beta, and the third week was Gold. During the Beta week we were required to Beta test other teams projects and report the bugs that we found. Beta testing other teams work gave us some ideas on what we could fix in our own scenes, as well as having another set of eyes provide input on our work. One member of our team took it upon himself to fully Beta test our level and spent about 30-40 hours that week trying to find every bug in all of our teams scenes. As a result we were ahead of the rest of the class when it came to Gold week, where one of the major concerns was making sure the player was unable to leave the playable space. Because of his testing, we had already blocked the player from exiting the playable space during Beta.

  3. Level transitions.

Our team, having spent the last month and a half working together for at least three hours every other day had grown to respect each others ideas. When the task came around to add interactive level transitions between our scenes we got together and as a group talked about each scene and what could be a good transition to the next. This process only took an hour, and afterward we built the transitions. One team member was absent for this discussion, so we had to design a transition from his scene that he could add to when he decided to work again. The transitions ended up being smooth and seamless, each incorporating assets from the other scenes so that there is a natural feel to them.

  4. Team work.

The team really came together over the last few weeks of the project. If anyone needed help all they had to do was ask if anyone is available in the discord server and someone would get to their computer to help no matter if it was three in the afternoon or three in the morning. There was a point where a few members of the team needed assets created, so another member spent the next few hours creating and texturing the assets for them so they could continue with other work. We rarely worked alone on this project, and even when we were working alone we were still talking to each other in the discord channel.

​

What went wrong.

​

  1. Late addition to the team.

The team formation began on a Tuesday in the first week of the final month. We had pre-planned on who was going to be in our team and signed up the moment we could. All four of the online slots for the team were filled, and we did not think that any of the campus students would want to join our team. We began work, and laid out our scenes together. On Thursday of that week the instructor added a campus student to our team. We welcomed this new team member, added him to our discord server and began to bring his scene into our project. Unfortunately this new team member was not interested in working with us. Over the entirety of the three weeks we were working together he only spent an hour and a half on his scene. When we noticed a bug in his scene he said it was there by design or it would take too much time to fix so he was going to leave it there. During the second week he became very disrespectful to two of us and refused to even talk to the other two members of the team. We did the best we could to lead by example, and show him what our teams objective was through screenshots and video.

  2. Version control software.

We were required to use version control software to easily allow us to share our work with each other and the instructors. The software that was provided was Perforce. While Perforce is an incredible powerful piece of software, it is also occasionally difficult to understand. There were several times during the project that even after submitting our entire folder to the depot (Perforce’s server), another team member who downloaded that folder would not see the changes that were made. To fix that issue we had to make a copy of our folders outside the Perforce workspace, completely remove our folder from Perforce and then add the copy that we just made. This was a long and tedious process. At least twice the process took over two hours for our work to appear the same on all our computers.

  3. Animations.

Perhaps the most frustration we had during this project was getting the animations to sync properly on each of our computers. This issue may have been caused by Perforce, the version control software we were using, or it may have been an unknown Unity issue. With the rest of the team watching via screen share I would create an animation. It would work perfectly when I tested it in the editor, and would also work when I made a build of the game. Once my scene was sent to Perforce and downloaded by my teammates, the problems started. It would not work the same on their computers. One team member reported that the play animation didn’t run, while another noted that the stop animation would loop. Neither of them encountered the same issues. Eventually, after recreating the animations several times we were able to get a build that worked the same on all of our computers.

  4.  Audio.

No matter how hard the team tried audio seemed to always be an issue. Either the audio sources were too quiet or they were way too loud. A tester from another team reported that they had to stop testing due to how loud certain audio was. Another issue that occurred with the audio was that ambient sounds were being heard throughout the entire level, not just the scene that they were intended on being heard in. Eventually we scrapped most of the ambient audio and focused instead on the interactive audio. One member of the team didn’t even add audio to his scene. At the end of Beta testing we had successfully adjusted the audio to the desired levels.

Conclusion:

This three month long project has been an exceptional learning experience. The process of planning out our levels and then having to restart completely in the second month simulated the possibility that the studio you are working for gets bought or sold and the games design considerations have now changed. Working with a team that was randomly chosen taught us how to work with a variety of work ethics and team members who may or may not share our motivations. The process of planning, mapping, and then building the scene shed light into the entire game making endeavor. I can not stress how much we learned, both about making games and about who we are as designers. We discovered what we are good at and what we need to spend more time learning. We created something that we are proud of, and in the process formed great relationships. I can not wait to work with the members of this team again, or see what they create in the future.