Cory Zicolella, Week 9 PPJ, Blog Post 9

Garnering Playtest Data - 5 hours
Editing Playtest - 1.5 hours

This week was pretty standalone from any other for me.  While I usually do many other extraneous things, this week was focused simply on getting all of the playtests we needed since we had to have 44, and we didn't get much testing on the motionbase this term.  A secondary objective I had was to get more footage for the video so I could edit it this week; while I did get the footage, the labs were full when I was available so I couldn't make the necessary edits.

Getting the playtest data was mostly done on the Wednesday group playtest where I spent 4 hours, and on the following monday where we reserved an hour to get even more.  I recorded testimonials of some people before and after their ride experience if they didn't mind being on camera.  I also had to edit the playtest for each of these sessions before they happened to make sure they were good (and in some cases, to streamline it).

That was all I really did this week.

Total Time Spent: 6.5 Hours

This is a personal post mortem, and as such I will be measuring my work I did against my team as a whole.  I personally think I was a great asset to Alien Arcade; I was part of the original team a term ago and my placement as a sound/idea person carried through to this term as well.  Of course I did other things such as modeling as well, but my main placement seems to have been unofficially in the sound & video department, and idea creation.  This all being said, there was definitely good and bad that came with this project.  I',m happy I got the chance to work on it, but given another opportunity, there are somethings I would change.

