Post-Mortem for my team and our level during our month in Project and Portfolio IV at Full Sail University. Future students can find value in the advice section located at the bottom of the document.

1. 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.

2. 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.

3. 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

4. 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.

5. 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.