A SCRAPS postmortem by Matthew Mathis

What once was is now no longer…

This is the story of a world in shambles with multiple societal casts that dictate the quality of life throughout the world.  This is the story of SCRAPS.  Scrappers are sent out into the wastelands to retrieve scraps of things leftover from a time when the world was still in one piece.  But our story had nothing to do with getting any old junk left around the world.  Ours didn’t bother worrying about the cast system or the morality of sending another person out on a potential death mission just to get some dusty old can of soda.  Ours was about the preservation of the last known piece of music in the world. The only beautiful thing left in a world devoid of beauty.

We were lucky in as much as having the core elements of the story and gameplay laid out for us beforehand.  Our team set out to make something that would take the preexisting SCRAPS story to another level. We had heard what other teams had done before us and we wanted to make something a bit different.  While other teams would be recovering items, we were recovering music.  Going after the intangible seems like a very difficult but worthwhile mission indeed.

 

What went right?

 

Dreams – By Thomas Gaff

Finding the right piece of music was far easier than we thought it would be.  Early on the team decided to use the idea of a world devoid of music except for one last rumored piece of it.  But with music comes usage problems.  We couldn’t just take any song off of the radio and place it in our game.  We needed something that was fitting to the mood of the game, but was available, and that the composer provided consent to use. It all fell into place at the end of the first week.  While surfing Twitter I stumbled across a post by composer Thomas Gaff, a close personal friend of mine, talking up his upcoming album.  So, letting curiosity get the best of me I followed the link to the sample clips he had and there it was: Dreams.  It had the right feel, it had the right ambience, and it was the right length.  It was perfect.  One of the hardest elements to procure fell right into our laps.  I called Thomas up and asked if it would be okay if I added it to our game and he immediately said yes with the simple caveat: just give me credit, done. That provided the footing with which to base the rest of the game off of.

 

PerFORCE your updates

Our initial impression and thoughts of Perforce (the software used to keep everybody’s workspaces synced up throughout the project) were honestly, abysmal. It felt clunky, user friendliness was out of the question, and the documentation to use it was basically written for a high level programmer to skim through as toilet material.  It seemed hopeless.  During the entire first week we struggled with un-textured materials and work reconciliation not coming through in the depot.  Thankfully we quickly discovered that it was a user side error and that the program was actually very efficient at the task it performed.  During the second week we had some major issues with uploads not coming through, it ended up with a team meeting in which we walked each member through the process of getting the latest revision of the software and uploading their changes.  This ultimately led to the ability of team members diagnosing problems in other members builds and being able to quickly implement the changes on their side and FORCING them over to the other persons client.  This allowed us to debug the game at a pace that would not have been possible using any other method.  This form of forced streamlining led our build and compile times to decrease dramatically each week from 2 minutes in the ALPHA week, to 45 seconds in the BETA week, and finally to less than 10 seconds in GOLD week.

 

All your SCRIPT are belong to me

One of the challenges we faced was to resolve the problem of each team member writing their own scripts for the same function.  Initially this was not a problem, but when you have four different scripts for opening doors or sending a GUI message it can become a problem. We were making Unity save memory slots and think about scripts that all did the same thing, but had to have their own reference.  One of our most successful steps toward optimizing the game was the use of consolidated scripts.  We made a few scripts that had universal functionality.  By toggling serialized Boolean statements on a universal trigger script the designer could toggle audio, text, an interaction, wake up another object afterwards, destroy an object, play an animation, trigger a story sequence, activate a respawn location, or even adjust the setting of the over world such as toggling the world light on or off and setting the world darkness to the appropriate level at the appropriate time. Hell, we could even deal damage, play a sound, update health, update speed, and track the player location, all with the use of one or two scripts working in tandem.  Getting the world optimized by using similar scripts also reduced the bugs we had to chase in the long run, since changing the master script would resolve ALL similar problems throughout the world.  This in tandem with perforce meant that a developer could state a problem, a scripter could go type a line of code, and it would update everything it needed to, resolving the problem and any future problems that could have been caused in similar situations, all without ever actually touching the other designers scene.

 

Nice desktop background bro!

Skype played an instrumental part in our team’s success during this project.  It was the main method of contact between all of the team members and the screen sharing functionality allowed team members to share visually the exact problem they were experiencing.  On more than one occasion we had team members who claimed that the problems in their world were resolved, but when everything was checked in the persistent scene on another computer, the problems were not resolved.  Initially this resulted in small skirmishes in which each person was trying to prove that their work was functioning as intended.  Skype put the kibosh on all of that by allowing us a simple and quick way to confirm or disprove the functionality of a specific build of the product.  Often this lead to an advanced reconcile or a forced update of perforce to resolve the issue.  Without it the debugging process would have been so much more painful than it ended up being.

 

What went wrong?

 

Did you just touch me bro? I’m pretty sure you just touched me.

