Post Mortem and Moving Forward

Post Mortem

Each member of the group was tasked with posting their thoughts about the good and bad aspects of this term. There is of course additional feedback (view-able below), but the summarized version of these results are as follows:

The Good

Dylan Yates - The entire team has agreed that Dylan was definitely one of the biggest factors leading to the success of this project. He did a disproportionally large amount of work, and that was due to our extreme confidence in his ability to use Unity. Without him, the project just wouldn't be what it is now, and we owe him big time.

Steady progress, regardless of setbacks - We had a new build each week that was noticeably improved over the previous week's. Regardless of assets being late or not turned in at all, we were able to push forward. This gave us a huge confidence boost as we moved forward. This was definitely the result of good team work and time management on an individual level, as well as group-wide.

Good overall team flow - This is broken up into a few categories.

• Casual communication - Our group seemed to meld together very well. It didn't seem like anyone was afraid to put their voice into the project, and we were able to communicate well because of this. There were some issues, as any group will face, but we were able to overcome them and deliver a great final product.
• Group diversity - We had a large enough group to give each person a specialized role. This allowed everyone to contribute their best skills to the project instead of having to take time to learn something they weren't necessarily as comfortable with. In a fast paced project like this, we didn't always have the luxury of spending a week or two to learn something new.
• Individual Cooperation - Our team did a pretty good job working together and getting stuff done for most of us having not worked with one another before. There were of course issues at times, but even then the issues didn't completely stop the flow of workand could have been much worse. For the most part, we met all of our deadlines and provided high quality work, and we are proud that our team was able to do that.

The Bad

Level Design and Audio - We didn't have a designated level designer or sound person. The level design was mostly a team error, with no one wanting to take the lead on it, but we were not assigned a sound person and had to find someone outside of the class. Due to the lack of a dedicated game designer, the final game level is a little dry. Without a dedicated audio designer, we also missed out on a lot of atmospheric tension.

Management and team consistency - This is more of an overall disappointment in Evan and myself rather than the rest of the team. There were times earlier on where we think we didn't micromanage as much as we should have, and it may have ended up hurting the quality of the project at times. This is could be due to our inexperience with managing, but personally there were times when I didn't want to push other teammates to the point of them getting frustrated with me. I thought that this would break the flow of the team and be detrimental to our success. We now know that that is the curse of being in a management position, however, and we definitely stepped up our game towards the end of the term.

A few things that should have been stressed early on:

• Naming conventions - Most of the people ignored the naming conventions that we agree on. It didn't show the downside now, because we don't have too many assets. It would become more and more of a problem as the project goes on.
• Strict deadlines - There were issues with getting things turned in on time to the point where a formal policy had to be written up. This led to situations where code might not work with the newest assets. Path-finding was a large problem, with Ryan rarely having enough time to re-calibrate after new level designs were made. This left Dylan with barely enough time to pump out a build, and even less time for playtesting and creating presentations based on the results.
• Communication - This was one of our biggest problems early on. At times, it wasn't clear what people were supposed to be working on and when it came to the time it was due, nothing was handed in. Eventually we figured out that all of our communications needed to be posted publicly so everyone knew what needed to get done.
• Distributing work - It seemed at times that not everyone was putting in the same amount of time and effort into the project. This may have been due to an individual just not performing as well as they could, but there was also a lack of even distribution. This is not entirely due to the group communication, there were just times when something came up on the fly and it was just decided by someone to do it themselves rather than send it to someone else in the group.

Git - We had our fair share of technical difficulties with Git and Unity. Doing pretty much anything with Git would involve the repository getting messed up and we were forced to re-clone it. There was also the issue of Git not knowing how to handle merging Unity binary files Each time someone wanted to work on the project they had to notify everyone else to make sure no one was working on it, then they had to manually download the latest version, make their edits, and re-post. Git worked well for scripts, but since Dylan and Ryan's work rarely overlapped, we didn't get to leverage that. Git also worked very poorly for models, given the nature of their file structure.

Overall, the group agrees that we worked together well. And even though we had our issues, it was definitely as great learning experience for all of us.


Moving Forward

Our group met up for a discussion on what we would like to see moving forward.

Administrative

• Spend a week going through the project to clean everything out and fix up any inconsistencies.
• Master asset list.
• Team communications need to be improved.
• Stricter deadlines.
• Plan for when people miss deadline.
• Stronger structure.
• Teamwork PM rather than Facebook.

Art

