0% found this document useful (0 votes)
58 views

CS 322 PostMortem-Individual Template

The individual summarizes their contributions to the VR project, which included scripts, lines of code, 3D and 2D assets created and procured, and animations. They estimated slightly more hours than were actually worked. Key lessons learned were minimizing file sizes, maintaining a clear file structure, and ensuring necessary hardware was available. The individual felt their contributions matched their teammates' in both quantity and quality, and that prior coursework adequately prepared them for this project although VR development was new.

Uploaded by

Zachary Barnes
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
58 views

CS 322 PostMortem-Individual Template

The individual summarizes their contributions to the VR project, which included scripts, lines of code, 3D and 2D assets created and procured, and animations. They estimated slightly more hours than were actually worked. Key lessons learned were minimizing file sizes, maintaining a clear file structure, and ensuring necessary hardware was available. The individual felt their contributions matched their teammates' in both quantity and quality, and that prior coursework adequately prepared them for this project although VR development was new.

Uploaded by

Zachary Barnes
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Project Postmortem (Individual) 7/16/2018 3:56 PM

Individual Postmortem for Zachary Barnes

Purpose1

The purpose of a postmortem is to “learn from past experience.” This is accomplished through careful
analysis of a project once it has ended. As a team and as individuals on the team, you identify what went well
and what went poorly so you can do better on subsequent projects. The postmortem also gives closure to a
project. Closure is important for team members who are breaking away and moving to different projects, or
to wrap up a particularly long or tough project cycle (sense of completion).

A postmortem should occur within 1-2 weeks of project completion. Smaller postmortems can be conducted
following completion of any major milestone during the project cycle. If you conduct the postmortem too soon,
people may not be done wrapping up loose ends.

This document contains your individual postmortem. For full credit, you must fill out all sections, critically
analyzing the production process you were engaged in this semester.

For each section, answer the questions in a narrative (paragraph) form. You may need more than one
paragraph per section. I'm looking for in-depth analysis showing that you have considered the questions and
reflected back on how you can improve the process for your next project. Each question should reflect different
issues/concerns. And since there is always room for improvement, all answers should be specific and
complete, with little repetition.

Please pay attention to grammar, spelling, comprehensiveness, and narrative. This is a chance for your team
to tell its story.

1The postmortem template has been derived from http://www.wintestgear.com/templates.html, which offers free tips
and tools for use.

-1-
Project Postmortem (Individual) 7/16/2018 3:56 PM

Individual Contributions (Quantity)


Include here your contributions to the production process. For programming and art creation, provide
information about your contributions only. For any assets procured, identify the number of assets you
(not anyone else on your team) procured.

Programming:
Scripts: 4
Lines of Code: 286

Art Assets:
3D Assets Created (if any): Laser, text labels
2D Assets Created (if any):
2D/3D Assets procured (if any): Boat, various island elements (bridges, water, trees)
Animations (if any): Boat animation
Other (specify):

Sound Assets:
Background Music Files (assets procured): 1
SFX Files (assets procured): 6

Estimated Hours (only you) Actual Hours (only you)


Sprint 1 4.6 4.5
Sprint 2 5.5 6
Sprint 3 9.26 9
Sprint 4 16.1 18
Sprint 5 16.6 14.33
Sprint 6 (if appropriate) NA NA

 Refer back to the number of hours that you (just you) thought it would take you to
produce the game. Compare the number to an estimated number of hours that you put
into the game to date. Explain the difference.

The total amount of hours I personally estimated for each sprint of the project was 52.06
hours. This was based on the card exercise our group did during each sprint planning
session. In reality, my total hours ended up just shy of the final estimate, 51.83. There are
many factors to take into account, but we were very conservative with our initial estimates.
We also realized that we would always be working a certain number of hours each week (6
hours) because of our meetings, and also include outside group hours. I believe the small
difference can be attributed to the amount of diligence and efficiency our group enacted in
the last sprint and final stages of development, in which we truly focused in what I viewed as
a very efficient workflow. Usually, estimates are under the actual time, but with this project
we worked under strict deadlines and managed to finish under the estimate.

-2-
Project Postmortem (Individual) 7/16/2018 3:56 PM
 What were the three most important aspects of resource planning that you (personally)
learned through this process?

1) Minimization and efficiency with files: Working heavily with many of the audio files that
the experience needed, I learned quickly that using high quality format audio files such
as WAV files caused the load times in Unity and GitKraken to slow down significantly. I
converted many of the files to mp3 and trimmed them so that when they looped, they
still gave the impression of an elongated audio file.

