rovane14-blog

[rovane14-blog]

Team Postmortem

Team Post Mortem

Nicholas, Ajay, Jon, Jacob, Ian, Jade, Logan, Nive, Mo, Tommy, and Jibril

           The team is very proud of what we were able to accomplish during this month. We were able to deliver a project that captured the idea and concept of the game we set out to make. The game has 28 mazes, 4 different obstacles, 5 themed areas, and custom UI and audio. The build is also playable from start to finish. This has been an overall positive experience for the team, and we are proud of what we made.

           There are a few things during this production that helped to make this game a success. One of those was the strong communication the team. The team tried to meet regularly to make sure everyone was on the same page and the product was on track. Even when the team did make mistakes, we quickly organized meetings in person to talk through how we could fix things. Without this strong communication, this project wouldn’t have come together nearly as well as it did. It also helped us to avoid losing progress through things like people pushing when someone else was working in the same scene. We made sure to communicate when someone was working on something to avoid these types of errors.

           Another thing the team did well during this project was staying on top of task completion. This can clearly be seen in our team burndown below. The most the team fell behind was on milestone 3 when we were 8 hours of scheduled tasks behind. Since we were able to stay so closely on schedule, making up those 8 hours of task was something the team was able to accomplish during the final milestone. The ability for every member of this team to accomplish the tasks they said they were going to accomplish greatly helped us in building what we did. If even one member of the team stopped doing their tasks, that would’ve shown in the final build. There would have been areas with large content gaps compared to the other ones.

           The third thing that the team did well during this project was our adaptability and willingness to change. Everyone on the team was willing to adjust their schedules if people pointed out areas where the game could be improved. This can be seen in the changes from the original schedule to the one we have now. The original plan didn’t have any art planned for the basic hub, no ceilings or lighting done for the hub, and no UI art. These things were pointed out as potential weaknesses to our builds polish and presentation, so people were willing to shift their scheduled tasks around and even take on extra tasks. The final scope of our project turned out to be 25 hours over our scheduled capacity because people were either working ahead of schedule or they were willing to put in some extra time to make the project better.

           There were also a few things about our process that didn’t go so well. These are things we would like to learn from so that we don’t make these same mistakes again in the future. One of the biggest problems we faced was revealed at the end of the first milestone. We didn’t plan out our entire schedule and instead focused on just planning that first milestone. While it seemed like this would work at that point, during our first milestone review it became clear that not planning put us in a tough spot. We had no clear idea where our project was going, and it created some misunderstandings about what people should be prioritizing. This is demonstrated in the burndown chart above where the line dips to zero then jump up to 358. If we were to make another game, determining our schedule before work starts is a must. It makes it easier for everyone to be on the same page and it helps to clearly demonstrate the teams end goal. If the team notices glaring problems or holes in their schedule, they can figure out how to fix it in their future planned milestones rather than trying to put out fires every milestone as they arise.

           Another process that we didn’t do this time but would have been helpful was setting earlier deadlines for content like art and levels. Right before every milestone, there was content being pushed and incorporated at the last moment, which made it hard to thoroughly test. This can be seen in the chart when the lines always start to converge right before the milestone dates. Going forward, it would probably be beneficial to set the deadlines earlier so that everything can be incorporated and tested beforehand. This also helps prevent situations where people finish a task, but they don’t see it in the build. That’s a situation no one wants to be in. This type of thing can hurt team morale when people put effort into something, but they then find out it didn’t make it into the build. I don’t think we ran into this situation during this project, but we did have some close calls with our deadlines. Unexpected bugs had our developers skipping out on some of their lunches to try and fix. It would be nice to have them do that again.

           Our testing plan is another process that didn’t go as well as it could. As mentioned above, the implementation of assets generally had us running close to our deadlines. So, when we ran our tests, they had to be rushed. This sometimes led us to missing some things. For example, for Milestone 3, we thought we had a 97% pass rate but unfortunately it was less than that. We rushed the process and marked things as pass that shouldn’t have been. This is clearly a problem because it makes our whole testing plan look suspect when things don’t work that should. Our testing plan was never at 100% expect for the final milestone. This was sometimes due to tasks not being finished on times, but other times it was due to poor planning. In the future, it would be beneficial to create more time for testing to occur so that it isn’t being rushed. It would be nice to have the testing plan at 100% for each milestone if possible.

           One final thing that would’ve been helpful was to spend less time brainstorming and planning in the beginning. It took us longer to decide on a game than we’d initially hoped. Sometimes this is unavoidable, especially with 11 people debating and pitching design ideas. Once we picked a concept, we spent another couple of hours trying to determine how best to tackle this. In the end, we spent a large part of our allotted capacity planning. If possible, it would be nice to reduce this amount of meeting time, so more time can be spent building.

              In the end, we view this project as a success. We are proud of the time and effort we put into it. It’s a functioning product that looks and sounds good, and best of all, it’s fun to play. There always more we could add to it to make it better, but within the month we had, we were able to make something that were happy with. Even though it didn’t run perfectly, the positive things about our process were able to outweigh the negative ones, which helped us to create what we did.

