Chris Lucas | Week 9: Rem@WakeUpYou'reInAComa

Chris Lucas | Week 9:  Rem@WakeUpYou'reInAComa

WEEKLY NARRATIVE

My focus for this week was animation, and rushing to get as many of those as I could in a workable state since we're getting towards the end of development. Mocap scrubbing actually went rather smoothly, but with a new model there will always be new changes that need to be made to animations. The parts of the model that broke are a mix between amusing and terrifying to look at, but luckily easy to fix. Me focusing on animation also meant I wasn't able to spend as much time texturing, lighting, and populating, etc, so those tasks got delegated in a new workflow. 

CONTENT WITH HOURS

• Cleaning Mocap (5 hours)
• Editing/Checking Animations in Mobu (4 hours)
• Texturing, Meetings, Teaching Perforce/New Workflows ( 3 hour) 

WORKFLOW EXAMPLES

POSITIVE OUTCOMES

• 5-6 new animations (especially death)  
• More help populating levels 

NEGATIVE OUTCOMES

• Time doesn't move slower
• Our low poly doesn't seem to work well until the room is heavily populated, especially without certain effects we'll need to get rid of 

POST MORTEM

So this is officially the largest team I've worked on. At first, I thought it would mean we'd get 3x the amount of work done, but in retrospect I'd say we got about as much done as we did last quarter. Of course, this is because of the 2ish weeks of planning and redesigning and familiarizing we did at the beginning, and I'm pretty confident that if we had more time our team would only accelerate in development. One of the big things from this quarter I think was my position as art lead. 

 I've been in charge of "aesthetic" or general art direction before, but never an actual lead over such a large group of people. I'm used to just buckling down on making assets and experimenting and getting new things in the game when I work on a project. To do this I had to make a bit of a change and split my focus between that and documentation, assigning tasks, etc. At first, I was a bit disappointed that I couldn't spend as much time just making things. However, I think I learned a lot, and I'm really glad I got the opportunity to do this. I got experience designing workflows, managing people, and communicating changes that I probably wouldn't have sought out otherwise. 

Art direction was another notable thing. Switching to low-poly and flat shading was the biggest aesthetic change. Low poly is something I'm very familiar with, and while there are certain consistent problems with our models (lack of variation, etc), I can link those to poor communication, and otherwise know where to make changes. Flat shading, on the other hand, was completely new. I thought it would be faster and easier, but making the game look interesting through mostly solid colors was, and still is,  a surprise challenge. Surface variation, more objects in general, and perhaps personalized lighting shaders are all things I think would help. This is definitely something I want to grab by the horns now. I've seen it work in other games, I've learned some pitfalls to avoid and best practices during this project, and I know this is something we can do. 

FOUR THINGS THAT WENT RIGHT:

1. I learned a lot about managing people and being more assertive when I delegate tasks, as well as about version control

2. In the modeling phase I learned a lot about tricks you can do with model normals and edgeflow or primitives to build off of that make triangular low poly work 

3. Populating levels with 70-80 rails and other furniture per scene was a time sink we maybe should have avoided but also taught me a lot about speed and shortcuts in unity 

4. Also learned after making tons of gradient maps manually that Shaders are incredibly valuable, and in development should maybe be considered first before you start trying to do something in a more manual way 

THREE THINGS THAT WENT WRONG:

1. The beginning of the quarter was very slow, and rapid prototyping is invaluable

2. Solid coloration doesn't work well unless you have interesting surface variation (so maybe in outdoor scenes with more organic models) or tons of content. I kind of regret going after it instead of sticking with painting. 

3. Lighting fell by the wayside until later on, and it would have been nice to maybe dedicate somebody specifically to lighting and have that be their one thing. 

NEXT TASKS

Polish animations and furniture

TOTAL HOURS LOGGED THIS WEEK: 12 hours

Jimmy Swanick | Wake up Wake up Wake up Wake up Wake up Wake up Wake up Week 9