What went right?
1. Reporting to the team.
I always made sure I would report back to someone if anything I did was finished (along with a direct path to that thing), or if anything somehow was an issue.  This really helped the team I felt because I was capable of doing more than I thought (if I told someone I didn't have much to do), and the team also knew exactly what I had been working on, and when it was finished.  Some people didn't do this as well as me I feel, and certain games may have slipped slightly because of it--they were always fixed, but usually never arrived to class in the state they should have been in.

2. Democracy
It is a weird label, but honestly I have no other clue what to call it (maybe team synergy).  Whenever I had an idea regarding a game, or an issue I had with an existing facet of one, or even a trailer decision, I ran it by the team.  This made it so everyone was aware of whatever idea/issue I had, but it also made it fair as to what we should do with it.  This essentially made everything a team decision, which I feel is really important for morale; everyone feels as if they have a say and in the end as if something important was credited to them.  This occurred often when brainstorming new ideas (this method of thinking eventually led to Draw at Noon) or during what I call 'issue meets' where we go through every game and list what is wrong (this is how we agreed to handle certain bugs).

3. Documentation
Personally, I didn't do a lot regarding this, but I think the amount that I did certainly helped the team largely and made the necessary processes faster.  When i gathered all of the sound effects for use in Alien Arcade, I made sure to document all relevant copyright information as well as a brief description as to what the ound actually is.  This made it extremely easy for David to add this into the GDD later as well as the credits of Alien Arcade; and it also helped everyone else who was trying to put music into the game.  Aside from this, my changelog submitted both to perforce and slack whenever I did something was very succinct and included exactly what went in and where each time, making finding those things easy.

What went wrong?
1. Timeliness
I am really bad personally when it comes to working in a timeframe, specifically because I work the best under pressure.  That being said, I always got things in on time and never really failed to do a task that I was assigned to do for the week.  I simply waited a long while or put the assignment on hold until the ladder end of the week to do other things in the meantime because that's how I've always worked.  It wasn;t necessarily a detriment to the team, it just forced me to change over time--I went from working mostly Monday or Tuesday on the project to starting to work on Saturday for it.  In some ways, this can be a positive thing; but it took 8 weeks to get there and I feel as if nothing but good would come from having me start and finish things earlier.

2. Not Getting Enough Playtests
Being in charge if playtests for Alien Arcade, this falls heavily into my hands I feel.  However, a few others and myself always mentioned playtests to people and we never seemed to meet our quota like we did from last therm (which is probably due to the huge influx of team members).  This means both on and off the motion base too; we managed to get many playtests our final week, but that was a desperation attempt because it was really required in order to fix bugs.  If we had more testers in general, and specifically more on the motion base, I feel like a large number of bugs we discovered could be fixed, and the motion could certainly have been tweaked already.  This was probably largely in part to there needing to be 3 people free, and 2 xbox controllers to even do a single playtest at all.

3. Time Estimation
This almost goes hand in hand with timeliness, but I'm setting it aside because this was a large reason why things were handed in later than expected as well.  This term in particular, I ran into many computer issues (both on my personal computer and on lab computers) that caused my various tasks to slow to a slog.  Whether it be the computer i was working on not having enough ram to handle a certain edit I made, or my computer deciding to randomly slow until I needed to do a system restore, or simply having something take longer than expected; time estimation always was an issue.

Lessons Learned:

• Reporting to the team allows everyone to know what's going on
• Team synergy is really important in a large group project for morale
• Documentation, no matter the form, will always help a process
• Working under pressure can be good, but in team projects it is not usually the best
• Playtests are extremely important to working out the flaws of a game
• It seems that estimating slightly more time than needed wouldn't hurt anything amidst all of the computer issues I ran into this term

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.

Xavier Smith, Week 10 Journal PPJ, Blog post w, GMAP 378

Content with Hours:

           

            Playtests and crunch time! This week was the busiest yet, another game I’m working on, RGB went into crunch time, so I spent the weekend until early Tuesday working on bugfixes and integration for a beta. That being said, I still managed to get a few things done for Alien Arcade this week

            Firstly were the playtests; I organized with the other section’s Team Lumpy Labs to host a joint playtest for both of our games at the motion base. Due to a few miscommunications however, we weren’t able to get enough playtests done, and so I scheduled for another one (with a fair amount of help from Joe Cory and David!) to get more playtests and find motion base bugs (3 hrs)

            Secondly, I did a bit of sprucing up on our sell presentation to reflect our latest build, and added a few more slides and talking points (1 hr)

            Finally, I made a few quick fixes on bugs we found from the motion base and tried to make the instructions for a few of the games a bit more coherent (1 hr)    

Content Positive:

- Got a lot of feedback from the playtests

- Fixed a few minor bugs

Content Negative:

- Didn’t have much time to work on the project due to RGB

Total Time Spent: 5 Hours

Personal Post Mortem

            Overall, this project proved incredibly draining. Most of the team and I were able to keep up with the project in the beginning, however the constant barrage of documentation, playtest requirements, and pressure to polish and add content while still keeping up with other classes took its toll on the team. Towards the end of development things started becoming strained between a few members due to the stress but we still tried our best to put out a decent game.

            

 What Went Right

1. Teamwork
As our team grew, we realized early on that we would need to change the structure of our team hierarch. To that end, I retained position of project leader, with John leading the programming team, and Angela taking charge of the art team. This proved to be a more efficient structure, especially for the artists as members were always clear on to whom they needed to speak to in order to get a task complete or a feature/art implemented. This also helped to ensure we did not repeat the mistake of the last cycle whereby members were unclear as to who was supposed to complete certain tasks resulting in the same work being done more than once. 

2. Content Generation
Despite time constraints and a few extenuating circumstances, the team actually managed to create more content than expected for this cycle. Halfway through the term our goal was to finish the project with roughly 16-20 mini-games; however we managed to finish with 22! One of the main reasons for this was having a dedicated programmer for functionality this cycle. Last cycle, functionality was done mostly by David and I. As a result, their ability to complete games was slightly hampered, and bug-fixes would be solved inefficiently as both programmers would occasionally work on the same problem unbeknownst to them. For this cycle, functionality was left entirely to John, who managed to complete all his tasks and still have time to implement a mini-game or two.  Additionally, our larger team size allowed us to work on more mini-games simultaneously, naturally resulting in more games being created. 

3. Documentation
In the previous cycle, most of the documentation was handled by David. For this cycle however, we managed to get more people on documentation, and so much more documentation could be done on a more detailed level. Due to the democratic process in which work was split up, not only did we ensure that no one member was overworked, but that each member got to work on something they actually had experience in or personally wanted to oversee. This proved to take a huge weight off the team’s shoulders (especially David’s) as we had the benefit of having more fair and even workloads while still being secure in the knowledge that all tasks would get done by the appropriate deadline.

What Went Wrong

1. Playtests
Playtesting was a more significant part of this cycle, with a much higher volume of playtests required for the game this time around. Due to the nature of booking the motion base as well as the necessity of 2 Xbox controllers and at least 2 players, gathering playtests for Alien Arcade has always proven difficult. While we managed to scrape up enough testers to meet quotas, each playtest cycle proved challenging to say the least.

2. Time Estimation
As a fair amount of our team members were in their senior year, enrolled in multiple production classes, or both, many members suffered from large workloads for this quarter. As a result, underestimating the time taken for one of our numerous deadlines would cause a serious setback, requiring no small amount of work to catch up and get back on track. As we are still fairly new to game development, these underestimations happened frequently enough to become a recurring problem throughout the project.

3. Clarity
One recurring complaint we received about the game was a lack of clarity for a few of the games. Due to the hectic pace of the game and our large library of mini-games, creating consistent, clear and concise instructions for each mini-game proved a persistent issue for the game. While the game now features a significantly more readable and consistent HUD complete with concise controls and instructions, we were still never quite able to figure out how to reach the level of clarity we wanted for every game within the project. 

Lessons learned
• Documentation can be very helpful in keeping track of goals and progress
• Setting aside time to test games is just as important as setting aside time to develop them.
• Team synergy can have a significant impact on morale
• Increasing team sizes eases workloads, but can make team management significantly more complicated