Our discarded (and broken) menu by made Tucker Apy.

This month I had the pleasure of working on a level together

with five other individuals. The level was for a game called Scraps. Scraps is set in a post-apocalyptic world. We had to stay close as possible to the creative vision as possible. Over the course of development we encountered several issues but the experience wasn’t all bad as there were several things that went right for us.

What Went Right The first thing that went right for our team was the selection of

the theme. We decided early on to pursuit an abandoned school as our setting. While selecting rooms was initially difficult we all eventually embraced some gameplay themes and found our motivation.

The second thing that went right was the environment. Everyone genuinely wanted to help each other. This led to multiple hour-long screenshares and/or quick short screenshares as everyone got feedback and/or help with their area. I believe this eventually helped up the quality of each of our individual areas in the final product. The third thing that went right for us was our willingness to improvise. You’ll read soon about our issues with our file sharing application but what is more noteworthy is how we came together to circumvent this situation. The afflicted member would upload his folder to Google Drive, another member would download it, paste it into his students folder to overwrite the old file, and reconcile.

Everyone stepping up like that is the fourth thing that went right for us on this project. Every time we had an issue someone would step up into a position and attempt to make something happen. For example, I worked with our instructor Derek through a good portion of our Tuesday in week two to solve our P4 issue. This led to a fix that got everyone working with P4 again. This didn’t last long for everyone but it was a permanent fix for the majority. The fifth thing that went right was our troubleshooting as a team. Granted, this went terribly wrong in week two. You will read about that shortly. The important thing is that that incident is the lone exception. There was several occasions where the team would brainstorm together or take on troubleshooting tasks for the entire team in order to fix an issue that wasn’t just their problem. A good example is the frame rate issue. I worked on this extensively by myself until someone got on to help me test the builds. I had to boot into windows to test, back into OS X to change, and then back again. After a teammate got on I would upload the test files to Google Drive and he’d test my various experiments. This eventually identified the problem that another teammate and I would later work to fix. I’m proud to say that Alex Lee finally solved the turret riddle that was causing our turrets to eat up massive amounts of memory and processing power.

My area was a classroom modified by a previous tenant to resemble a maze.

What Went Wrong Our first and biggest issue was P4. A lot of us didn’t read as much as we should have on the subject. Maybe we all learn by doing rather than reading. In any case this led to multiple issues with the file sharing application. Our folder was wiped during the second weekend. This caused all sorts of issues for us and it took until Wednesday to get everything sorted out for everyone. Despite that two members still had prolonged issues reconciling their work. They didn’t manage to get them resolved until the final week. One of those team members was the week two level keeper. We actually had more issues than that regarding the persistent level keeper position. The PLK is supposed to preside over the persistent level that streams all our area into one scene. The PLK for week one came around increasingly less frequent as the month went on. It didn’t get any better with our second week PLK because he had issues with P4 that persisted up until the final day.

No one else had read the PLK section on the FAQ so restoring our project settings was a matter of “Who wants to step up?” This was altogether our second pitfall. It is also directly because of problem number three; our roles completely broke down. Few people followed their assigned roles outlined in the charter. An absentee production lead did little to rectify this situation.

This organization problem also greatly contributes to problem number four; when we did try to do something there was often too many chefs in the kitchen. This was most noticeable during week two as the PLK with the most knowledge and experience was gone while the second was struggling to get P4 working. Everyone tried stepping up at once and it only made everything worse. A few people had to reconcile their files again and eventually the entire student folder was wiped.

Our last huge issue was our failure to compile early and often. This is partly because everyone would push their work to the last couple of minutes leaving us little time to compile, upload, download, and playtest. This is noticeable in our gold version as a door script component was changed to “missing” during the upload/download process. Not only that but my featured asset was still crashing the game. This was a build specific bug that did not show up in Unity playtests. It also did not show up on the OS X platform. It was specific to crashing the game in windows builds.

I implemented a fix for the asset issue but my ceiling renderer was forgotten and left off. I uploaded that fix and went back to working on my door not working. The problem was that by that point, despite the easy fix when I actually looked at the door itself, we were

too pressed for time. My door fix and renderer for the ceiling were left out of the gold product.

Here is my whiteboard concept’s evolution over the course of

development.

Advice to future students First and foremost, LEARN P4. This gets stressed a lot in this

advice column and for good reason. My biggest issue was I learned more hands on. It would be beneficial if you read the PLK section of the FAQ too. Having said that you need to compile early and often. Adhere to your deadlines. At the very least you need to remind yourself and your team the day before submission that your work is good enough and spend the due date doing nothing but compiling and testing for build specific errors. We had several errors that would pop up in the build but not in Unity playtesting. This gave us a world of headaches and cost us on our grades.

Overall, despite our shortcomings as a team in combination with our technical difficulties, I would rate this as a positive learning experience. Sometimes you do not know how you will react when some of the worst things that could go wrong actually go wrong. But this month I learned more about Unity and something about myself in the process. I learned about Perforce. Version control is an amazing thing and I cannot see myself not using it going forward. I also learned more about Perforce than I likely would have had we not struggled with it so. The one-on-one exchange of shared screens with our instructor gave me valuable insight that comes from trial and error coupled with hands on experience. More importantly I met and got to work with some great people and I am confident that on the next opportunity we have to work together that we will do better.