2) File hierarchy/structure: This is one of the first times I have had to work on a project with
such a large codebase of different libraries and frameworks. Our group took the time to
clearly layout the file structure with libraries clearly outside of our main working file,
Gimbal’s field. By doing to this, it was very efficient to find where our scripts all were
consolidated, as well as where assets that we had to access frequently appeared.

3) Hardware/physical tools: One lesson that I learned early on was that it was imperative
that we had every necessary piece of equipment on hand as much as possible.
Charging cables, base station stands, headphones, etc. By making sure that we had the
same room and equipment each time early on, I didn’t have to check each time for all
the equipment, because I knew that it was in the same place and no other group was
using it. Hardware can sometimes be very unpredictable, and I learned that by using the
same computer and VR headset each testing phase ensured consistency throughout
the development process.

-3-
Project Postmortem (Individual) 7/16/2018 3:56 PM
Individual Contributions (Quality)

 Was the quantity of your contributions for the project on par with your team members? If
so, in which way? If not, why not?

Every meeting, I strived to have one or more quantifiable tasks completed. Whether this was
adding or tweaking an audio element in a scene, improving the controller responsivity, or boat
experience, I worked in small increments that could be committed to the git repository as to
avoid merge conflicts. I believe that all group members had a similar mindset, and if someone
felt that they didn’t have a substantial task, we would collaborate together on one difficult task.
Because of this I believe I contributed a similar quantity of work as my other team members.

 Was the quality of your contributions for the project on par with your team members? If
so, in which way? If not, why not?

When I added a feature of asset to the project, I constantly tested it through the VR headset to
see if it was of high quality or even appropriate for our projects goals. There were certainly
times where I had to iterate through certain features, but in the end, I was satisfied with the
quality of many of the audio elements, island assets, and animations. Through user testing and
group member testing, I feel they also were content with the contributions I added, so I feel
confident that my contributions were of similar quality as my other team members.

 Do you feel that you were adequately prepared (based on your other courses at Knox or
other learning experiences) to take this course and be successful in it? If so, in what
ways? If not, what could be improved in the curriculum so that you are prepared for this
course?

After enrolling and completing CS 292, Software Development, I felt ready to work on a
large-scale project with a team for a whole term. Despite CS 292 having groups of three, I
was optimistic about working in a larger group and seeing how a group could still achieve
efficiency even at a larger size.

I felt prepared to work with source control and tools like Git and GitKraken because of my
past web development experience and CS 292 work. Despite this, the Udemy tutorials did
fill in the gaps with my knowledge of GitKraken.

One way I was challenged at the beginning of the term was that I had never developed for
Virtual Reality technology or the Unity game engine. But after going through the Udemy
tutorials, many of my previous reservations about the complexities of 3D design were
mitigated. After working through the first couple iterations of Gimbal’s Field on the headset I
felt confident in being able to contribute and create an experience I and others in our group
would be proud of.

I would recommend for future curriculum to again use video based tutorials, because they
provide the practical knowledge at my own pace outside of class to get started quickly on
working with the relevant technologies.

-4-
Project Postmortem (Individual) 7/16/2018 3:56 PM
Some improvements to curriculum could be to have an introduction to 3D modeling. Myself
and other group members learned the open source Blender tool to produce many of our
assets. While this ended up being enough, I feel that I have only scratched the surface of
what is possible with this tool. By having 3D modeling introduced in earlier prerequisite
courses or at the start of the course I feel I would be better equipped to handle mediums like
VR and other game development environments.

 Did you enjoy working on this project? Why or why not?

I initially was indifferent to working on a virtual reality project for this class, because I have
never developed for VR before. But once we started brainstorming on ideas and doing
research on what was possible, I became very enthusiastic about what our project could
accomplish. It was extremely enjoyable to be able to implement a new feature and escape
into the world of VR to test it out. After the first few iterations, when we had a project that
was truly beginning to take shape, I only got more motivation to make the project even
better. User testing was also an exciting aspect of the project because of the immersive
nature of VR is. Our user’s enthusiasm for the project added more motivation for me and I’m
sure to the rest of the team. If I had the chance, I would definitely enjoy doing this project
again.

 Are you happy with the quality of the release build of the game?

Besides a few small details like the boat’s path, sky interactivity, and the detail in the island,
I was proud of the quality we were able to produce in only 7 weeks. Between the last
presentation at SMC down and our final presentation, I was astounded by how much little
detail improvements could completely change the feel of the project. By adding the much
more polished and realistic low-poly water asset, it made the whole experience feel more
alive. We also made the island path less ambiguous, which made for an experience that
was even more intuitive than the previous versions. The quality of the release build was
something I was eager to tell my friends and professors about!