• Art "manager" to ensure consistent art direction
• Naming conventions need to be followed.

Programming

• A list of what we need to program to distribute work better.
• Comment code.

General

• Have the Creature setting "seeds" or something to that effect, making it evident to the player that they are trying to cultivate the station for themselves to live in.
• Puzzles.
• More interesting environments.
• Multiple monster types.
• Better "cat and mouse" mechanics
• Audio! Consistent and higher quality audio. We need a full audio director/engineer.
• Dedicated time to meet up and work together.

Evan: Postmortem

Things are coming to a close this week and it's time to do a brief personal postmortem. We decided each person should individually write a mini version, and we'd bring together our ideas for a longer one.

The Good

• Not being overly ambitious: Early on, we took a pragmatic approach with what we could and couldn't do in ten weeks. This paid off big time. We didn't over-promise too much, and we defined an idea that we could - and did- build.
• Regardless of short term setbacks, we improved: Each week, we had a new build that was noticeably improved than the previous. Regardless of assets being late or not turned in at all, our weekly build improved.
• Dylan Yates: He did an unproportional amount of work, and without him the project wouldn't be what it was. Dylan, if our project moves forward, I promise this will be fixed!

The Bad

• Management: This is more of a disappointment in myself rather than the rest of the team. There were times where I didn't micromanage enough and it ended up hurting the quality of the project at times.
• Not having a (used) master asset list: This would have been helpful to have for obvious reasons. I created a master list late in the project, and it was unfinished and unused. We should have created and maintained a list earlier in development. This is necessary should our project move forward.
• Deadlines being missed: This was stressful for a few reasons. When things are late, I had to go find out  the reason why and when they'd be in. When it became a problem, I had to be Mr. Manager and give serious talks. That wasn't fun.

11/21 Class Minutes

Today's is a big update! Our game is coming along nicely and nearly finished. We have some heavy texturing to do, some sound changes, and polish - but we're nearly there. We presented an early version of our final sell presentation today, along with our newest build. We got great feedback and positive input, and it felt really great to finally hear that our product is become impressive.

Here's the notes I took today on both our sell presentation and our game demo.

Sell feedback (The number corresponds with the slide number)
2. Make the 'imagine' parts pop up one at a time
3. after 'you hear noise', jump to 'now you're on a spaceship'. Not straight to Game Start screen.
4. After 'on a ship', then game screen.
5. ??
6. Blend art and story here, don't separate. Incorporate screenshots. This goes for other slides too
7. Intended audience is good, just put intended rating as well
8. Introduce character > story > what player doing > intended audience (in that order)
9. Don't list individually. Maybe ditch slide. As we put images, we can mention some of these things. Demonstrate these, don't list. Video?
10. Include this on the story
11. Include this after story? Gameplay slide? Can go into small detail as to how the creature is finding you (heatmap)
12. Great slide. Maybe get scale, get better pose of Henry. However, this is a little deceptive to in game - creature seems smaller in game than this screen. Reared up pose in game to demonstrate size and fear?
13. don't break this out. concept art is great, try to get matching screen shot. This doesn't need its own slide, should be in gameplay explanation
14. This screen shot could go with story. don't title 'Demo Scenario'
15. good, same as above
16. this shouldnt be seperate slide. incorporate these slides throughout
17. get updated gun model. ditch concept art. this goes with gameplay, doesn't need its own slide. Have gun pictured with energy pickups, show they work together.
18. have gameplay demo, then Question?

- Less lists and back and forth
- Video right before game screen? Want to give them sense of fear before game screen.
- Too much back and forth between story and gameplay, have it flow better.
- If we show Henry, needs better poses and look.
- Introduce Henry before explicit story. explain why he's the only one. show game screen, then talk about Genry and why he's only one there
Demo
- Audio/visual clue when pickup ammo
- More monster audio
- Make generator spin, turn on lights? make it more obvious that its now on. give more payoff, a clue as to what's next? cliffhanger!
- Footsteps frequency needs to be upped
- More scares! valves and pipes bursting? lights that were on turning off?

11/7 Class Feedback

Today we presented our week 7 scrum. Overall feedback was positive and we've made some great progress. Things we need to work on over the next few weeks are implementing sound effects, getting animations in, and texturing the world and objects.

A lot of players seemed to be confused about what exactly the generator was, and they had trouble figuring out what to do once getting out of the intro room.

