SCRAPS: Post Mortem

Introduction

My name is Robert McSheffrey. For the past several months, I have been going through the paces of designing a video game level from start to finish. My level began as an idea: make your way through a school while evading security cameras and completing puzzles. From there, I turned the idea into a bubble diagram, map layout, and block out. I crafted and tested prototypes, and iterated on my setups and configurations until I achieved the product showcased in the Alpha review. For the last month, I teamed up with fellow game designers to link our SCRAPS levels to create a seamless, 4-level game play experience. I gained valuable insights to level design, and even though everything did not go entirely as planned, I am still proud of the work my team mates and I have accomplished.

What went right

1. Finding a diverse team: All students began this project working alone. We developed bubble diagrams, pitched mechanic and level ideas, and built prototypes all on our own. We constructed playable block-outs before reviewing our peers’ work and selecting teams. I was immediately drawn to a level that featured crumbling floors and the use of the flashlight to open doors. Within a few days, Team Garnet was formed. Fortunately, we all had experience working with at least one other person on the team. Jeremy and I worked together in the Building Functional Groups course, as did Christian and Jordan. Each of us brought unique skills and knowledge, team members to learn from and mentor each other. Some were talented with terrain, some very talented with materials and textures, and others provided clear and coherent quality assurance and feedback. The diverse talents allowed Team Garnet to produce a high quality product worthy of final release.

2. Well documented QA: As stated above, well documented and detailed feedback was critical in our completion of the product to the highest degree. The snipping tool in Windows makes it very easy and efficient to take screenshots of bugs. In addition, each member not only provided accurate accounts of the bugs in question, but they also made clear suggestions to the involved parties. As a result, bugs were identified and squashed in a timely manner.

3. Creating functional setups: I went into this long-term project with very little experience in designing a level or mechanics of my own. I wanted the level to feature security cameras and circuitry puzzles. I wanted the circuits puzzle to include more features like alarms or secondary options, but at the time of designing these mechanics, I was battling time while I juggled a full-time teaching job with designing a level for SCRAPS. I maintained my “puzzle” aspect with the second and third conduits setup. I am especially proud of the third conduits setup, the burning Chemistry room. The only parts I would change are the ghost boxes. Though they help the player identify what to do, I think they make the puzzle a bit too easy. I could have communicated the clue in another way, perhaps using a cut scene, but in the end, the setup work as I intend and the puzzle aesthetic remains.

What went wrong

1. Material mishaps: Probuilder prefabs do not usually play nicely when it comes to materials. My teammates and I encountered several instances of materials not applying correctly, materials reverting to their place holder counter parts, or materials not rendering at all (the cursed magenta objects). Most issues were resolved with a quick double check of the perforce server. Still, it is quite obnoxious to apply materials, one-by-one to thirty identical chairs, only for those materials to not stick when my classmate downloads the latest revision of my work. I would say about half of all QA tickets were related to materials in one way or another.

2. Over complicating the layout: When Team Garnet was first created at the start of January, we collectively chose the ambitious goal of creating a non-linear experience. The intent was to create a compound style play space. The player would have the option of choosing which order to complete the missions in. As soon as we began importing the Unity scenes, though, the challenges of this direction became clear. For one, it would require each of us to create alternate entrances and exits as well as scripts to control which doors would open and when. We also would need to design multiple transitions between each level. The last challenge, though, is the most annoying. Terrain in Unity 2018 does not rotate! Even if we could surpass the other three humps, the need to redo all our terrain put this goal out of reach. In the end, we stuck with the compound layout, but there is only one path from level to level.

3. Mechanic Crossover: This is probably the one part where we could have done more, but it was not communicated clearly. We could have created a stronger sense of connection between levels with more crossover with mechanics. Other than one spot in the archives level, none of the mechanics from any level can be found in the others. We had this idea when discussing the multiple path layout, but it just never came to fruition. In retrospect, it might have been cool if players would need to use explosive barrels to gain entrance to the school. Jeremy’s secret lab would be more interesting with some security cameras to evade, and plasma cutter portion would have worked nicely in Jordan’s library level. The time was there to accomplish this, but with so much focus on materials and QA, mechanic crossover took a back seat.

What did I learn?

1. Greater understanding of Perforce: In the earlier months of this project, I sometimes encountered big problems with version control. Usually a result of my carelessness, I would find perforce acting very strangely, giving me errors, and just not doing what I’d ask it to. This was very problematic during the Level Design course. I uploaded my Library and Temp folders, which made everything slow down, big time. Eventually though, I learned how to revert changes, undo actions, and how to recover a deleted file. As the weeks dredged on, so did my knowledge of this particular software grow. I am now far more comfortable using P4V, and would recommend it in the future.

2. Generating feedback: We were required to provide player feedback for each of our interactions. This is especially important if we want to communicate success and failure. By changing the lights or cueing a sound, designers can let players know that something has happened, and whether it is good or bad. This feedback should be consistent with the theme and atmosphere of an area to maintain the intended mood of the level and game.

Conclusion

In the end, I am very please with the product my team and I churned out. Our diverse skills in game design proved valuable in promoting team work and comradery. We crafted a memorable game with enriched environments, setups, and interactions that I would be proud to put my name on. In creating these levels, I learned more about texturing, constructing geometry, and applying materials. We gained very valuable experience in writing QA tickets and the all too important skills of generating feedback. I am excited to wrap up this long-term project and begin the next one.