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 

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.

Playtesting: Round 1!

This past week was our first official round of playtesting! The results are in, our game is...

"...too scary to keep playing!"

At least that is what one of our primary critics told us. It was then followed up with a swift, "...more of a fan of the brightly colored, puzzle like games...", and, "...don't make fun of me!"

Our main focus for this week's playtesting was to try and get some environment variables set in stone.

The majority of our play testers were male, with only four females participating out of the thirteen total testers. The general consensus is that we need to have either text pop-ups or a quick "tutorial level" before throwing the player into the game, with most playtesters responding that there was not enough initial direction for them to know how to move forward. Testers also desired a darker environment, as the current settings made it too easy to see in the dark.

With the Creature AI still being in development, the testers made sure it was known that it was way too easy to avoid and escape the Creature.

The L.E.G. light orb mechanics drew a divide amongst the testers, with the results of being nearly a perfect 50/50 split.

The complete results can be found here.

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.

Playtesting v1.0

In preparation for the upcoming weeks of playtesting, an initial playtest survey has been created and can be found here:

The Unseen Playtesting Survey

This survey focuses mostly on environmental variables and general mechanics, so that we can determine the best setting for each variable. Later surveys will focus more on actual gameplay.

This week, each member will be taking the survey themselves, as well as giving the survey to at least one other person.

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!

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.

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.

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

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

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!!

Lighting, Shadows, and Functionality

Here are some screenshots from the "cubes and spheres" demo.  The functionality for the Light Energy Generator has been prototyped, allowing the player to charge and fire an orb of light into the environment.  The player can also pick up and throw objects like crates, but they will make a sound when they hit the ground.  The preliminary tracking algorithms for the monster to track light and sound have been developed and an AI character will seek out the most attractive light or sound.  Lighting and atmosphere will be key to bringing our environment to life.  We are showing off a few features here that we plan on using as we continue development.  These include realtime lighting, dynamic shadows, bumped specular shaders, ambient occlusion and bloom.

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.

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.

The Unseen: First Contact Five-Pager

Our five page pitch document can be found as a Google Doc here.

It's quite long, so I won't put the whole document in a post.

The Unseen: First Contact One-Pager

Our one page pitch can be found as a Google Doc here.

------------------------------------------------------------------------------------------------------------

The Unseen: First Contact

Overview

The game places you aboard the “Extraterrestrial Examination Station”, where the player controls Ensign Henry as he struggles to escape the Broodmother, an alien creature that has broken out of its containment cell. Armed only with a device that creates balls of energy, the player must explore and repair the ship while trying to avoid the monster at all costs.

Category

First person horror with environmental puzzles that have multiple solutions.

Features

• Environment: Many of the ship’s core functions have been disabled, including lighting. This creates a constant feeling of suspense and urgency.  The environment will also contain objects for the player to interact with.
• Stealth: Because Henry is not a fighter, the player must use the environment to avoid combat. Sound and light attract the alien, so the player can make use them as a distraction, but must avoid drawing attention to himself.
• Energy gun: The player decides when light is needed to explore and solve puzzles, and when it is a liability. Light can also be used as a tool to distract the alien.  However, the energy gun has limited power and recharges slowly, so the player must use it sparingly.
• Puzzles: Physics and environment based puzzles will be throughout the environment.  The energy gun will also be used in puzzles as a way to power certain objects in the environment which may help the player but cost valuable energy.

Level Design

The entirety of First Contact takes place aboard the E.E.S., a man-made space station orbiting just above the Earth. The demo will consist of a single level split up into multiple sections. However, this can easily be expanded into a multi-level structure if it is deemed appropriate or if we move forward.

Graphics

The game would have have a realistic 3D feel. Realistic textures, models, animations, and sounds will be implemented. Lighting will be a key factor for the ambience.

What Makes it Special

• Atmosphere: Immersion and ambiance will be the core values of the game. In a dark, disturbing and unnatural situations, the player will feel tense and uncomfortable.  Lighting and sound will be integral to convey the horror aspects of the game.
• Sound: The ability to use items and the environment to make noise to attract or distract the alien will be a major part of the game experience.
• Light: The player has an energy gun that can be used to fire an orb of light into the environment.  Light orbs will fade over time, and making brighter orbs requires more energy. The player will need to find resources to improve the gun over time.
• Multiple solutions: The player will complete puzzles that vary in difficulty and have the ability to complete puzzles in various ways, which alters the game experience. If the player chooses to complete a puzzle by a quick “brute force” method, it will be faster but noisier. If the player goes for the longer, more challenging route, it will be much quieter. The puzzles will be grounded in reality and not break the immersion or flow of the game.

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.