[rovane14-blog]

Individual Project Post Mortem

The original goals for the game were to create a number of levels but commit a majority of our man ours to focus on the quality of the levels and the mechanics of each level. This vision had to be re-envisioned due to the requirements of our assignment, in the end, the plan was changed, and the number of levels was increased. After this pivotal  design change to our plan we began to be much more deadline orientated as the number of levels increased the amount of maze that needed to meet the teams goals,  this shifted the aim of our production as a team, as we focused more on the  number of mazes and combinations instead of very detailed mazes but a smaller  number.

 What was the original project success criterion?

The original projects success criteria were to have all the mazes designed and implemented into unity by the end of the month.

How did the project end?

The project ended with the team meeting the goals that were set, which was having 100% content implementation and art implementation.

What went right?

Throughout the process, many things went right during the process, but I believe that was one of the best things that went well for our group was the amount of communication that our group shared throughout the process. That communication allowed us to be adaptable as a team to best fit the needs of our project. As we received our feedback the good communication made the adjustments that needed to be made in order to meet the new goals that we set for our team. The communication included the use of discord, individual text messages and team meetings, this lead to us all being able to collaborate more efficiently through the limited time that was available from our various team member due to other time obligations. I believe that  this became one of the key elements that lead to our successes as a team

 What worked well?

In terms of what worked well, when looking back at the project something that I think worked well was the division of labor that the team initially planned. The plan was to have dedicated teams of one artist and one designer to properly each theme of each maze. This worked well until the team was encouraged to increase scoop which took away a lot of the quality time that could be spent on each level, we then had to move from this efficient system.

What went wrong?

Our main issue for our team came in the first milestone as we did not plan correctly initially to meet the requirements for our project. This lack of pre-planning leads to issues once we had to change elements of our initial plan to better fit the new scope of the project. The initial issue came from a miscommunication when receiving the instruction during our course. From this miscommunication, our team had to leverage our available time during the first week to rework our initial plans in order to match the current scope. This was Definity a test on our ability to adaptability as a group but it gave us the opportunity to rise to the challenge and challenge ourselves as a team.

[rovane14-blog]

Individual Postmortem

Project Overview:

Original Project Goals  and Objectives

The original goals of our project were to produce a game that would be fun and appealing to a wide age demographic and to produce a  prototype to help to demonstrate the core feature and mechanics of the game.  The game that we decided on was an adventure platformer where we wanted the focus to be on the level exploration and how the players would traverse this level. The team decided that the main player character would be a hamster that is in his ball. The character was chosen to help us appeal to appeal the fictional person that product is targeting. The product objectives were to successfully put together a prototype that allowed us to demonstrate the elements of the game that we believed would be the selling points of our game such as interesting movement, puzzle solving, environmental interaction and immersion.

 Original Project Success  Criterion

The success criterion for the project was producing a  proper physical prototype to represent our vision of the games core features and to produce a stable digital prototype of the game.  

 How did the project end?

The project ended with us accomplishing both of our goals.  The physical prototype was successful as it shows the intended puzzle elements of the game and the intended player interactions intended for the game.

 Key Accomplishments:

What went right?

The things that went right were the communication on roles within the team as we found ourselves communication properly and staying on the same page in terms of what was going on with the project. We also successfully took our original ideas and made iterations that further helped us develop the mechanics and overall presentation of the prototype.  

What worked well?

A major thing that worked well with our project was assigning roles early to help us properly organize the work that needed to be accomplished in the project.

Project highlights

A major Highlight during the project was an impromptu iteration session during class. During this time the group was given limited time to make improvements to the digital prototype. When the task was given the team rose to the occasion as we came together to properly task and distributed the work properly so that the task was executable in the timeframe that we had.  We also incorporated feedback from the instructor and did our best to take his advised improvements and accomplishing them within the prototype. This was a great success for the team and showed us how much little changes could help better to convey the proper message to the audience that we want to convey with our prototype.

 Key Problem Areas:

What went wrong?

The one thing that did go wrong was the adjustments made to the movement prior to our final presentation. The initial movement that we had used was thought to be too easy for the player so to increase the movement’s difficulty slightly we found the movement to feel less intuitive and too hard to control.

What specific processes caused problems?

The biggest process that caused an issue for our team was not something is uncommon which one and that was the scheduling of time for group meeting and this was largely due to the time that we all have committed to our capstones, so finding a meeting time was somewhat difficult.

 Post Project Tasks/Future Considerations

Ongoing development and maintenance considerations

