Joseph Santos Week 9 PPJ and Post Mortem

This week, I just had to finish textures for any fbx in the currently in the build. That meant importing a transparent trexture for ufo in refuel and a texture for the popcorn machine in pop corn popper. That was the end of my art production for this week and the entire term. The rest of the week I spent time helping my team gather play testers for both the playtests on Wednesday with infinite skies as well as alien arcade's own individual play test on Monday. I created the event on facebook and constantly blasted it out to every drexel group in hopes to get as many people possible. During the play test, I've captured some footage for Cory's video.

Pros:
Finish tasks in art backlog and closed it.
Got enough playtesters for the game this week
Cons:
wished I could have helped more with any other art asset that needed polishing
Event I created in facebook to get people for play test didn't draw a lot of people as I hoped. Even though we met our quota, I wished we got more people.

Hours:
Finished textures for fbx:
ufo - imported = .5
popcorn texture = 1

Getting people for play test(posting posters, sending invites) = 2

Attending play test and getting additional footage = 1

Total hours: 4.5

Personal Post Mortem:
This term was a bit rough for me. In addition to this class, I had other production heavy classes as doing the co-op interviews. At times I felt being pulled in 3 or 4 different directions with these projects and as result as I fell behind at times. However, I was not the only one in team suffering from being over burden with stuff and together, everyone pulled through this term to deliver on most of our promises for this build.

Problems:

Time management: 1 Production class is enough work for a student but working on 3, I found myself exhausted each day that I would fall behind schedule. I also had to do interviews for co-op and usually after doing those and traveling to them, I wouldn't feel able to do anything else for the rest of day. Not only would better time management would serve me better but also maybe not signing up for 6 classes this term. Lesson is not to take on too much.

Playtesting: Getting player testers for our game was a big problem most people faced, especially on the motion base. For me personally, I was usually never available when we scheduled playtesting on the motion base since I other classes around those times. I tried to make up for that by spamming our website to various friends, families, and game dev facebook groups, asking them to download the build and take a survey. Turns out I need work trying to write better posting to make people curious about our game and willing to give 4 minutes of their time to play the game.

Some mis-communicaiton: This was a problem that popped up every now and then. Usually I use Trello as a reminder of what I have to do. However, some art assets I did or created wrong. That was due to me misunderstanding the instrucitons, whether written or verbal. Luckly, whenever I screw something up, I was able to fix it and turn the correct asset in before the deadline. Again, this problem popped up every once in a while. Not a major problem but something to note.

Success:

Teamwork: When Moo diary team from last term got absorbed into Alien Arcade, everyone got well. A week or 2 into the term, the team was shown working well together. Everyone did their best to deliver what they ask and for the most part, we gave updates with each other on slack, letting known what was done or needed.

Art: For the most part, I was able to deliver on crucial art assets needed from me. By the end of term, any art asset asked form me is in the build. Also, I was able to catch some errors with other fbx not made by me and fix them.

In summation, despite being overwhelmed with classes and interviews, everyone was still able to deliver a solid build and I am proud to have been on this team.

David Monteleone, Week 9 Journal PPJ, Blog post 9, GMAP 378

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.