Riley Stewart PPJ 8 Post-mortem

Right?

1. Good variety of games

With variety of mini games being used, there was alot of creative freedom for each individual developer do test their idea. having a a basic framework for development to work off of, the developers had complete creative freedom over the game they developed. this helps prevent development from growing stale, and if for some reason the game cannot go forward, it's less of a loss to the developers.

2.Wide variety of drexel ride movement potential

With the variety of minigames available, it allows the developers to use the rides capabilities in unique ways. the movement of the ride can vary greatly between games. One game, you move as a mech walker, the switching to an interdenominational spaceship. Possibilities are endless, and there is full freedom for developers to find and test  these possibilities.

3. basic framework for development

After we hammered out the bugs of the system, a basic framework for development was created. This streamlines and makes development simple, allowing developers to simply drop and apply this framework onto the games making implementation incredibly easy.

Wrong?

1. Work schedule

This is a personal issue. My schedule for this term was fairly strict, with other heavy production classes this term and working 30-40 hours a week. This prevented me from efficiently being able to produce work on time, as the only easily workable days were late Tuesday and late Wednesday. being so, alot of my work was implemented the week after it was intended.

2. Communication

Communication was difficult, as it took a while to setup slack. even so, alot of people were very unresponsive, leading to alot of confusion with development and assembling assets. This was a bit more efficient and worked out later on, but not fully fixed.

3. changing game concepts.

During development, alot of the minigames were changed alot from their initial concepts. this led to alot of the assets having to be changed as soon as they were made, or even scrapped completely. this was very frustrating and confusing during development. For my personal work, alot of the assets I created were scrapped, such as the initial stello says, cardboard cutouts, and the ufo model.

Resolving for future projects

Now the major hurdles are understood and worked on, development as a whole is far more streamlined. with alot of communication going on between the team members, any issues one developer has, such as art, programming, and design can be communicated with all other members of the team.

Lessons for future projects?

• There's always a way to solve a problem in development
• t's a challenge developing these games, even with the small scope and a basic framework, it's still a full game that needs to be developed
• COMMUNICATE
• get the ideas down early to speed up development and prevent wasted time and work

Xavier Smith Week 12 PPJ

What Went Right

1. Collaborating on ideas.

While creative freedom was an important part of this project, that doesn’t necessarily mean everyone could just do whatever they want or have complete control over a mini-game. All of our games were run by the team as a whole. We would then come to a vote as to what alternative we’d go with in the case of a disagreement. Surprisingly this never became an issue, as most of the pitches for ideas and games usually resulted in team members adding even more to a game idea, or mechanic, resulting in a better game that we almost always agreed on. While there may have been times where some of us may have disagreed with the direction on an individual idea or game, there were never any hard feelings and we always respected final decisions of the team.

2. Covering each other’s weaknesses

Occasionally there would be a problem with a game or feature: be it a motion base error, a 3d model, a script or what have you. The person assigned to that particular task would have problems with. In such a case, there would always be another person on the team that could and did solve that problem. A concrete example would be the movement controls for Space Aim and Stello Says, where Chenghao and I initially had some difficulty getting the movement to work for a controller, and so David went in and reconfigured the controls for both games.

3. Creation of a modular system

As stated above, one of the huge goals for our project was a modular system, whereby new games could easily be added without having to redo much of the code. I and David did a lot of work to ensure that controls were set in a consistent manner and that this could be done easily in the future. The resources such as an easy to use timer and score keeper were available to just slap onto games so that members did not have to worry about having to mess with the timers and other common elements to get their games to work. Angela also created textures and materials that could easily be applied to more than one game for art.

What Went Wrong

1. Motion base

Being inexperienced with the motion base and having never made motion-based games before, our team ran into problems with the platform. A lot of time was spent debugging and smoothing out scripts and objects that influenced the motion of the Drexel Ride. One particular issue that gave us trouble was switching between mini-games. If the object that held the script governing motion base movement was destroyed, regardless of whether or not a new one was created it would cause the motion base to stop. Eventually a solution was found to prevent this and implemented in such a way that the fix could just be dragged and dropped into each mini-game. This again conforms to our idea of modular scripting and design.

2. Communication