We also need to figure out a way to convey to the player that the monster should not be shot, and can't be killed. While most people figured this out on their own, most players attacked it first.

We also need to work on the alien's vision distance. Right now, in the dark, he can see you from very far away. Originally, we wanted the monster to be pretty blind in the pitch black parts of the game, and it would only find you if it bumped into you in the dark. However, he'd have no problem seeing you from a distance if you were standing in light.

We need to polish up these aspects of the game, but so far so good.

New Group Policies

Due to last weeks chaotic submission process and deadlines not being met, we have come up with the new policies below.

New Submission Policy: We now have a Deliverables spreadsheet on Google Drive, which can be found here. Each week, your deliverables should correlate with the Gantt chart (also on Google Drive). Send your assets to whoever is listed in the "Submit To" column, by the date and time in the "Submit Time" column. The receiver should then provide feedback to the submitter, and let them know if revisions need to be made. After the asset is deemed finished, the receiver needs to sign off on the spreadsheet, and graded on a scale from 1-5, (1 is bad, 3 is average, 5 is great). This grade will not affect your Diefenbucks unless the quality is a 1 or 2.

Deadlines: All art assets should be sent to Dylan by Tuesday morning. If they're not in, you'll receive a 30% reduction in your Diefenbucks for that week. If they're still not in 24 hours later (Wednesday morning), you'll receive no Diefenbucks for that week. Note: If people abuse the 30% reduction, we'll up it to 50%.

Diefenbucks Distribution: The Diefenbucks we receive each week will be distributed evenly among the group, provided there were no penalties for an individual. If there are penalties, the Diefenbucks they forfeited will be evenly distributed to the other members of the group. For example: we have 8 members in our group. In one week, we earn 8/10 bucks. If every person does their work without any deadline penalties, each person receives 1 buck. However, if Evan was late on his submissions within 24 hours, he will receive 0.7 bucks and the rest of the group will get 1.04.  If he's 24 hours or more late, he will receive no bucks, and everyone else will receive 1.14 bucks.

Oct 17 Class Meeting

Today Cory presented our Week 4 scrum presentation which can be found here.

Our presentation overall was good, and we got a few tips on how to improve it. I took some notes.

• Compare what we said we'd do vs what we accomplished (relate it to the previous week)
• How successful were we, self reflection
• Art
• Show concept art vs prev week vs current
• Art asset checklist overview (show overview, table)
• Gun concept as player would see (player perspective)
• World assets need to fit the theme better
• Programming
• Basic ideas of scripts that were made that week, what they're based on
• "For Next Week" section
• Organize by category
• Programming, art, audio,
• As a whole section

We also had some discussions about our game and debugging menu.What we have so far is a great start, but we need some debug options for the enemy, including speed. For our debug version, we should also show the player's HP.

Lastly, we also really need to hash out our monster, and what makes it scary. It's possible we'll have to do some redesigning of it if players don't find it scary.

Next week we'll have our first playtesters play through our prototype level and give us basic feedback.

Oct 10 Class Meeting Feedback

Today we presented our first 5 minute sell presentation, our prototype, and scrum presentations from the past two weeks.

We got some valuable feedback for all of them, which Jon wrote down and I'm recording here.

Feedback on our Sell Presentation

• Have a more interesting, not all-black background
• Include more images
• Have some kind of teaser in the beginning
• The title slide should have a tag line
• Realism - it isn't unique
• Be careful with setting the bar in relation to big-name games
• Go more in-depth on sound and light
• "Story" instead of where & when
• Character portrait sketch
• Research station sketch
• Paint a consistent mental picture for each person in the audience
• Relate 'who it's for' with fans of other games
• Why we are making it/marketing, why people will buy
• What does the player...
• do?
• know?
• see?
• how do they know it?
• why is it fun?
• Potential design idea: monster consumes energy orbs, gets energy/speed/power
• Perhaps in the dark, player's cant tell the difference between colors, possible puzzle?
• Whole team participates in next sell

Feedback on Scrum Presentations