-5-
Project Postmortem (Individual) 7/16/2018 3:56 PM
Challenges

 What challenges did you personally encounter during this project? How did you work to
overcome those challenges?

The challenge that I worked the most hours on compared to any other aspect was the boat
tour of Gimbal’s Field. Initially, I was using many of the complex rotation functions and
transforms that were built into Unity, but this proved to be very hard to customize and
manipulate. I was able to research and find an applicable animation tool, iTween, that
allowed for simple animations of objects. There was still a learning curve to using this tool,
as it had its own share of specific code syntax and documentation. But in the end, it was
worth it, because it allowed me to be highly specific with where the boats path could go,
which allowed the boat tour to go around the island and outer sphere.

One of the more significant audio challenges I faced during this project was the 3D aspect
of the VR experience. To be able to hear different sounds like water brooks, fire crackling,
and crickets chirping, without all overbearing each other and making it seem realistic to a
real-life experience took a scrupulous amount of tweaking and testing in the VR audio. I was
able to overcome this challenge by putting in additional research at the start of the project
regarding 3D audio in Unity. Once I found the optimal settings for each audio component, I
used it as a template for each new instance of audio in the scene, so that I didn’t have to
relearn all the correct configurations.

The controllers for the HTC Vive were a valuable yet complex piece of hardware to develop
with in this project. I believe the reason for this is because they had a variety of functions
that needed to be incorporated but have limitations on the amount and type of buttons they
include. For example, our experience needed to be able to do three things: interact with
space objects, teleport around the island, and select menu options. Initially, it was simple to
include a laser, but as I added on other features like teleporting, there was a significant
amount of clashing with the functionality of our controllers. They eventually become
unintuitive to use. To solve this problem, I helped simplify their purpose, making it so that
one controller was relegated to star interaction, while the other was strictly for island
interaction. By labeling the controllers, I also helped mitigate initial confusion as to what the
controllers purpose was for new users, especially those that had never encountered VR
technology before.

-6-
Project Postmortem (Individual) 7/16/2018 3:56 PM
Communication

 What were the three primary challenges you personally encountered with
communication among team members? (Answer honestly.)

1) Slack: Slack was invaluable resource for our groups communication, as it assisted in finding
meeting times, sharing short code snippets, etc. However, because of the number of
channels that were being used, and the proliferation of messages that could occur in a short
amount of time, the most important messages were being neglected. Messages that
pertained to a certain meeting were sometimes overlooked, and there were several
instances where I and other group members had no idea that we were meeting on a certain
day.

2) Source control: While our group had a thorough understanding of tools like Git and
GitKraken, communication issues stifled our efficient use of these technologies. One
specific instance was our use of branching. A source control concept that is meant to
mitigate merge conflicts, because we failed to communicate that most of the main work was
being completed on our menu branch, not the main branch, I and others ended up pushing
commits that were not being used in our working version of the project. To help alleviate this
problem, communication about what branches and their purpose should be constantly
known within the group.

3) Deciding what our priorities were: This communication issue occurred near the end of our
project. We had the approaching deadline, and details like water color and other trivialities
were being handled, instead of the dominating factor that our stars were not responding to
controller interaction. This to me was the key feature of our project, and because of lack of
communication of our priorities we didn’t address this problem until very close to the
impending deadline. One way this problem could be mitigated in the future is to have priority
numbers on our list of tasks at the beginning of each meeting.

-7-
Project Postmortem (Individual) 7/16/2018 3:56 PM
 What were the three most important aspects regarding communication that you
personally learned as a result of this project?

1) Face to face interaction: While slack and other messaging tools are extremely helpful, I
learned that by vocally acknowledging tasks and meeting dates at the start and end of
meetings was a much more effective way in solidifying these details.

2) Having clear communication about deadlines: Through this project’s number of sprints, I
learned that it was crucial to have a sense of where our deadlines were, even if they were
only our own agreed upon deadlines. As a group I believe we effectively managed our
deadlines, and this allowed us to incrementally produce work of increasing quality
throughout the term instead of having sporadic periods of productivity or complacency.

3) Inter-team support: A valuable lesson I learned about small team communication was that it
if one is stuck with a problem, it is better to communicate and ask the team about the
problem as soon as possible, instead of trying to figure out the problem from scratch. This is
because it is highly likely that someone else in the group has encountered that problem
before. By communicating early on, I was able to get much quicker support and help for
problems instead of if I just looked up solutions online.

