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.

Changing on texturing

Thank to CrazyBump, I don't need to do a lot of the shading and bumping by myself.

That's why I'm trying to add OCC map to the texture and hope that it would make the result more polished.

OCC map makes everything looks more dirty, when doing modular level building , dirty is good, because you can hide seam this way.

The way I handle seam is by purposefully leaving it black. See the black line runs across the picture? There is a seam and no matter anything wrong with the game engine, this seam will blend in beautifully.

Starting on Texturing - Week6

I went on my quest to study how to do environment correctly, it's totally different from how school taught it. I cried a little bit inside to find school works were not so helpful:

This is a picture of almost finished tunnel:

And thanks this awesome app CrazyBump, bump map has never been so easy!

Look at my texture map, bump map and specular map:

I'm now looking at 

Progress On Environment Modeling -- Week 04

This is the first version of a energy room model I made. And it's also the first room model I made for games. I say it's looking not bad.

We decided to make each trunk of the environment by 10s. This room is made out of a 30 by 30 box. I cut all 4 corners to make it a 8-sided room.

The benefit is pretty obvious, I can make things and duplicate them by 90 or 45 degrade angles.

Just heard from Dylan that the pipes are too high poly, I guest it's time to smooth things up!

Progress on Environment _ Week03

As I'm doing modular environment design, I find the more I try to make something continuous, the harder for me to model.

Making the transaction piece

2 way done

3 way done

Solution for Environment Modeling

First of all, this article is the Bible for level design:

http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html

After seeing a few tutorials, I came up with a way to make level design modular.

First, I figured out how to snap to grips and line up objects perfectly in Maya:

(keeping the pivot at a corner is a good thing.)

(I seamlessly snapped two plants to a cube by selecting constrain to grid and point in Maya)

Since it's a horror game and the levels only feels right by testing them and play with them, I created 9 20 by 20 Maya unites tiles for level designers to work with( two sizes of doors, a floor with a wall, a straight corner, a floor, a wall, a curved corner, a block, a staircases):

While level designer can play with those tile. I may start learning some more texturing techniques and start painting something.

Getting started on Environment: Concept and Prep

I'm a pretty systematic when it comes to design. Some artists may start by drive right into drawing and see what works. However, I have to have a back story for the environment at the back of my head; I have to know the exact layout;I have to know exactly how to make thing. And most importantly... I have to be inspired.

Those are some images and resources I looked into for environment concepts:

layout:

https://www.google.com/search?q=spaceship+layout&source=lnms&tbm=isch&sa=X&ei=lf9VUsaXDs2g4AOHq4HQCQ&ved=0CAcQ_AUoAQ&biw=1642&bih=898&dpr=1#q=spaceship%20floor%20plan&revid=1959306252&tbm=isch&imgdii=_

I don't know how spaceship will do layout, so it's good to look up how people designed them.

Environment retargeting:

http://www.polycount.com/forum/showthread.php?t=89682

Environment Modularity:

http://wiki.polycount.com/CategoryEnvironmentModularity?highlight=%28%5CbCategoryEnvironment%5Cb%29

A simple tutorial on snapping to grids in Maya:

http://www.worldofleveldesign.com/categories/3d_modeling/maya-tutorial-for-beginners-09-snap-tool-pivot-move.php

Just testing the round motif:

There are so many goo stuff on polycount that I can't even appreciate it enough!!

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.