• Background has same problems as sell
• Role-specific tasks (who's doing what)
• Don't jump back and forth between things (Don!)
• Sufficient detail on how things were done
• Videos of animations
• Psuedo code
• Pics of models
• Give enough detail for critique

October 3 Class Meeting and Feedback

Today we had a class meeting where we presented our five-page pitch, and received a lot of valuable feedback.

There are a some core concepts we need to fix about our game, and define in our game design document, which is due Oct 10. They are the following, in no particular order.

• Define our HUD: We don't plan to have any sort of HUD, but we didn't make that apparent in our five-page document. Are we going to have even a small dot as an aiming reticle for throwing objects? (Yes, they will have a minor aiming reticle)  How will the player know how much health Henry has if he gets injured? (Red boarder around the screen that gets more intense as they player has taken damage). No minimap, no gui, except for aiming reticle
• What are the specific in-game objectives? How will we convey where the player needs to go and what to do? Unsure at the moment. In the demo, maybe small gui text will tell them they need to fix something at the start of the demo? Long term, I think it would be best if Henry had like a mental checklist the player could pull up of things he needs to do. What are the end game conditions? If the player is killed by the Creature, or if the player solves the 2 or 3 puzzles we have for the demo.
• What is the expanded vision for our game? If we could take it further, what would this game be, and what will the vertical slice be? Is there a possibility of a series? What is the lifetime of the game?
• Define Henry and the Creature: What are their individual strengths, weaknesses, abilities, size, and specifics? Compare the two in relation to each other. Who's faster? Who can see better and hear better?
• The Creature:
• What is it's origin?
• What exactly does it look like?
• How did it get on the ship?
• How does it move and follow Henry - will it always be in the same room as him?
• Can it see light through walls? Hear through walls?
• Melee only? Is it a one-hit kill?
• Does Henry have a chance to get away if he's spotted?
• Henry:
• How many hits can he take before he is killed?
• Concept art ideas:
• Player shooting a ball of light while the enemy is somewhere on screen - maybe with the Creature taking notice. Something in an open room, more representative of the environment a player would see in-game.
• Puzzles: We need more explanations on our puzzles. What are some specific examples? How will the LEG be used to help solve them?
• What are some specific scenarios where using the LEG will present a fair risk and reward?
• Checkpoints: Will we have them? Is it game over if you die? Unsure. Lets talk to the programmers
• Safe zones: Will there be any? I would say yes in the full game, but I’m not sure if our demo will have any.

September 30 Meeting Minutes

In attendance: Ryan, Jon, Cory, Dylan, Miguel, Don, Evan.

After we all threw around a few ideas, we agreed to keep the horror idea for our game, but with new mechanics and a completely different setting. It would take place aboard a space ship that has lost power, has been damaged, and is now stranded in space. The player's goal will to repair certain parts of the ship, while avoiding a creature. Light and sound will both play an important mechanic, as the creature will be attracted to both. The player will need to navigate the space stations using a gun that can create orbs of light, and also be used to solve puzzles.

September 29 Meeting Minutes

In attendance: Don, Jon, Dylan, Miguel, Evan
We met up today to further refine our ideas for The Unseen.

Miguel and Jon liked the idea of setting the game underwater. Their idea for the demo was this: the player would be controlling a diver in an old-fashioned style diving suit. The player would be tethered to a submarine, and exploring the ocean floor. Suddenly, there would be a violent pull from the tether, and the character would look back to see the submarine crashing down to the ocean floor and into a deep crevice. To avoid going down with the ship, the character would cut his tether which would seal his suit, giving him a limited amount of oxygen. The player would then navigate to the crashed submarine, and have to solve puzzles in order to repair the submarine.

While we liked the idea of setting the game underwater, Dylan and I were hesitant to try this because of our limited time to complete the game - we thought it would be difficult to give the game a realistic look and fill in such a short time span.

The team deliberated on our horror idea and tried to refine it by giving the game a theme and setting. We went through many different iterations for the setting, theme, objectives, puzzle types but we didn't settle on a single, solid idea. After two and a half hours of discussion, we agreed it would be best to give ourselves 24 hours to come up with self-refined ideas for a first person horror game, or come up with a completely new pitch for an entirely different game. We agreed to meet on the following day.

Week 1 Pitches (History)

Our team came up with two different game pitches this week.

The first idea was a side scrolling 2.5D  platformer called Subject 52. The player would pause the game and give game objects a path to move along, and when the player unpaused the objects would start moving in that direction. The player would use this mechanic to solve puzzles and advance through the levels.

The second idea was for a realistic 3D survival horror game called The Unseen. It would take place in a dark environment where the player would have to avoid being seen by a monster, which would be attracted to sound. If the player made too much sound while moving or running, it would attract the monster. The player could ideally use objects to distract the monster, and sneak past him.

We sent off both pitches to Professor Diefenbach, and received feedback that both ideas needed to be refined.