The team has already come together and decided that we wish us to continue the project in the future which is something that everyone came together and agreed upon. We have already an idea of the things that we want to continue to improve and other things that we wish to add in the future iteration of the game.

 Is there anything still outstanding or that will take time to realize?

The biggest outstanding thing to be taken care of is the creation of the next level in the game possible but the entire team is responsible for the competition of the level.

[rovane14-blog]

Team Postmortem

           Looking back on the project now, the team is very proud of what they created. From our initial design, we were able to incorporate most of the mechanics and puzzles that we wanted to into the final build. The game did evolve throughout production, but we were able to keep the base concept the same. There were issues that came up as we made the game that required the team to come together and find creative solutions to these problems. We are happy that we were able to do this without having to cut too many of our ideas.

           One of the main things we are proud of is Simon, our player character. His final look and feel are what the team was hoping for when the idea was first developed. We are also proud of the level we were able to create. Not only did we incorporate all the puzzle related objects, but we created many additional objects that helped to bring the house to life. The world was also brought to life with sounds. These sounds help guide the player with feedback and they also help to bring life to the world.

           While we are proud of what was made, we do wish that we could’ve incorporated more intricate puzzle designs. So rather than adding multiple different simple ones, we could’ve focused on one puzzle for each room that had several specific steps to trigger. This is an idea we can take and use if we make additional levels for this game. The stage we made this month works as a nice introduction level since each puzzle is simple.

           As for how the team worked together, there were many positives processes that we used. One of the most helpful things about our team is the diverse set of skills we have. We have artists, developers, designers, and audio skills in our team. This team make up allowed us to capture the look and feel of the game we were trying to make in a short period of time. The team also works well together. We have been in a class together for half a year and we have worked on multiple team projects together which helped make teamwork more comfortable. The team is used to each other which helped to facilitate communication. We didn’t always agree on everything, but the team was able to work towards compromises or ideas that would work within the scope we had.

           The artists on the team used a google document sheet to help track all of the required art assets for the projects. This helped to make sure that two people weren’t making the same object and therefore wasting time. Another tool that the team used that was helpful was Github. This made adding assets to the scene easier for multiple people. Unity has a collaboration tool, but it only allows three people to work on the project at once. Github allows all of us to push and pull parts of the project into the build.

           While there were many positives to how the team worked together, there were some issues that arose. One of those was bottlenecks. These came about because not everyone on the team is used to working within Unity. So only a few people could incorporate objects into the scene, which made some things a little tricky. Even though Github is helpful, only one person can work in the scene at a time. This made it difficult when multiple people wanted to make changes within the scene at the same time. There are also some people on the team that weren’t used to using Github either.

           For future projects, we would make some changes to make this process better. For starters, we would make sure everyone on the team was familiar with pushing and pulling assets off Github. This will help make sure everyone’s assets make their way into the build. We would also make sure everyone is familiar with Unity. That would also help reduce the occurrence of bottlenecks and the reliance on a select few to make changes in the scene.

           One thing that we didn’t officially do this time around that could’ve been helpful was to make someone the producer of the project. This person would’ve been responsible for assigning and tracking all the various tasks required for the project. We were able to get things done and incorporated into the build but having someone in this role would’ve made the process much smoother. There were instances when stuff wasn’t incorporated into the scene because someone didn’t know they were supposed to do it. A producer would help clear up miss communications like this.

           Another difficulty we ran into was scheduling. It’s difficult when the team can’t always meet in the same space. We tried doing things individual and using discord for communication, but that didn’t work very well. After that, we always tried to meet in person for at least part of the work time. Individual assets can be worked on separately, but when it came to building the scene, having the team together often made things easier. If problems arose, the team was there to help fix issues.

           We also learned that incorporating wWise into the project for the audio is something we should’ve done beforehand. We made it work but incorporating the sounds into the build was more difficult than it could’ve been with the proper foresight. Next time we would set up this incorporation first to help make this process smoother.

           All in all, the team is proud of the final product we were able to create in this short amount of time. We were able to create a game that captured the intended look and feel of what we wanted. While this initial level is simple, it does showcase the types of contraptions and reactions we wanted to make to get the hamster out of the rooms. This is a solid starting point for a project that could be turned into something much bigger. We are proud of ourselves for being able to build this within a limited amount of time while also balancing everyone’s individual schedules. The team was also able to make it through the experience with their team relationships intact.    

[rovane14-blog]

MEX Journal

The various things that I learned in MEX helped me to better understand the entire testing process and the methods that are applied to them. The testing process helped to apply my understanding of validity that was learned in earlier months and expanded upon this month. Throughout the course, we were responsible for constructing and conducting our own tests, this experience in particular I enjoyed. I say this because it allowed me to have hands-on experience and apply the knowledge that I've learned over the past few months about design, conducting and analyzing testing data.