WEEKLY NARRATIVE

After attempting a few means of implementing Volumetric Lighting on my own I returned to the internet to try some open source packages. I found two that seemed up tot he task:

https://github.com/Unity-Technologies/VolumetricLighting - this is apparently a package of some of the volumetric light effects from unity's Unity 5 Demo "Adam".  It's a little easier to implement but dependent on the type of Renderer and GPU you're using. 
https://github.com/SlightlyMad/VolumetricLights - and this was produced by a guy named SlightlyMad, and is a little more complicated and limited, but appeared (at first) to be more cross-platform friendly.

I was able to get both working in their own demo scenes & projects, but neither to work in the REMemberance unity project. 

It took a lot of tweaking and experimenting with inputs and settings to get the lights in the first package to be visibly volumetric at all, but I got it working. Unfortunately that was only after a lot of hopeless debugging that ended up leading me to what seemed to be a bug in Unity's build settings, in which metal support is turned on when the associated checkbox is turned off. 

Anyways, Here's the result:

It's definitely not what I was hoping for, but after spying the code behind this effect in both of the open source implementations I found, I'm thinking it's probably not the best idea to spend more time tweaking this. If it turns out that this doesn't hurt performance too much I think it will end up looking this way in game. 

CONTENT WITH HOURS

• 6 hrs Volumetric Lighting

WORKFLOW EXAMPLES

See above?

POSITIVE OUTCOMES

• Finally able to visualize enemy's vision area.

NEGATIVE OUTCOMES

• I'm still not satisfied with the appearance of this volumetric spotlight but for time's sake, stuck with it.
• I wasn't able to dedicate as much time as I'd have liked to this. 

NEXT TASKS

Rem is still in need of a visual effect for dashing. I'd like to plan more, but time isn't looking like that will be possible. 

TOTAL HOURS LOGGED THIS WEEK: 6 hours

POST MORTEM

Remembrance has been an interesting project, and I find it hard to believe it's only been about 22 weeks of development. The variety of work i've done for this project is astounding. I managed to touch almost every aspect of game development during this project's lifespan. I've rigged, animated, textured and modeled. I've learned a ton about post processing, Occlusion Culling, Light Baking, Bread Baking, NavAgents, Mesh Instancing, Ray&Sphere Casting, Audio Mapping, Particle Systems, Trail Renderers, and so, so, so, so, so much about shaders.  

I couldn't be more glad about how much I've been able to learn on this project - but it wasn't all technical skills. Managing a team of twenty students is pretty difficult, and even more so when all of them want to influence the design of the game, and the team's trajectory. Throughout the process we each were constantly describing different understandings about our plans. We couldn't all attend every meeting, so decisions were constantly being made and unmade with everyone being notified. This is somewhat inevitable, and is mitigated by a smaller team of decision makers, but for what felt like the longer part of these two terms we all were excited about the potential this game had. We even spent the first two-three weeks of this second term entirely in a concepting phase. (This ended up feeling like a mistake, especially when most of our ideas never made it into the game.)

We had very big plans, and in the second phase, when the size of our development team doubles, we felt encouraged to make those plans even bigger. We would continually say "We have six modelers, and eight programmers! We can get all this done."  - but alas, not a one of us was already proficient in any of the skills we needed to do it. And even worse than that, a time of this size is nearly impossible to organize. 

We could have survived the added organizational stress, though, but the design decisions we made ended up leading us to try to improve the game by adding too many abilities and new mechanics, and too much content. Though at the time and during our discussions expanding the player's toolset to deal with evasion situations in the game seemed like the smartest idea, in the end we ended up spending far too much time scraping by to develop the most basic versions of these abilities on schedule, and thereby ran out of time to polish any of them to a point that felt good. 