Communication within the team, while vastly improved, was always a difficulty for our team. Initially our team communicated via e-mail, however this led to problems as certain members would not get some e-mails, and we would have to look back through dozens of e-mails if we wanted to find something mentioned a few days ago. This was solved by moving to Slack. However not all of the difficulties were resolved. There would still be the odd occasion where we simply could not get a hold of some group members or some messages remained unseen. This resulted in work being done by others that were not assigned to the task. Sometimes the task would be done by two individuals, but the original person would never tell the group that they had already done it. This will stop next term as it resulted in several people doing more work than was necessary.

3. Perforce

Our team had great difficulty in setting up version control for the project, and these issues persisted until near the end of the project. We were slightly late in setting up Perforce, instead opting to use Google Drives to zip and rezip the project for the first week of production. When we were all moved to Perforce, some members had trouble setting it up correctly and that also took an extra week to get everybody on board and familiar with the software. Additionally, we would constantly run into errors when pushing, with scripts missing/conflicting, textures and materials not showing up, changes being undone etc. Towards the end we achieved an understanding of the platform and learned to use it with minimal error, although issues with textures still occurred somewhat frequently.

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.

Vincent Slifer PPJ Post Mortem

What Went Right
1. Created Multiple Games for the Motion Base
The primary goal of the project was to successfully develop a game designed for use on the motion base, and I felt that this was accomplished fairly well.  Throughout the weeks, the team worked together in order to create and implement a diverse amount of games to experiment with the different motions of the simulator to create vastly different experiences for each game.

2. Created a Method to Integrate Games

A fairly important aspect of our game was that it was composed of mini games.  We needed a methodology to integrate everyone's games with a minimal interruption with anyone else's work.  We developed a fairly simple system of just creating our own sub folders to sort our games, but it was a good methodology to find assets needed in a quick manner.

3. Collaboration

A very important aspect in team projects.  I felt that everyone worked well together to make the project.  Everyone expressed their ideas to each other at meetings and brainstormed to create new ideas on how the mini games would be presented.

What Went Wrong

1. Version Control

Whether it was an issue with our system for hosting the builds or people updating the build at inopportune times,  there were a few issues with keeping the build updated.  From my experience, Perforce, itself, gave me a lot of trouble and headache.

2. Communication

While the team worked fairly well in collaborating together, there were some issues in communicating with each other.  Some members, including myself, did little to minimal communications on the group slack, and sometimes communicated in methods not fully available to the group.

3. Work Ethic

The team decisively separated members to fields that best suited their abilities, programmers program and artists create art, but the distribution of work seemed off.  From my experiences, I felt that I did not accomplish a lot.  I was able to program the mech game and had a little extra time to test an idea for another mini game, I felt that other members had taken up more of the responsibilities.  While I am grateful that they were willing to take on tasks, I feel that I should have had more work to accomplish.

Moving Forward

Essentially, the group needed a definitive leadership role to keep track of tasks and group focus.  The group needed someone dedicated to assigning tasks for each game, and figuring what needs to be done on a less loose schedule of just one week to complete your task.  The leader role would also aid in keeping members in touch, ensuring people were in open communication or could easily get a hold of them no matter what.  In the end, someone dedicated to being in a leadership role would vastly improve the effectiveness of cooperating with each other and keeping track of individual assignments.

Lessons Learned

- Communicate everything with members

- Ensure lines of communication are open

- Learn how to use the hosting service(s)

- Do not work on projects in the early AM

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

Vincent Slifer Week 10/11 PPJ

These weeks were fairly simple.  I mostly had the job of implementing the art assets for the Mech game.  Beyond that, I trouble shot some errors that occurred from saving the game to perforce.

Positive Content

• Implemented Mech Game Art (partial)
• Debugged issues that came up with overall game implementation

Negative Content

• Essays halted productiveness
• Other classes

Work and Hours
Programming (2 hrs)

• Implemented Art assets
• when available
• Attempted to work out linking errors

Total Work Time:  2 hrs

David Monteleone, Week 12 Journal PPJ, Blog post 8, Personal Postmortem

David Monteleone, Week 12 Journal PPJ, Blog post 8, Personal Postmortem

Communication, Team, Framework, Mini games, Motion base, Personal Postmortem, PPJ

Personal Postmortem

What went right?:

1)      Making a modular system to integrate plenty of mini games.

One of the main goals for the project was to create a system where games can be worked on in small teams and easily integrated into the entire mini game system. Through the use of modular scripting and not creating major dependencies, the team did this well. Moving forward, the team is now able to break out into small groups and create any type of motion mini game that you can dream. I saw this as an excellent breakthrough for the team and was happy to have been a part of it.

