Content with Hours:
Since this is our Post
Mortem PPJ, I’ll keep what I did for the week to a short paragraph. Here’s a
quick listing of bugs that I fixed: made aliens move faster in Water Gun, fixed
Mech controls to be on the correct side for shooting, made the Press game
slightly longer, added missing textures throughout the game, added and modified
control panel images that were wrong, added alien controls to games missing
them, and added human controls to games that lacked them.
(1.5 hrs)
In
addition to bug fixing, I also made the final credits scene to display our
names and the music copyrights. I implemented the art for Press that Jinghan
made. I removed the old and unnecessary UI elements from all of the games. Ie:
the ‘X’ button, and return button in the top right corners. I added the Popcorn
Popper texture that Joe made. I then started to work on the final GDD deliverable.
In addition to these tasks, I spent a large amount of time playing the game as
many times as I could. Every time I found a bug or issue I’d report it to the
appropriate person via Slack. I love where the game is right now!
(3.5 hrs)
Content Positive
(Duplicate hours from above):
-
Fixed various bugs throughout the game (1.5 hrs)
-
Added missing artwork, made the final credits
scene, removed old UI elements, playtested the game like crazy, and worked on
the final GDD.(3.5 hrs)
Content Negative
-
None
Total Hours for the week:
5 hrs
Personal Post Mortem:
Since this is a personal
post mortem, I will discuss how my efforts affected the team and where my
efforts went right or wrong. In general, I believe that I was a great asset to
the production of Alien Arcade. From the very beginning, I helped shape the
game to be what it is today. Whether that was with my hard work or leadership
the game was definitely impacted by myself. I’m happy to see the game be where
it is today, but of course, there are always lessons to be learned by the
mistakes made along the way.
What went right?
1.
Documentation
During the term,
I was in charge of all documents related to team organization, documenting the
game, and putting in writing what the game is actually supposed to do. I put a
significant amount of effort into each deliverable that related to
documentation. The end result was a very good response from our professor. The
game was also easier to understand and the group had a single document to go to
for information on the game. I believe that this contribution was critical to
integrating the new team members into our group early in the term. The
documents explained how to make mini games and integrate them into our system.
This is probably one of the best products that I produced for the team. This
taught me the lesson that well done documentation can be one of a group’s
greatest assets.
2.
Game Making and Up Keep of Old Games
The group
followed a similar development style as last term. As such, I developed three
of my own games and maintained them. Because we allowed individuals to maintain
their own games I was able to completely focus on keeping my games in tip top
shape. I also took on the task of maintaining the games from the previous
quarter. Trust me, there were plenty of bugs to be fixed in the original five games
from last quarter. As a result, I polished a total of 8 games and am extremely
happy with where they are at today. This taught me the lesson of being
responsible for past work while also maintaining work that you have recently
made. I didn’t make others find my bugs from last term. I went back and fixed
the old games while still maintaining my new ones.
3.
Communication
I made it a
clear to everyone when bugs existed in their games or when things just didn’t
seem right. During each group meeting I was an active member that participated
and made sure that my voice and opinion was heard. Without this type of
communication, many bugs would’ve never been fixed, controls would be flip
flopped or nonexistent, and games would lack the proper art that the artists
had put the time into making. I made sure that if an asset was ready to be put
in a game that the person knew to put it in the game. I also made to sure keep
the group on the same page when adding in new features, adding bugs fixes to
another person’s game, or updating the GDD which is the final say in how the
game is built. These lines of communication and networking are critical, especially
when working with a group of 11 and using version control software. The lesson
learned here is to always keep your lines of communication in a group open.
People should always know what to do or what to fix.
What went wrong?
1.
Time Estimation
Throughout the
term, and even last term, I struggled to estimate my tasks appropriately. I
ended up having many tasks being “Extra” when we would present the Status
Reports for each week. This is something I know I have an issue with and I did
attempt to fix the issue. I always tend to underestimate the amount of time it
takes to fix bugs or implement features. The lesson learned from this is to use
your past experience as a gauge for estimating the time required for tasks in
the future.
2.
Time Management
I did not have
nearly as much free time as last term. This is a result of having more classes
than I did in the fall quarter. As a result, I had to schedule my work for the
project in tighter and more constricted time blocks. This resulted in many of
my tasks being rushed and not as thoroughly completed as they could’ve been. An
example of this would be the controls that I had to do two weeks in a row. I
needed to manage, and space out, my tasks for each class more appropriately so
that I could complete each class’s tasks well. This closely relates to my time
estimation problem, but this is more so regarding my timing of everything in general.
Balancing outside work with classwork and making sure each is given an
appropriate amount of time. There were a couple weeks here and there that could’ve
been given another hour of two of production for the game. This reason here is
why I did not accept the leadership role that was offered to me at the start of
the quarter. I simply did not have as much time to be the same leader I was
last term. I think that was definitely a smart decision on my part, both for
myself and the group. The lesson learned here is to make a schedule for each
week or month and make sure each task is given an appropriate amount of time to
work on it.
3.
Not Play Testing Enough on the Motion Base
This is not just
a personal issue that I had during this quarter, but this is a team issue. I
did not play test ON THE MOTION BASE enough after making changes to the build.
Granted, it’s difficult to find time slots that match the motion base hours and
the teams. Last term, I felt like I was at the motion base on a weekly basis.
This term, I did not have as much spare time to spend the game. The end result
was a game that was well polished, but still needed a couple motion tweaks here
and there. When the group did organize motion base play testing I was at every
play test session. I even brought friends to play too. The lesson learned here
is that setting aside time to test games is just as important as setting aside
time to develop them.
Lessons Learned:
·
Documentation can be one of a group's greatest
assets.
·
Being responsible for past work while also
maintaining work that you have recently made.
·
Always keep your lines of communication in a
group open. People should always know what to do or what to fix.
·
Use your past experience as a gauge for
estimating the time required for tasks in the future.
·
Make a schedule for each week or month and make
sure each task is given an appropriate amount of time to work on it.
·
Setting aside time to test games is just as
important as setting aside time to develop them.
