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.

Creature Animation Review

The creatures will have six limbs, not including the tail. The two closest to its head will operate primarily like arms and be used for attacking while the hind four will be used to scurry around the station. It will be able to raise its head to approximately 8’, or keep it low to the ground. This variety should add tension as the creatures is able to raise its head to spot the player, or remain low and out of sight as it searches.  It was modeled in Modo with an emphasis on modelling for animation. Edge-flow allowed for proper deformation in all six extremities as well as the two torsos. Revisions had to be made to shorten the back section of the monster in order to work with the pathfinding programming. This ended up helping to reduce polycount which was another issue that arose during development.

For future work, creating character sets to allow for all animation to be brought into a single file will be considered from the start. I was unaware of this technique until the issue of having multiple animation files arose at the. There are other ways around it but they were not compatible with the programming structure in place.

Jon: Post Mortem

The Good:

Casual Communication - through facebook and after class.

We were able to begin iteration early which helped compensate for a lack of predetermined gameplay design.

Dylan Yates

The Bad:

There were issues with getting things turned in with enough time to pump out a build, then playtest and create presentations based on the playtest results.

We didn't have anyone to design the game.

Git

Creature Modelling Progress

This is the progress towards the creature model so far, Some issues that have been encountered include the polycount with which I was a bit to liberal, and the potential need for the model to be encompassed within an upright capsule in order to function correctly within once of the navigation softwares. Oh, and it doesn't have a head yet, but that is the most straightforward of these issues. All things considered, I'm glad that this work was but in early to allow for these revisions and considerations.

And Then There Were Monsters...

here are some of the iterations that I came up with when brainstorming ideas for the monster. As they were drawn, conversations on anatomic believability, ease of movement or animation, and creepiness arose. The final orthographics will be posted soon and resemble the last picture the most.  The motivation came from a combination of the two monster concepts that were submitted with our five pager (in an earlier post). The slug/spider looking one captured the movement of slipping around that was favorable. While the other, more humanoid, one was going to fit within the environment better and be able to see the player more easily.

Cover of GDD

An initial design for the cover of out GDD, it will most likely be cropped to isolate the hand before being included in the document.

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.

Player P.O.V. Mock-Up

An orb of light is being launched from the energy gun the user will wield, and the light just barely catches the claw of the monster in the door-frame.This is a mock-up of how the game layout will appear to the player and the general lighting and atmosphere that we are striving for. It is not indicative of the end goals for the in-game art as a more realistic approach will be taken with texturing. One evident absence is that of the GUI, which hopefully will be avoided by indicating to the player the amount of energy they have left on the gun (through the glowing bars seen on the side). Hopefully this will allow for deeper immersion.

Creature Concepts

Some initial concept work for the Creature aboard the station. The humanoid one in the lower left is going to be developed further. The other one (with a front view at the bottom and a side view at the top) is sort of a cross between a spider and a slug. It was created with the idea of being able to move up the walls and onto the ceiling as well as being low to the ground and hard to spot. However programming the creature to behave as desired while moving from surface to surface is out of scope for the current project. The humanoid character is easier to program and will provide for more advanced animation.