2)      Cooperation within the team.

Although the team suffered from a lack of solid communication, the group did get along as a whole. There were never any personal conflicts between individuals that cost us time. I’ve been in far too many groups where individuals end up hating each other by the end of the term. As of now, if the group moved onto next quarter, we have a solid relationship between everyone. I see this as being an excellent asset as friends work together better than enemies. We are definitely a team and work to motivate each other to do their best! As a leader in the group I worked to keep individuals motivated to do their work and wanted the best work from them.

3)      Recovering from a rough start.

I’ll be the first to admit that the team started out pretty rough. We we’re very confused and disorganized. The mini game concept lends itself to getting lost in many different ideas. However, around week 6 after having a serious group meeting, about getting our act together, the team recovered from its rough start and turned our Alien Arcade idea into a reality. Production ramped up, assets got finished, scripts were cleaned up, and real work was being done. I’m proud to have been working on a team that was able to fix so many problems and finish so strong. I’m not sure if my leadership was a part of the recovery, but I tried my best to help the group get out of this hole. I put many more hours than I needed into the game to bring it back up to speed.

What went wrong?:

1)      Communication between teammates.

From my perspective, the group suffered from individuals not keeping an eye on Slack. It also took a couple weeks to get the entire group onto Slack. People simply did not accept the invites to join the group even though they were sent when the group first started. Throughout the term there were situations were individuals would go quiet on Slack and not report where they were at on their tasks for the week. This resulted in myself having to pick up other peoples’ tasks. Sometimes people would do the same work and not realize two people had finished it. This is clearly unacceptable and the team will work to make sure that all individuals are accountable for communicating to the team next term. The leader of the group next term will assure that all teammates are in constant communication with the group.

2)      Version Control

From my view, the group struggled to use Perforce throughout the majority of the term. By the end of it everyone understood how to use it. Individuals were pushing changes that lacked .meta files. Teammates were working on the same files at once, which resulted in painful merge conflicts. The group spent more time than we should making sure that Perforce was taking our changes that we made to the game. For myself, after working through my work for the week it would sometimes take me an hour to properly get my changes into Perforce. The group eventually ironed out these issues, but it did keep our production slow in the beginning. In the next term a Perforce meeting will be held to iron out any issues that teammates having with using Perforce.

3)      Lack of a task assignment and management system.

The group used no task assignment and management system throughout the term. Tasks were assigned on a weekly basis and the team used the status report Excel file to figure out weekly tasks. There was a master task list in the Google Drive, but this was not updated regularly. This resulted in teammates not knowing when certain tasks had to be completed and the general timeline of the production was not set anywhere. I think this is one of our biggest crippling factors. I was very unhappy with the lack of organization we had this term. Moving into next term, the group will utilize Trello to fix this issue as it plagued us throughout the term.

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

I know that the team will fix these issues in the next term. A clear leader will be assigned to the group through a voting process. Sometimes leadership roles were swapped throughout the term and there needs to be a clear leader to look to. The leader will be responsible for assigning tasks through Trello and making sure that all individuals are working on their assigned tasks for the week. There will be no lack of communication between group mates and the entire group will assure that. Before production ramps up in the next term, there will be a Perforce meeting to make sure that everyone working on the game understands how to use Perforce quickly and correctly. The group as a whole will be stronger and better. The issues that plagued us in the Fall quarter will not carry over to the Winter quarter. I will make sure of that.

Lessons learned for future projects?:

My personal lessons learned from this term are:

-          Modular systems are great!

-          Team cooperation is key!

-          Don’t have slow starts.

-          Make sure all teammates communicate.

-          Use version control to work for you, not against.

-          Use a task and management system!

Tags: Communication, Team, Framework, Mini games, Motion base, Personal Postmortem, PPJ

Chenghao Wang, Week 11 PPJ

This week I was busy on making my first build of sensor design project. But I still did some completed feature for Alien Arcade.

As the group meeting discussed, we decided to reposition of the foot model from top to forward, and change the end game object from a massager to a more obvious object in the Space Aim.

Besides, as David found the bug on the motion base, the direction that the motion base moving is not correct as we expect. I think the reason is the motion base system only think moving on x-axis means forward and backward, so I presented a solution for this, and  I think it should work.


Positive Content

- Reposition the foot model works well in Space Aim.  (1  hrs)
- Change the end game object in Space Aim, and it obvious for users to finish the game. (1 hrs)
- Have the solution for the motion base bug. (2 hrs)