-8-
Project Postmortem (Individual) 7/16/2018 3:56 PM
General and Words of Wisdom
 List the three top things that went well for you during your project. Explain each.

1) Creating a peaceful, Zen, audio atmosphere: When our group solidified our goals for what
we wanted the overall project mood and experience to be, I strived to make the audio
features of the project to match these characteristics. I spent a significant amount of time
finding and testing out open source music that might suit our experience. We went through
a couple iterations, and by the end I was very satisfied with the final background music
sound and other audio effects placed in the island. Perhaps my favorite moment of the
project presentations was when I placed the headphones on one of the users, and she
immediately responded, “This is so peaceful!”. I am a firm believer in the effect quality audio
can have on an artistic experience like games, movies, and now, VR.

2) Making interactions with the Vive controllers intuitive: Like I explained in the challenge
section, getting the Vive controllers to be meaningful and intuitive for the experience
required inordinate amounts of tweaking and testing. But in the end, I was very satisfied with
how simple and intuitive the teleporting and lasers were for users. Many users (especially
Professor Bunde’s children) were ecstatic about how fun the controllers were to use in our
experience.

3) Using user testing data insightfully: For our first user testing sprint, I was surprised with the
amount of insight we garnered from many of our users that was not very obvious to us as
developers. The purpose of our experience was not clear. By seeing the data aggregated in
our surveys, it was obvious that some aspects like teleportation and interactions with the sky
were not well implemented. I used this information to simplify the teleportation and laser
pointer to improve the overall quality of the experience. For me, this was one of the most
helpful user testing phases I have ever had in a project.

 List the three top things that did not go well for you during your project. For each,
suggest how you would mitigate those problems if you could do it again.

1) Not converting the project into a build until the very last day: Because of delays with many of
the features we were implementing in the very last phase of development, we did not
actually build the project until the day of the final presentation. We encountered numerous
file and library reading issues when we converted the project into a build, which increased
our stress in the final moments of the project. To mitigate this problem in the future, I would
strive for having a build for every significant presentation and instance of user testing, so
that the problem would not come by surprise in the final crucial moments.

2) Gaps between testing in Unity and VR: For I and my teammates, this problem occurred
often: A feature worked and looked great in our Unity window, but once it was tested in the
Vive, it looked completely different or sometimes didn’t even work. I experienced this with
my audio features, as well as with some of the 3D assets and text labels. One way that this
could be mitigated in the future is to have VR testing once a new change is committed to the
master repository. By doing this, one will not have to go back and fix a feature that was
believed to have been functioning for several days or weeks.

-9-
Project Postmortem (Individual) 7/16/2018 3:56 PM
3) Completely eliminating any motion sickness: I spent the majority of my time in the last sprint
making the boat tour engaging but at the same time not to sickness-inducing. Thu and
Jamie implemented the tunneling feature for the headset, but its effects were sometimes not
enough. Ultimately, one of the biggest factors in reducing motion sickness was changing the
boat speed and orientation, which was difficult to test again because of the gap between
Unity and VR. For most of our users, they didn’t experience any motion sickness, but for
some of our users, they described the boat tour as being the most sickness-inducing part of
the experience. In the future to mitigate this problem, I would have more frequent testing of
the boat’s speed and path. Once an optimal path and speed were found, I would not tweak
them significantly, so that its steadiness would be preserved.

 What are 3 areas you will work on over the next few months, prior to your next class
and/or the next project you encounter, to improve yourself as a team member?

1) Communication: The aspect I mentioned in the communication section that outlined the
importance of face to face communication is something I will actively work on in other group
projects and daily relationships. If something can be communicated face to face, as
opposed to email or text, I can only think of a few situations where the latter is more
effective. By defaulting to face to face communication, I believe my thoughts and
interactions will be more meaningful to group projects in the future.

2) Work on larger scale projects: This summer, I am researching here at Knox, and because
the project is extended in time and scope, I will need to have a strong overarching sense of
structure and organization to this project. I plan through this summer project to gain a better
understanding of how large-scale code bases work and how to effectively manage
motivation and focus over a long period of time.

3) Ask more questions: Through this project, I also learned the importance of asking questions
carefully and frequently, because either my team members already had solved the problem
or were facing the same problem as me. I will be actively working on asking questions that
are specific and insightful with my summer project and other academic undertakings
throughout the year.

- 10 -

You might also like