Throughout the project's lifetime, our playtesting feedback constantly resulted in players complaining about the character controller, about the camera, about jerky movement, and about a lack of clarity about the game's mechanics. And we all had great ideas to fix these things - but among a denser cloud of concerns we were overcommitted to developing more content and abilities; those problems were never solved, despite us having plenty of good ideas about it.

That said, I think the primary reason for that was that the game's original mechanical concepts were weak, and very poorly defined. We ended up discarding them early, and spent the rest of our time trying to improve an idea from every angle at once that had become confused, and mostly lost. 

This isn't something that can be avoided very easily at all, and even if we had realized this early (we had) we wouldn't have been quite free to turn back and work on a different game. 

No matter the end result though, learning any skill at all - especially project management, documentation, team communication, or learning anything technical at all, is inevitably a process of trial and error, and experience. Working on REMemberance, I think all of us acquired a tremendous amount of experience that we might have had from only on the best internships. 

PS - though I wish I could have spent more time in the last several weeks of this project on visual effects, there were several weeks during which i managed to do a whole lot. After this project lead me to begin with graphics (In order make the Xray portal effect), I ended up going to spend hundreds of hours of free time teaching myself about shaders, rendering, particle effects, and procedural animation. I ended up steering all of my projects in that direction, teaching myself droves of linear algebra lessons, and going through dozens of hours of animation and rigging tutorials. My personal projects look cool. I feel cool. I am so glad I started learning about graphics and effects because of that Xray portal, and It's certainly the career path i now intend. 

I hereby rate REMemberance 8.6/10.

Matthew Wagar | Week 9 : Website Updates

WEEKLY NARRATIVE

So instead of designing floorplans this week because we have a lock on level design, I decided to fix up the website a bit. Now on the home page it displays our trailer so everyone can see our game in action. Also on the documentation page I updated it with all of our scrums and sell presentations for winter term. 

I was very busy with other classes this week and other final projects, so I was a little too swamped to work on the game itself, but I at least contributed something!

CONTENT WITH HOURS

• Website updates (2 hours)
• Post Mortem / PPJ (1 hour)

WORKFLOW EXAMPLES

Updated scrum page

POSITIVE OUTCOMES

• A better documented website, plus trailer

NEGATIVE OUTCOMES

• There were some VFX that I wanted to test out on the game this week, but I never got the chance to work on it

POST MORTEM

Looking back on this term I started off putting in 20 hour work weeks and have slowly put less and less work as time went on. The reason for this is because at the beginning it was a big undertaking to implement a blog on the website and learning the Google Blogger API. This job included implementing a tagging system, a way of displaying pages by id, and lazy loading images and posts as you scroll down. 

Not to mention in terms of level design we put way too much time into thinking of ways to innovate our game without actually doing it. We would have 5 hour meetings practically on a daily basis arguing over what should or shouldn't be in the game. In the end once we finally locked down what mechanics we want, the direction we want, and the general layout of the hospital, everything became a lot easier.

In the latter half of the term I only had to put in 5-10 hour work weeks because I only had to make level designs and coordinate with the modelers and programmers to implement them in the game.

THREE THINGS THAT WENT RIGHT:

1. The blog! It works! I've never done anything like this before, so implementing a blog felt like a nice personal achievement. It's not the prettiest thing, but it works!

2. Level designs with verticality and diagonals. Switching from our tile set we had last term opened the doors to a lot more intricate and complex levels. Very fun and educational to play around with. Definitely learn the do's and don't's of level design and how to approach future projects scope wise.

3. Learned how to speak of level design more critically. At first its fun to make big random spaces or rectilinear spaces without a clear challenge or thematic meaning. Design, in my opinion, is very underrated in terms of work load. It's not about getting functionality to work or create an asset beautifully, but its about communicating an idea as intuitively as possible. 

THREE THINGS THAT WENT WRONG:

