Chenghao Wang, Week 12 PPJ, Blog Post 8

What Went Right

1. Followed a waterfall flow to produce a game project.

It was a new experience for me as a team member to produce a game project followed the water flow. We divided into many small groups and focused on our own assigned game which is a good way to make mini-games collection like this.

2. Experienced the process of game making for motion platform. 

Motion base platform was the platform I used to play on at Disneyland or Universal Studios. But the process of making a game for that is kind of interesting to me. As a developer, the main difference is to focus on motion instead of gameplay. The gameplay can be simple, but motion can't. So this project is not like my other game projects have complex gameplay, AI, or requires more challenge programming skill. It's kind of new to me, but fun.

3. Learned how to balance gameplay.

This term, I mainly focus on the mini-game called Space Aim, which needs more player balance than what I did before. So thankfully, we have the survey for players who experienced this game, I got many valid feedbacks for the game, and tried to balance the game weekly by changing moving speed for both wall and ship, changing the layout of the wall, the background. It's a precious experience. 

What Went Wrong

1. The larger team, the larger problems.

Since this term, as a project team, we have 7 people, which is the huge amount of people as a student project team. In this case, people have to follow a direction, a guide. For example, artists must follow the art concept, but maybe that is not what they want it be. But that is how real world production works, so I guess maybe that's not a bad thing.

2. Weekly build deadline.

As the syllabus says, we have to have a build each week. That's a challenge for our entire team, programmers and artists have to do their work in the early day of the week, and we need to test the changes, add-ons to see if it works. The deadline really pushed people, we were too busy working on the current stuff with no time to come up with new ideas. 

3. Communication between team members.

This issue happened a lot in every team project, so  I think this is not an issue, it should be called normal. For example, when a team member did not finish his part in time, it causes a problem for the entire team. And sometimes, that team member cannot be got in touch with for some reasons, therefore, other members have to take more tasks than expect. I think it is a lesson, always check emails or any instant message software is the key to avoiding bad communication happened, and it is the key to being succeed for a team project.

Moving forward and how do we fix these issues for future projects?

The syllabus should be changed from submitting one build each week to submitting one build every 2 weeks. Team members should check their email or instant message more often. I think that's enough for being succeed on a college project.

Lessons learned for future projects?:

Programming for motion base following a specific work flow.

Balance gameplay by the given feedbacks.

Angela Buchanan, Week 12 PPJ, Blog Post 8

Personal Postmortem

What went right?

-       Collaboration

The modular structure we’ve set up for our game has made it very open for a collaboration of ideas. I felt that it was great that we were able to use our initial individual concepts to test the process of making a game work as one consistent game, despite have such broad differences in the initial ideas.

We could have started with a fresh batch of game concepts, but I felt it was a beneficial experience for our team to take on the challenge of adapting games that were not initially designed for Alien Arcade. Since we were able to make it work effectively, I feel that it proves that our team is adept at collaborating with people whose ideas and goals are diverse.

I also like that we have built a space that is open to taking risk with little loss. Our game gives us the opportunity to try experimental ideas without worrying too much about failure, since losing a min-game is not as significant of a loss of losing an entire project.

-       Team Development

Initially, we had a lot of issues coming together as a development team. But over the duration of the course, we have all learned from our early mistakes and have made significant progress in creating a more efficient workforce.

While we still run into the occasional mistake or miscommunication error, they tend to be minor in comparison to our early issues. I am also confident that our team has the awareness needed to improve our work habits for a smoother run next quarter.

Not only have we improved functionally, but we have also grown together personally. We all take pride in the work we have accomplished together and have significant respect for each other.

-      Strong Aesthetic presence

On the art side of things, I’m personally proud of the theme we managed to develop for our game. Since the beginning everyone was involved in narrative elements of our game, and we were all interested in the setting we wanted to build.

I feel the idea of space carnies is a great way to develop a humorous, devious species and the idea of abductions and captives adds a nice touch of fear for the player.

Aside from ideas, we also have great assets that can easily be used across multiple games. We also have a lot of artwork that is effective at communicated our concepts and is great for promoting our idea publicly.

What went wrong?

-      Communication

                  This was especially problematic early on. I felt in the beginning it was easily to get lost in what was assigned and who it was assigned to. I didn’t just have problems with this amongst the artists, but it was also an issue that occurred with the programming side of things.

                  Despite this being a major issue, I felt we handled it well as a team. I felt a lot miscommunication stemmed from our lack of organization, which we realize now and plan to address in the future.

-      Changes in Ideas

In relation to the miscommunication, I felt our ideas were hard to confirm as decided upon officially. I felt this was especially prominent regarding themes for mini-games. I feel like this was primarily due to a lack of a well discussed asset list or Gantt chart.

I felt task priority was also hard to establish within the team. There were some tasks that were in higher needs of completion than others. There were also tasks that I felt were high priority, but after working on them and handing them off, I realized their priority wasn’t as significant as I once thought.

For example, the bodybuilder asset was viewed as a high priority when being made. But after his completion, I realized that the efforts put into him should have been applied to other assets first. However, he has gained a lot of popularity, so it was not a full loss.

-      Deadlines

I struggled with this personally. Unfortunately, the bulk of my class assignments this term were due early in the week and demanded a lot of attention. Combined with preparing for co-op, I had a chaotic, unpredictable schedule.

This combined with the miscommunication and organization issues early on in the project, led to a lot of assets being built the night before class. While it was relative easy to just roll the implementation of assets over to next week’s sprint, I would have preferred to have my assets completed earlier.

This was not only an issue of mine, but an issue experienced by other members of the team.

Moving forward and how do we fix these issues for future projects?