This co-insides with my overall GDMS track over at the Full Sail User Experience lab. The information gained and the tests we ran weren’t the same as in the lab and I welcome this information because I felt like it increased my overall knowledge base. The game we chose for our test was a mobile game called Uno with friends and the experience also gave me a chance to analyze the process of game testing from a new perspective. The group was comprised of members that I had never worked with before and I enjoyed the chance to work with new people and try out a new combination of styles and ideas.

[rovane14-blog]

Reflective Essay

The area of research that I am focusing on is the effect of gaming and game design on human learning and motivation. The importance to the industry that this research holds is that if we can identify how game design effects on people that can be used to motivate people and can be used to aid in human learning. The research that I have done during month 4 was focused on gathering more information on how games can influence learning and how games can be used to aid in the learning process. The goals of future research are to see how the motivation factors from game design can be utilized to aid in the learning process. The topic connects to my capstone goals in the UX research lab by allowing me to study not just who plays what games, but more importantly why they play and what effects their decision to continue playing. My career goal is to be a game designer and I believe that if I can understand what motivates people and how they learn, then I use this knowledge so I can design games motivate people to learn more.

[rovane14-blog]

"People say I make strange choices, but they're not strange for me. My sickness is that I'm fascinated by ... what's underneath the surface, by the worlds inside people." - Johnny Depp

Famous INFPs - Individual Differences Research Labs. (n.d.). Retrieved from https://www.idrlabs.com/infp.php

This quote sticks with me because during this course I was encouraged to explore my mind and given the opportunity to execute my own project plan. During this process I found myself finding my unique style of management and personality type. The personality test, in particular, helped me to solidify my own understanding of who I am and identify with people of similar personality type. It was filled with writers and philosophers that I spent a majority of my life idolizing and studying. Seeing the reflection of those the same personality as me inspired me to continue on this journey and path because now that I see the greats that have come before me so I see that I am not on my own in the way I think and feel. This course helped to fuel my personal confidence in my leadership ability and personality strengths.    

[rovane14-blog]

RTD Mastery Journal

As I started the Research and Team Dynamics course I was curious as to how it tied into my journey career and my overall mastery plan, but up until this point in the course nearing the end can I give you a clear answer. My answer came at different points throughout the course as I began to understand Dr. Kennedy’s purposes for various things in the course. I came to understand the research the research methodologies and practical applications. This came back up as I shadowed at the UX lab I saw how my undergraduate degree gave me a basic understand of the research field and how my career path in the video game industry could be more design and research focused instead of development. This clarity leads me to focus on getting into the UX track to explore my interest in research and how the track could help me achieve both of my career goals in the industry as a researcher and designer. The course helped me to find identify how much I how the research process interacts with the design world. I found my topic is tied to the class due to its based in design. A part of the course required us to form our groups and design and develop our own game games. This helped me to identify that design would be the focus of my topic and after shadowing, I looked into game design and user experience.

[rovane14-blog]

https://www.brainyquote.com/authors/brad_henry

This quote inspired me because of the experience I had during my first course Mastery. This class helped me to understand what was ahead of me and also excited me at the thought of the various possibilities of the future.

[rovane14-blog]

Tupac Shakur Quotes. (n.d.). BrainyQuote.com. Retrieved July 21, 2018, from BrainyQuote.com 

This quote reminds me that no matter how many dreams I have nothing will be accomplished if I only dream and never chase them. 

[rovane14-blog]

[rovane14-blog]

[rovane14-blog]

Feedly Screenshot

[rovane14-blog]

[rovane14-blog]

The day I graduate for me signified the completion of a goal to become the first in my family to graduate college. This day signified the completion of my track and field journey that I spent so many hours and years of my life on. This day signified the beginning of a new adventure in life that only time can unveil its true outcome....... 

[rovane14-blog]

The Vision

The vision that I have for my mastery journals are to help me clearly outline the goals I have put in place for myself to serve as self-motivation. I believe that visual aids help in motivating one’s self and I want to implement this theory along this journey. I draw from many art forms so I will be posting and reposting my various inspirations from various art forms such as video games, film and the world of music. The role I desire in the industry is one that is one in which I must have a great understanding of the various aspects of developing and designing a video game, the journals I hope reflect this. I see these journals also as a way to properly convey interests and display credits for any project that I have work on. I want those that view these journals to be able to see the progression throughout my master's program and career after. I hope to learn along this journey what it truly means to take a game from idea all the way through to completion. I am interested in the entire video game process and during my time here at full sail, I hope to gain the necessary knowledge to forge my way into the industry in a confident position. I also want to learn how I can become an efficient and positive producer because I believe in the team aspects of working and that if we can excel as a team then the quality of our art form increases. More often than not we never get a chance to properly convey our unique creative vision and I hope with this allow me to share my creative journey a and vision in a way that fulfills this essential need. I welcome you to share this vision and progress with anyone willing to accompany me on this journey.