1. Accidentally did Waterfall development instead of Agile. As a designer it feels intuitive to plan out the big picture of a game so that every area and idea can be linked together thematically. However, in practice as we learned, that takes way too much time and blocks everyone else from developing. Instead I think it's better to prototype as soon as possible, get builds out as soon as possible, and build off from the base you have. It's important to be as iterative and modular as possible so that no development of the game can break once one mechanic isn't working.

2. Very hard to stay in scope. I ended up creating a level design last week that was one week too late to be modeled and developed into an actual level. As designers it's easy to think of out of scope mechanics and challenges and level designs, but it's hard to cut corners tastefully and effectively.

3. This term outside of school I took it upon myself to learn how shaders and VFX work in Unity and OpenGL and really wanted to implement something of my own into the game, but I just never got around to it. The workflow of going into Perforce and changing things felt kind of daunting, and I was also just busy with other classes. I would still really like to mess around with it in the next week, though!

NEXT TASKS

Next week I plan on being involved in whatever the team needs me to be. For example I might be implementing assets in the scene, or throwing in VFX, or messing around with lighting. 

TOTAL HOURS LOGGED THIS WEEK: 3 hours

Zak Olyarnik | Week 9: RIP My Sleep Schedule

WEEKLY NARRATIVE

I don't have anything special to report for this week.  The Thursday night meeting was more of a recap than any new task assignment, as was to be expected this close to the end.  All my hours this week went into playing the game and getting screencapture in order to improve the quality of gifs in our sell presentation.  There were a lot of other cosmetic changes to it as well, which I worked with Mike on.  Lastly, I went back over the playtest survey one last time, now armed with the grading feedback from the versions we submitted earlier in the quarter.

CONTENT WITH HOURS

• Meetings (2 hours)
• Sell presentation rework (8 hours)
• Scrum, including analyzing playtest data (3 hours)

WORKFLOW EXAMPLES

POSITIVE OUTCOMES

• Nearly there...

NEGATIVE OUTCOMES

• The combination of Photoshop, Unity, OBS, and Google slides is enough to crash even the mightiest of computers

POSTMORTEM

I've always been a natural leader, and it bothered me immensely when I wasn't selected for that position last quarter.  But what I learned from the experience was that sometimes it's better to let someone else be the face and make the decisions while you worry about the logistics.  I was happy to slip into a similar position as scrum-master this term, allowing me to still keep tabs on our deadlines and progress along the way, with the bonus of getting to compile all the presentations, which is something I really enjoy doing.  I took on way too much with SPARK, and to some extent I needed to for it to be successful, but with Remembrance the rest of the team was large and skilled enough that delegation was not only possible but highly successful.

Now, did the fact that I came into this project halfway through and found a messy codebase and an even worse Unity project hierarchy have any impact on my decision to gravitate further and further from actual programming as the quarter went on?  Well, that's kind of a leading question, isn't it?  But did I give anything less than 100% on my scrums, my work on the playtest survey and data analysis, the sell presentation, and the creation, editing and proofreading of the GDD and all of our other major workflow documents?  I should hope that the quality of those things answers that question for me as well.  And I feel like that's the best summary of the quarter as I can give: I maybe could and should have been more involved with things like the actual game build, but I feel I was highly successful with the parts I took on directly.

What went right:

1) I became a team player with this project.  I knew what to expect from a few people from last quarter, and that helped me feel more comfortable delegating more to the strong members while I felt out the rest of the team.  Corwin was a phenomenal Programming Lead and programming was always able to meet their goals and deadlines each week without anyone having to kill themselves.

2) From reading all the PPJs every week, it sounds like everyone got to work on pretty much what they wanted to this time around.  Again, the big team allowed that, as well as covering for a lot of weaknesses.

3) Believe it or not, I feel like I learned a lot about game design from this course, both in the classroom and just working with the team.  Now, this was not my first GMAP class at Drexel, not by a long shot, but before it had always been about pleasing the professor and catering to the very specific whatever they were looking for.  This time, we got the hands-off freedom to be creative, balanced with suggestions for improvement and general tips for making games better, even when they didn't apply directly to this game.