We had a pretty significant problem with colliders throughout development.  We literally had items falling through the world all the way up to the GOLD build.  While the implementation and use of colliders is really simple and straight forward we ran into a few case situation in which it caused nothing but headaches.  On occasion an asset would be considered “open” and when a mesh collider was attached to it Unity would spam the screen with critical errors, occasionally leading to a lockup of the system.  It was discovered, in the last week, that some of our team members were attaching colliders to empty game objects, causing the error.  This was happening because some of the assets consisted of multiple sub assets combined and held in place by a parent object, which was empty.  Colliders were being applied to the parent object, with the expectation that it would place a mesh collider around the entire object.  Well, it didn’t, and you know the rest…

 

You said “15 minutes”, it’s been 2 days…

One of our team members was consistently absent from the team.  Throughout the month he would sporadically show up and get work done.  The main problem was that his work would just appear in the depot without anybody knowing about it and the team would then have to spend time debugging the new problems that just basically appeared overnight.

 

You’re breaking up; I think we are losing our connection…

Being a team of individuals everyone had a different time slot that they were available for peak production.  Some of our members did the majority of their work at night well into the wee hours of the morning.  Others did work in the morning, and left by early afternoon.  Some had to deal with circumstances that required their time be spent elsewhere for unknown amounts of time while still others just didn’t show up.  The team was almost never in full sync which slowed our production cycle significantly.  This was most apparent when work was all but halted while waiting for an update from another designer. While this marred the team throughout the month there were moments of clarity and it eventually led to the development of the unified script to allow for offline alterations to be made to other designer’s scenes without requiring them to be online or interacting with their world directly.

 

Pride comes before the fall

Some of the team members were not happy about the use of universal scripts to consolidate the functions of the game.  This resulted in certain areas of the world being less optimized than others due to their refusal to use the assets.  It also resulted in lengthy debugging sessions during which time the best method of solution was screen sharing with others and explaining what it happening, and how to fix it.

 

Takeaways (Advice)

 

Don’t overreach but don’t sell yourself short. 

During the first week, make a level you think you can make, and then scale it down. Your lofty ideas are likely bigger than you have the time to achieve during this class.

 

Treat it like all you can eat sushi or a buffet.

Don’t try to build an entire encounter at one time.  Pick one of the elements of your level and get it working perfectly.  Then you can move on to the next one.  Don’t do anything just halfway.  If you got only halfway, it should be scrapped (forgive the pun).

 

Don’t get ahead of yourself.

Do what is required per week, don’t get ahead of yourself.  Don’t worry about polish in the first week. Get your systems working, get your puzzles up and functioning as intended, debug them, and do it again.  Short of throwing a quick texture on pink objects, don’t worry about that until week 2.

 

Learn perforce early.

Don’t wait until the end of week one to make sure everyone understands perforce and how to reconcile and submit.  Get the entire team understanding perforce and its use as early as possible.  This will save you so much trouble in the long run. Also, DON’T DELETE THE DEPOT. Got that?

 

Set a deadline and stick to it.

Don’t use the end of the week as the deadline for submissions.  If everyone submits on Sunday, that leaves you NO TIME to debug and test.  Require a submission from every team mate by Friday at the latest, then you have the weekend to tweak it and fix problems. This does not mean that once you submit on Friday you are done, you can still work on it during the weekend, but if you haven’t turned anything in until Sunday, how is the PLK supposed to stitch the world together or how are you supposed to bug test the whole world? Simple answer: You can’t.

 

If you saved, SUBMIT, unless….

This one is simple as it gets.  If you just saved your project in Unity, upload it to the depot.  If it was important enough for you to save on your end then surely it is important enough to backup. You’ll thank me later.  The only exception to this rule is if you have a critical error in your scene.  If you submit a scene with a critical error in it, DOING THAT WILL PREVENT EVERYONE ON THE TEAM FROM WORKING ON THE PROJECT. Don’t be that person.

 

Disable your FPC!!!

Before you submit, disable you FPC and ensure your level is working as intended.  Believe me; not having to search the hierarchy for a pesky FPC who is ghosting around the level triggering all sorts of random stuff is worth the 1 second it takes to disable it before saving.

 

Conclusion

 

For whom the bell tolls…

Overall this project was a fun and exciting undertaking.  Along the way we had our highs and we had our lows but overall we came out on top.  From a purely personal standpoint this was one of the best experiences I have had at Full Sail up to this point.  It allowed me to flex my creative muscles but it also led me to a deeper understanding of what a team project will be like in the future.  A deeper understanding of many programs followed the tasks that were required throughout the weeks.  I learned more things about Unity than I previously knew, I learned a bit more about re-mastering audio using Adobe Audition, and I learned texture creation in Fireworks, Paint, and Illustrator.  I learned light mapping and creating glowing materials.  I discovered the usefulness of linking scripts up to each other both through the inspector and by getting components from unlikely places.  Last but not least, I learned that a team can achieve a lot more than an individual can.

 

References

Simche [username].  (2014). Sound of Music HD CLEARLOGO [image]. Retrieved from https://fanart.tv/movie/15121/the-sound-of-music/