Update Week 07

All hands on deck! This week's update features the protagonists' hand - it now exists , animates correctly for the most part. From here on, we're going to focus on mastering the protagonist's hand and animations along with building and texturing more models. Because the player will spend so much time seeing the hand and arm, we have to make sure both look and feel as natural as possible. 

The build can be found here. Remember to download both, but only run the html file.

Week 06 Build

This week's build brings about a slew of visual upgrades. First, we're now using a new set of lights we purchased from the asset store. The new lighting effects are much more realistic looking than the standard ones Unity includes, but they come at a slight performance hit. For now, they're going to be kept until they become an issue on the laptop Intel has provided for us. This week's build also has some new models of various world items, a much more fleshed-out ICU (which will also serve as the tutorial), and various other improvements.

The files needed to play can be downloaded here. After downloading, just run the html file!

Week 05 Build

Another week, another build! This week's build features better lighting, but not much else functionality-wise. The teams are busy on programming new functionality and creating new models, including the alien. The game can be downloaded here - make sure to download both, and run the html file.

Week 04 Build

Week 4 is the first week we have an actual, playable build since we basically started the project from scratch this term.

In this build, we have crafted a level that was designed by Kenneth and Jon. The amount of lighting is very low, as we want darkness to be a strong aspect of the game. This build also shows off our use of substances, which are lightweight and easily modifiable textures. These were purchased from the Unity store, and are used to texture all walls and floors.

The build can be found on our Google drive here. Make sure to download both files, and start the game by using the html file.

Welcome to Part 2 of Development

This project was chosen to continue for the next subsequent term to be worked on by both sections of the class. This blog will serve to document the progress of the game, with notes on weekly builds, design decisions across the board, presentations, the game design document, and more! Due to the sheer size of the team (and the amount of meeting minutes that go along with the team!), we have decided to house the notes elsewhere.

Now that the team has expanded, we hope to make significant progress on The Unseen in the coming weeks with the goal of polishing the game for the Game Developer's Conference in March. Until next time!

Trailer

Last night I put the finishing touches on the first draft of our Trailer! Future drafts hopefully will implement motion graphics.

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.

Ethan: Post Mortem

The Goods

Talented Technicians- Our comp sci. team was quite a talented bunch and managed to implement a variety of features and consistently make them work. Dylan Yates and Ryan both did an impressive job. I'm not positive of Cory was a coder as my work rarely coincided with his but if so no doubt he did an admirable job as well.

Solid Art Style- Between Don's research into modular level design, solid hallways and rooms, Jon's awesome monster, Miguel's well textured light emitting device and my rooms and assets we had a really good style and atmosphere that I think was one of our strongest suits when combined with the powerhouse programming and game design.

Good Management- Cory Dylan and Even were fantastic managers and did a great job maintaining a steady stream of communication in terms of what needed to get done when.

The Bad

Timing- This term took place in the middle of coop season for many of the students within the class and I believe that contributed to at least for parts of the term some people being less dedicated than others. Interviews also slowed down our progress over the last few weeks of the term

Level Design- We didn't have a clear lead level designer because no one stepped up to the mantel for whatever reason. I hope to be able to work on this if we continue to move the project forward. Dylan Yates gets mention for doing a damn fine job anyway despite that he was doing so much programming.

Audio- We also lacked a solid committed audio designer. We made due still, but missed out on a lot of atmosphere and tension that could have been utilized.

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.

Don: The Unseen Termly Post Mortem

We have pretty good turn out over last 11 weeks. We started from a vague idea of making a horror game to fully developed vertical slide. There were definitely things worked well and things to improve. Personally, I'm glad that I can deliver an art style that is not what I would usually do and still appropriate to the concept of the game.

The Good:

1) We have steady progress on our game each week. Each week we have more about our game to show and each week the game gets better. It's definitely the result of good team work and good time management on individual level. It also give us confidence as the project moves forward.

2) We spend enough time making the actual in-game assets, which also result in a better developed visual. It relates to the point above. I researched on modular environment design and decided it would be the best solution to deliver a large and explorable environment with less work on making the actual 3d models. We spent 4 weeks on making the 3d geometries and 4 weeks on texturing and 1 week or so on lighting. It's a pretty good scheduling.

The Bad:

1) Name 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.

2) Game design. We don't have a dedicated game designer on the team, which result in the final game is really dry. With that said, maybe we have some resources inefficiency issues, too. Since some teammates only committed no more than 3 hours of their time some of the weekly. 

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

Dylan: Postmortem

The Good...

• We had enough people to give each person a specialized role.  This allowed everyone to contribute their best skills to project instead of people having to take time to learn new skills.  In a fast paced project like this we didn't have the luxury of spending a week or two to learn new skills.
• Our team actually did a pretty good job working together and getting stuff done.  That wasn't true all of the time but things could have been much worse, especially when you look at some of the other groups.  For the most part we met all of our deadlines and provided high quality work, and I'm proud that our team was able to do that.

 The Bad...

• Communication was one of our biggest problems early on.  It wasn't clear what people were supposed to be working on and when it was due so we ran into a few situations where work didn't get done.  Eventually we figured out that all of our communications needed to be posted publicly so everyone knew what needed to get done.
• Not everyone put in the same amount of effort into this project.  Some members of the team were very passionate about the project and went above and beyond to make the game better.  Others only did the bare minimum of what they were assigned to do or submitted substandard work.  It would have been nice to see each member of the team put in a comparable amount of effort into this.
• We had our fair share of technical difficulties with Git and Unity.  Doing pretty much anything with Git would involve the Git repository getting messed up and being forced to reclone it.  Also we weren't able to use the main purpose of Git since we cannot merge Unity binary files.  Every time someone wanted to work on the Unity project they had to notify everyone else to make sure no one else was working on it. 

Week 10/11 Feedback

Mostly minor things. General feed back was that the game looks really good.

Sell Presentation:

• Elaborate more on audience
• Why should someone play our game vs other games?
• Possibly go from demo to more detail about the game
• Talk about future plans
• Address replayability and game time
• Talked about LEG before it was introduced. Stop that.
• And stop saying gun.
• Add to intro slides "All you have is a flashlight"
• Address why the player isn't shooting the Alien in the demo. Say this in presentation.
• Almost too easy to power Reactor, add more of a challenge.
• More creature noises. We don't want them sneaking up from behind.

Scrum:

• Sound is weak, improve both effects and as a mechanic (not for next week, but term)
• GDD isn't just what you've done, but where you're taking the game. What enhancements are coming?
• Address player feedback in the presentation. Give summaries of feedback, and tell us where the game is going.

Note: Maybe we could make it so that the Creature hates light and wants to destroy it/put it out? This would explain why he follows light orbs. We could eventually have an animation of a creature ripping a power station out of the wall. That would be cool.

Diefenbucks Distribution

The current distributions for our Diefenbucks can be found on this spreadsheet. The spreadsheet is updated every time we receive our weekly totals.

Team Communications

After being instructed that we should have our communications archived and in a more public domain, I will be working over the next week to transfer our communications from the facebook group to a new tab on this web page.

I will create a new blog post for each week's communications up to and including the current week, and will be encouraging the other members to post any updates they have on this new page.

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?

Level Design Update

After a few rocky starts the final drafts of specialized rooms are being implemented in the overall level design. The Lab, The Bridge, and The Biodome are some of the varied environments the player comes across during their quest to save the doomed ship. Also seen are some attractive shots of our main protagonist

.

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