What went wrong:

1) The design -> programming workflow.  I've already written a lot about this, probably more harsh than I should have been...but it really bothered me when the design team kept throwing in new things A) without asking programming if they were even possible, and B) when they contradicted features and other things already in the game.

2) Making builds at 6am the day they're due, after pulling all-nighters to even get to that point, just doesn't work.  Half of the team liked to leave their work until the last possible minute, even with multiple reminders, encouragement, and "public shaming" over the chat.  We developed a better solution for this by mandating a frozen build (bugfixes only allowed afterwards) on Saturday night instead, but A) that meant that this build was always very art-sparse, and B) the fact that it took the hit to our grades for this to happen, late in the quarter, is discouraging in-and-of itself.

3) Towards the end, it seemed like programming was going in circles.  Every new thing seemed to break something else, something that had already been fixed, and it seemed from my [albeit outside] perspective that the hotfixes were getting close in number to the amount of "real" code.  I'm truly worried about the integrity of the game trying to move forward past this.

4) I just have to add: I think moving from Git to Perforce was a huge mistake.  We lost about two weeks to it at the beginning, just trying to get everyone connected and able to use it, and it's caused nothing but problems ever since.  Inadvertently locked files, or ones that were forgotten to be included in a revision, or it just not playing well with things like Unity's prefab system have caused us more problems than...wait, why did we even want this in the first place?

Lessons learned:

1) Put a programmer on the design team.

2) Set deadlines much earlier than necessary, expect for them to not be met anyway, and never undervalue QA and testing.

3) Do what you like and are good at, and let other people do what they like and are good at, and everyone will be happier.

NEXT TASKS

The list of final deliverables is kind-of heavy for me, considering how I just described my position on this team.  I've had my hand in the sell, the GDD, the Gantt, the playtest data, the other workflow and archive documents...and they all need to be cleaned up before final submission.

TOTAL HOURS LOGGED THIS WEEK: 13 hours

Daniel Shalala | PPJ Week 9 | Close to the End

WEEKLY NARRATIVE

This week I had no real work that I needed to accomplish, with the institution of the story and memento objects I was left to work on other homework that was required and neglected for a while. This being said I did have one final thing to focus on: playtests.

Tasks this week

-Meeting (2 hours)

-Playtests (30 minutes)

POSTMORTEM

   Overall I can say several things about this project, chief among them is the fact that I enjoyed my time with this team and that I have learned a great deal about myself, game design and how to work in groups. Overall, my level of work increased from last quarter, I understood more and contributed more with the group. On this note I liked the direction that the game went during this quarter. I think we had an excellent idea for this game, but the scope was ambitiously large. The biggest complaint I had was with the conflicting ideas that emerged during this time, it seemed like the group had several different ideas about how it wanted to proceed.

   I'm glad that I could have been part of the story group. With the additions that we added I believe that we made Rem a more interesting and approachable character, my only regret is that I feel like our approach to implementation and execution was off, but if we ever work on the game in the future then we have a way to go.

  I think the biggest issue that we faced as a group that kept us from meeting our end goal was communication, or lack thereof, something that I myself am guilty of. This became an even bigger issue when it came time to meet deadlines, again something that I had issues with also.
   

POSITIVE OUTCOMES

• I got my playtests completed

NEGATIVE OUTCOMES

• I didn't sleep this week (But then again it has less to do with this class)

NEXT TASKS

• Whatever everyone needs me to do

TOTAL HOURS LOGGED THIS WEEK: Estimated 2.5 hours

Joe Lipinski | Week 8: Post Mortem

Joe Lipinski |  Week 8: Post Mortem

WEEKLY NARRATIVE