The majority of our team, including myself, agrees that a lack of organization was our biggest downfall. We thought perforce, meetings, and slack would be enough to manage an effective workflow for our project. Unfortunately, we were wrong.

In reality, we should have been making use of organization tools such as Trello. Even if it would not be our primary source of communication, it could serve as a guide for tasks assigned. There would also be no confusion as to what ideas were “official”, for tasks in Trello could be viewed as confirmed.

Despite the lack of organization, we still managed to pull ourselves together as a team and make great progress while acknowledging our mistakes and learning from them.

Lessons learned for future projects?:

-       Record everything major stated in meetings and keep it posted it in an easily assessable location.

-       Map out a detailed list of assets early on and actively communicate changes that are made to that list.

-       Always use organization tool, such as Trello, even if you think your current communication methods are fine.

-       Always ask others about the current state of things, especially if it directly involves your work.

Cory Zicolella, Week 12 PPJ, Blog Post 8, Personal Post-mortem

What went right?

1. We successfully created a system capable of pooling selected mini games

The primary focus when this game was initially pitched was to create a platform in which you can select games out of a pool and play them; secondarily we were to use the base code from our initial 10 week development period to use as a foundation for most future game ideas.  Considering we have a wide unique array of motion in each mini game, I would say that this venture has been successful.  The code base for driving, flying, sudden jerks, and bipedal motion are all included in our current build, with a WIP idea for boat physics--these things cover most groundwork for code that we would need.

2. Collaboration

Despite every person approaching the beginning of this term with unique ideas, each person was able to neatly collaborate on this game, partially due to the doors it opens.  Half of our tech demo games from week 3 were used in Alien Arcade, and the team was able to incorporate changes easily and without debate.  Those that didn't get to incorporate games had great input into the current build at hand and didn't fuss about ideas they weren't partial to.  If there was a problem at any point, the group addressed it simply and found out a way to solve it, together.  I'm fairly certain there were no points in which there was a disagreement between us, and the work we accomplished really speaks towards our willingness to function together.

3. Capable of Solving Issues Efficiently

It is no secret that despite everybody's best efforts, there simply were issues that we had to deal with over the term.  We are only human after all, and when these issues arose they were always either highlighted to the responsible party and dealt with post-haste, or it was mentioned to the entire team at which point we split off to fix whatever went wrong.  This was the case in multiple cases; when the work on the Mech Game was delayed, when I accidentally created 3D models (instead of cardboard models), when everyone was still cranking out new resources with only 2 weeks to go.  All of these issues were dealt with very well and this is just me speaking from the art end--I'm sure that the coders handled many more issues (One I'm aware of is the motion base bug).  Because we were capable of this efficiency, it allowed us to complete alot more in our allotted time.

What went wrong?

1. Lack of a Gantt Chart

I think this is pretty straightforward.  Had the team been referencing a Gantt chart or other similar project management, we wouldn't have had to be confronted in the 11th hour to stop making new resources/adding to games.  We could have adhered to a strict schedule and been aware of what we needed in the weeks ahead.  Granted, we ran into a few hefty bugs that took awhile and inevitably some portions would run into other weeks--but it would without a doubt have kept us all on the same page, instead of meeting once a week and delegating tasks randomly based on current progress.

2. Communication

In the early onset of this project, we communicated via email.  Needless to say, this was disorganized and worked horrible, especially with Drexel's email system: some people just wouldn't get group communications because their mailbox was full, and others just wouldn't check.  After 2 weeks of this nonsense, we moved to Slack, which alleviated much of our communication issues to almost 0--to those who used it.  Many did what was asked of them regardless, but some didn't check the slack often or got notified when they should have been.  I was on constantly and almost instantly replied when I needed to, as for others I can't say the same.  Some people barely used the slack at all.  And communication mediums aside, sometimes tasks were garbled and confused, causing people to not do the right thing or nothing because they were unsure of what to do.  This happened very few times, but communication was surely a factor.  Communication issues will always ensure when there is teamwork though, and overall I think we did moderately well.

3. Work Ethic

This is a bold statement, I know-- and it surely doesn't affect everyone.  I can really only say this at a personal level, but sometimes my work ethic suffered.  Of course everybody has more than just this project to do, and I'm understanding, but most of the work for the majority of the term was completed seemingly last minute.  As time went on I got better with it, not doing all of my work on Wednesdays and instead having it finished by Monday night or Tuesday afternoons, but I certainly feel like others also waited a similarly long time (or longer) to complete their work.  Again, I only can accurately measure my time spent: I did complete everything I was assigned to do usually (unless surprises occurred that took more time).  I just work well under pressure, so naturally I wait in order to give myself that motivation.

How are these issues resolved for future projects?

The answer to this one is quite simple, I feel.  We'll most likely have laid out groundwork for what needs to get done so the team isn't delegating jobs on a per-week basis; it allows a better insight into our final goal.  Communication will always have somewhat of a rough road, but if we are more aggressive with standards or simply having people report in once a day it will probably solve all of the issues there.  As far as work ethic goes, that is up to the individual to fix.  To a certain extent team members can add pressure, but that isn't necessarily good or helpful for the team as a dynamic--ultimately it is up to each of us.  For me, I've already accepted that I need to complete my work sooner.  For others, it may be similar or it may come later.  Meetings will iron out most of the remaining team problems and enforce (what should be) these new policies to insure that we won't have to deal with as many problems next term.

Lessons learned for future projects?

The lessons that working together with Team VIIcious for 12 weeks have taught me:

• Most bugs, however large, are workable for your goal
• Communication is key to creating content
• Even though mini games sound easier than a single game, there is just as much work
• Version control is a lifesaver sometimes, even if Perforce is the devil
• Keeping momentum at a high is important for productivity
• If a team is able to collaborate, it makes teamwork so much more enjoyable