Negative Content

- Not much art as I know need to import to the game, so I feel I didn't do much.
- At this point, there is not much work to do as a programmer.

Total Hours for the week: 4 hrs

Angela Buchanan, Week 11 PPJ, Blog Post 7

Interface, Sell

I knew ahead of time that this would be a low production week for me, so my planned tasks were based around tweaking or assisting others.

Unfortunately, I ran into a significant amount of trouble after having my wallet pick-pocketed off of me. Combined with scheduled interviews and critical due dates in other classes, it was a struggle to get much of anything done.

While I wasn't as useful as I would have liked to have been, I did minor updates to the select screen parts and made it easier for my team mates to find the assets.

And because I felt guilty about my asset production, I put a lot of effort into making the sell presentation look more aesthetically pleasing and exciting. The implemented video is not playing smoothly on my computer and power point's compression damages the video too much. I believe this may be a problem on my end, for I run into the same issue with the older version of the sell. 

Positive Content

- Awesome looking sell

- I managed to get some work done opposed to none

- I had a nice Thanksgiving 

Negative Content

- Very low production week

- Critical assignments in other classes had priority

- Stolen wallet caused a lot of problems

Work and hours

Select screen tweaks (.5 hr)

-Tweaks were minor. I broke the file up a bit more and modified the folder in perforce to make it easier to find them.

Status report (.5 hr)

- Compiled everyone's updates like normal

Sell Update (5 hrs)

- Made a lot of changes to the sell to make it more exciting and aesthetically pleasing. I also did minor edits to content to make them fit more thematically with the presentation. I ran into an issue with implementing the video (It is lagging significantly), however I have the same issue with the old presentation. I believe it's a problem on my end. 

I attempted to use power points video compression, but I did horrible things to the quality. Thus I promptly reverted it back to it's original form.

Total Hours: 6 hrs

Riley Stewart, Week 11 PPJ

Mech cannon- 3 hrs

With the project for the term coming to a close, the finishing touches need to be put on the project. For me that involved making the mech canon model, as the original plan of texturing the control panel was reassigned to Angela, being better at color work. Unfortunately I didn't have much of a break, as all of my time was taken up by family obligations and upon returning I had to do work on all the other finals I had going on. So the canon model was fairly straight forward, once selling on a design, it was just a short bit of modeling to be done. The canon was needed before I could texture it though, so that will be left for next week.

 Positive
- final modeling asset finished

Negative
- small amount of time available, despite break

Total Time Spent - 3 hr

Cory Zicolella, Week 11 PPJ, Blog Post 7

Creating Textures/Editing Models for Mechanized Warfare - 4.5 hrs
Trailer v2 (Footage Edit) - 1.5 hrs

This week I was tasked with getting textures on all of the models I had previously made so they look pretty in the new mech environment that I also modeled and textured.  I managed to complete this task for every model except for two; the waves and the lifeguard chair.

This first part of my work this week probably took alot longer than it needed to only because I'm not trained well at all in texturing; in fact I was initially told never to texture with UVs and only use projections (go figure, that was horrible advice).  So not only did it take me long to do relatively simple tasks, I also had to get help from online tutorials and forums when something went wrong, and in rare instances contacted Riley to assist me.  Whenever I ran into a road block it either took a time longer than it should have (I feel) to fix it because of my inexperience, or I found myself redoing textures because Maya would randomly decide to crash multiple times -- this is partially why the lifeguard chair was never finished (After 7 crashes I lost hope).

The alternative work I did for this week, which was not originally done, but touched upon because I had time, was to give the trailer a much needed footage update, to include all of the most current build's games as opposed to the Alpha I versions.  This took about as long as expected, and came out really well.  Because I did this update now, that means next week I'll only need to add footage updates if it is required from polish, and to redo my voice over in an actual studio with a better mic.

All in all, and considering it was Thanksgiving the week before, my inexperience in texturing, and the fact that I actually had become sick a few days ago; I feel as if I did a good amount of work for what I set out to do.

Content Positive
- Most of the models for Mechanized Warfare are textured! - 4.5 hrs
- The new trailer looks great and is a truer reflection of our game! - 1.5 hrs

Content Negative
- My inexperience with texturing lead to difficulties that probably wouldn't exist if I were well-versed with doing it
- Getting sick sucks
- Thanksgiving happened.  Which sorta impeded workflow.

Total Time Spent - 6 Hours