This week I tackled making sure that all screenie's had the proper gifs on their faces and then worked on fixing a bug with the xray mechanic. Previously the xray would consume stamina even if the portal was not spawned. After doing some null checking and extraneous coding the problem was fixed.

POST MORTEM:

3 Good Things:
I learned how to use perforce so that's some cool stuff. Not sure if I want to use it in the future but at least I got my feet wet.

Our coding team was organized under grand master Corwin which meant that task delegation and production responsibility was actually a thing.

This project covered a lot of coding areas that I was unfamiliar with so now I have a lot of reference material.

3 Bad Things:
I was only a coder so I feel like I did a good job in that department but I also wanted to get more involved with design.

Most of my code was functional and non-juicy. I would rather have added more juice.

It took a while to get settled with perforce and understand how it should be done for mac.

CONTENT WITH HOURS

• All gifs (1 hour)
• Xray (3 hours)
• Play testing (1 hour)

WORKFLOW AND PLAY TEST SCREENSHOTS

POSITIVE OUTCOMES

• Tasks were completed so its all good.

NEGATIVE OUTCOMES

• Xray took wayyyyy too long to fix.

NEXT TASKS

Probably tackling some of the bugs that were generated from this playtest.

TOTAL HOURS LOGGED THIS WEEK: 5 hours

Matthew Napolillo | Week 9: The Beginning of the End

Matthew Napolillo | Week 9: The Beginning of the End

WEEKLY NARRATIVE

The two major priorities this week were getting the final two designs in the game: the PreHero Challenge, and the Library Hero Room (the one that contains the Wall Memento). Most of my work this week was getting those done in time for Kane to do the models. 

The rest of the week was just the usual team meeting, and making a brief change to the hallways using Pro Builder where you could see through a crack in the mesh.

CONTENT WITH HOURS

• Level Layout Design (4 hours)
• Team Meeting (2 hours)
• Fixing Hallway Issue (.5 hour)

WORKFLOW EXAMPLES

Library Pre-Hero Room Challenge Design

Library Hero Room Design

POSITIVE OUTCOMES

• Created final designs
• Took care of an issue with a hallway mesh
• Got to mess around with ProBuilder

NEGATIVE OUTCOMES

• Didn't have time to help out with Art Dept decorating/texturing scenes

POSTMORTEM

Well we're finally here. It's the end of the quarter, and this has been one hell of a quarter. At the beginning of the quarter I was full of enthusiasm to be working on this project. I was so eager to learn and to build up this game into something to be proud of. Though my original intent was to focus on the programming side, I ended up being put on the design team because of my experience on SPARK. Though I thought I would be able to go back and forth, I ended up diving head first into design. The first three weeks were a whirlwind of meetings, new concepts, and trying to build out this game into a new and interesting experience. There were so many ideas being discussed and debated. I was a bit stubborn early on, and realized that was one of the things I needed to work on. I watched a ton of GDC talks, and learned about important design pillars. Every week things would change, and I'd learn more. However, while all these decisions were being formed and thrown around, we weren't doing the best job at communicating all the new changes to other departments on the team (specifically the programming team). 

About halfway through the term, that lack of communication came to a head. This was probably one of the most important things I learned over the course of this term; when working on a team this large, make sure the people implementing the new changes are kept as aware as possible (and in the room hopefully) about those discussions and changes. It was rough dealing with the realization that there had been this glaring problem the whole time. Another issue I realized a few weeks in is that we really needed a Design Lead who'd be the final say on whether a change happened or not. Someone to vet Design ideas and make the final call so that debates wouldn't go on for too long. Though I don't think I was ready for that position at the beginning of the term, I felt comfortable taking charge as the Design Lead at around the same time that the disconnect between departments became apparent.

I feel like I grew a lot working on this project. No matter how the project turns out, I'm content with how much I've learned as a game designer.

NEXT TASKS

Help out the Art Dept on decoration and texturing. 

TOTAL HOURS LOGGED THIS WEEK: 6.5 hours