srgamedesign-blog

[srgamedesign-blog]

Team Post mortem

Postmortem: Pirates of the Ice Coast

 Introduction to Game

 Pirates of the Ice Coast is an action RPG where you play as a walrus humanoid named Kaijaq, a pirate ship captain trying to make his way in a world full of other pirate animal races.  After learning of some powerful loot discovered by a rival faction, Kaijaq begins a quest to find the treasure for himself.  Will he obtain it to keep it out of the wrong hands?  Or will he use it to pursue his own nefarious agenda?

 This game features expansive levels totaling in fifty-nine maps. Melee combat, ranged blaster combat, and dodge rolling are the key player character mechanics used while trying to complete quests and explore the world.  The main antagonists presented to the player include hordes of penguin and polar bear pirates that have been pillaging and wreaking havoc in the towns and villages.  Completing main quests leads the player to new areas and, their main mode of transportation while in the overworld map, Kaijaq’s ship.

 Our project was created for our Asset Management course. As a team of six, we were to create a game of our own design.  The production lasted one month with four milestones to be met.  Three times throughout the production, we met with our instructor and went over the progress of the project at that point.

 What Went Right

 Engine:

           We used RPG Maker MV to develop and compile our project.  It is a fairly simplified and easy to understand program with plenty of tutorial available online.  With only one member focusing on the development side of the project, this played a major role in making constant builds available to the entire team throughout production was easy.

             The engine itself came with level editing features that already contained player collision, map height, item creation, skill creation, animation implementation, and quite a lot more.  Though this did make it harder to fine tune several features, it expedited the development process for someone with those with little experience with many game engines.

 Plugins:

           The Chrono Engine plugin made it possible for us to create an action RPG that did not use a turn-based combat system.  The battles instead to place in realtime and relied more on player reaction and strategy.  The player was able to used long range to their advantage when they had distance on enemies, pick up and throw bombs to effect multiple opponents, and stave off enemy attacks with melee knockbacks.

           YEP was another plugin that was used to track quests within the player’s quest journal for reference during gameplay. This would allow the player to see if the quest they were doing was part of the main storyline, and remind them of the general details for the quests.  YEP really helped out those that were making and fixing quests throughout the project by keeping them neat and easy to access.

Quests:

With the creation of the game we had a fun time with creating the quests. The quest were written in a timely fashion. They were then implemented in a quick fashion. We were able to continually grow are quests into more in depth and interesting stories. With the help of the YEP plugins we were also able to add a quest log that helped track the quests we made.

             The experience of creating these quests and implementing them was a great learning experience. Our writer learned how to implement the quests themselves and how to work with the engine. This was also a great way for our team to see and work with questlines. With these experiences we should be able to push our games forward.

 Maps:

           As our game was an RPG we wanted to have a fun and interesting world to explore. This was key to our game experience. The maps came out looking really good and playing really well. We had a few road bumps with them due to issues with one of the plugins, but ultimately the maps came out working well.

             It was an interesting experience creating the maps for the game. The engine has several tilesets that make map creation very easy. It also contains a simple event system to allow easy implementation. The creation of the maps ultimately led to our game feeling more life like and expansive. Especially when in conjunction with enemies and quests.

 What Went Wrong

 Team Investment in the Production Timeline:

With the development of the game one of the key issues we faced was lack of investment to the production timeline. This lack of investment led to all sorts of smaller issues inside the process for creating the game. It caused communication issues that confused and pushed our production behind schedule. It also led to work not fully being completed. The issue also caused our teamwork to drop.

             What we can learn from this issue is the importance of putting your all to any project. This is especially true if you dislike the project. Due to team members lack of investment we faced many issues. They could’ve been solved simply by us acting more professional. It is important when working in any team environment to work together in the continual goal of completing the project. We also must remember it’s a team effort and not a one man show.

 Art Implementation:

           Another problem we faced during development of the game was the lack of art implementation before each QA test deadline and the end of week presentation. This issue also resulted in a de-synchronization between our testing result from QA and the results showed within our end of week presentation, as more art was added late between the two. The contributing factors include artists not being available to communicate, minor complications after testing the artwork in engine, and art just not being completed in time to be passed along the pipeline for implementation. This dilemma was less prevalent within the end of the month and however still posed a legitimate concern for further discussion.

             The lesson that can be learned from this is that we need to better control our time. This means sticking to deadlines and knowing personal capacity. Doing everything last minute easily led to delays. This further added onto the appearance of less professionalism and inadequacy. In the future we all understand the need to better control our time and capacity.

 Lack of a Clear Pipeline:

 One of the things that went wrong was the lack of a clear pipeline. During our sprints every department finished their tasks independently, without taking into account the dependencies or the workflow of the whole team. This lead to many problems, one of which was having contradictory information on the slides. QA was done at the end of the sprint, so it gave the team no time to fix any issue. An ideal pipeline would have had 2 builds, one in the middle of the week and one at the end of the week. If we did QA at the middle of the week, and then worked on a final build addressing whatever issue QA found; we would have had a much stronger build to present.

 What we can learn from this is the importance of having a good pipeline, and the importance of being aware of the dependencies in any project.

 Lack of Evenly Spread Disciplines

 Another issue that we faced was the lack of evenly spread disciplines. Not a lot of team members worked on the project within the engine. That lead to some team members doing extra work when any issues came up. It also affected the quality of our final product.

 The lesson that can be learned from this is that having evenly spread disciplines is key to a project success. For future projects team members that don’t know how to use the engine could learn and implement at least some minor features.  

 Game Summary

             Throughout the course of our games production we encountered all sorts of things. We pushed through the issues and continued to make our game to the best of our ability. This was at least true for portions of the team. The game is a short demo of what we can make. We also have made it in such a way that we could add and expand onto this game as needed. This is a game that could easily be pushed all the way through and into completion.

 While we had issues during the making of this game it ultimately served its purpose. This was a great learning experience and ultimately taught us all a great deal. These lessons we can take into the future and to help us with all of our future endeavors. Pirates of the Ice Coast is a short game made in a month that taught us all a whole lot. In the future we should be able to adapt and grow even more.

[srgamedesign-blog]

Individual Postmortem: Pirates of the Ice Coast

Pirates of the Ice Coast is an action RPG where you play as a walrus humanoid named Kaijaq, a pirate ship captain trying to make his way in a world full of other pirate animal races.  After learning of some powerful loot discovered by a rival faction, Kaijaq begins a quest to find the treasure for himself.  

 I worked as a producer on week 2-3-4 of the project.

Our biggest flaw as a team was communication. I tried to alleviate this issue by accommodating to each team member. For instance, we held a Discord meeting at 6pm But 2 members could not be part of it. I had a private meeting with one member at 8pm and with the other at 10pm, to update them on the project status and to get the information I needed from them.

Another big issue was commitment. As a producer I’m responsible for the completion of the project. However, it is hard to do this job if the team is not committed to the project. I felt that I had to put a lot of effort to get information I needed. I was absent one week and missed an important presentation. When I asked how the presentation went to the team member that had the feedback notes, it took him 1 day to reply to my messages, and then he never gave me an answer. So, I never knew for sure how the presentation went.

This lack of commitment made it hard to have an effective pipeline we had QA at the end, so when I reviewed the scheduled all the hours had been spent. That gave me a positive view on the project, however, QA found bugs right before our presentation, so the QA information showed that the project was not at the point the scheduled made it look like.

An ideal pipeline would include 2 QA build reviews. One in the middle of the week and one at the end. But this implies that the team would commit to have a build by the middle of the week, and correct as many bugs as possible by the end of the week.

  On the other hand, one of the things that went right was the development. The engine made it easy for the developers to create a lot of content, even though the art was behind schedule most of the times

 This project was a great learning experience, it showed me that having a good pipeline is key to any project. I also learned that the team needs to be committed to function effectively, and a big part of the producer’s role is to make sure that happens. Team building and team morale are key items to make sure everyone is committed. I also learned that everyone has to agree to every process, from communication channels to production pipelines. Especially in student made projects, or in any project that doesn’t have a monetary compensation.

[srgamedesign-blog]

Ratatest team post mosterm

 When going into the month of February our team was tasked with creating a new game. Thus we came up with the concept for Ratatest. Ratatest is a sidescroller infinite runner. Players take control of a lab rat who has the ability to change size as they are the experiment of a mad scientist. With the creation of Ratatest our team experienced many things. We had our ups and downs. We’ve grown and learned a lot about the iterative process. This allows us to move forward and be a better team going forward into our next months.

 When we were creating the game we had a lot of things that went well. The creation and development of our features and gameplay went very well. This allowed for us to quickly adapt and grow the features. We were also very quick at distributing tasks and making sure everyone was involved. This enhanced our productivity and helped the game get developed quickly. With distribution of tasks our artist was capable of focusing on the character and animations. This lead to a character we are very proud of and we feel functions properly. All of these combined to create a series of good prototypes that allowed us to hone in on our concept. In doing so we refined and stuck to our original concept and created a game we can be proud of.

 Throughout the month, our team collectively agreed that communication was lacking. Discord was the only platform that was utilized, which was inconvenient for some team members. In addition, there were repeated absences from various members during team meetings. Apart from communication, we struggled setting up the repository, so it was hard for some team members to have access to the project files. Both the importance on capstone participation and the reluctant communication and disagreement between some members further contributed to the unsynchronized production of the digital prototype. The conclusion we made was that both the scheduling and enforcement to adhere to the schedule were found lacking. Moreover, the negative attitudes of some team members affected the overall productivity of the team.

 After analyzing what went poorly, the team came to the conclusion that improving communication, team building, and technical knowledge is a necessity for future projects. To improve communication we need to have multiple communication channels, a better meeting structure, and a designated producer in charge of scheduling and task tracking. After completing this project, we realized that team building plays an important role. If there is tension between team members it should be alleviated as soon as possible. Finally, having team members with technical skills would improve the speed of the development process and the quality of the final prototype, however, if the team doesn’t have members with technical skills, a good mitigation strategy is to take the time to define some tasks that are adequate for their skill level.

           In conclusion this made for an interesting project. Ratatest taught all of the members of the team a few new things. The things we did well have shown us what to do in order to meet success and continue to create games we enjoy. While what we did poorly showed us how to improve and how we can grow further. Our love for games and thirst for knowledge lead us to create something we hadn’t made before. We hope to possibly further develop Ratatest or look forward to our next game.

[srgamedesign-blog]

Ratatest individual post mortem

My role

              I acted as a producer, however, we didn’t establish official positions in the team. Some of my work was creating a meeting schedule, setting up meeting reminders, creating and updating a Trello board to keep track of tasks. I also worked on the scene of the first digital prototype, and did art for the final digital prototype.

What went well

              I kept track of the work done by most of the team and was able to work with most of them throughout the development process. We had a clear meeting schedule. I feel that I provided good tools that facilitated the work of the team. I also helped some team members with engine related questions and I got practice on Adobe software.        

What went wrong

For this section I’m going to talk about both my individual performance and the team performance, because I feel that the performance of every team member was affected by conflicts that we had. Our final prototype was good, but our process to get there could have been better.      

              I feel that the major problem was team dynamics, other problems were communication and defining clear roles. As a producer I take responsibility, because I know that avoiding these problems was my main objective, and how I tried to do so was not accurate.

After analyzing the work done and after finishing the team post mortem, I think that the main problem with our team was the tension between team members, and I don’t feel that I addressed the problem as I should have because I had not experienced this kind of team conflict before.

As I stated above, I tried to help the team with some tools (Ex. meeting schedule), but I had no power to enforce the use of them, and most of time it seemed that some team members didn’t care about working as a team, and were only concerned about their capstone work.

For example, we had a meeting schedule that was constantly updated and I sent reminders before every meeting, if some team member didn’t show up, we would try to contact them via text message or phone call, but this wasn’t enough to get some people to show up to the meetings, even when the work of others depended on them showing up, whether it was to explain something or send a file. Most of the team members missed at least one meeting, only a few attended to all of the meeting, and this caused the tension between team members to rise.

As a producer I could have created more than one communication channel, and I could have increased the number of reminders, but I don’t think that the problem was getting the information across, I think the problem was that some team members were not committed to the team and the project. And that is a team conflict that I didn’t know how to solve, however, I did use some risk mitigation strategies, I will expand on it next.

We had similar problems when assigning tasks, one team member would override what the team decided, and go his own way. To mitigate the risk of not having a complete project, I decided to give him a shorter deadline, and pretend that it was for the whole team. The rest of the team agreed, and we gave him a deadline that was 2 days shorter than the one for the rest of the team. The purpose was to make sure that his work was done, that he had follow what we had agreed upon as a team, and that the rest of the team could have some time if there was anything that needed to be fixed.

This mitigation strategy worked to have the work done on time, but it didn’t address the main problem, which was that the team member was doing what he wanted without considering the rest of the team. There was work done by various team members that was not implemented into the final prototype because this conflicting team member decided to not add it or simply deleted it, even when the rest of the team wanted to.  

 What could be improved

              Working on this project really helped me grow as a producer, I was presented with new challenges and the quality of the final product was good.

              Personally, I could improve by stating since the beginning that I am working as a producer. For next projects I will create multiple communication channels, and I will be clearer with the meeting schedule and the structure of meetings. Furthermore, I will try to implement team building exercises at the beginning of projects to prevent any sort of conflict. And in case conflict arises, I will deal with it as soon as possible. I will also remind my team mates that the capstone is only worth 30% of the grade, if there is a team member that doesn’t seem interested in the project I will increase my involvement with him, and if that doesn’t work I will contact my instructors to ask for advice.

[srgamedesign-blog]

Methods and UX

The Methods and User experience course, gave me an overall understanding of how users interact with digital products, from a psychological and a physiological perspective. It also gave me tools to design a successful test, knowledge of the different types of tests available, and what are the strengths and limitations of each one. This class also gave me information about the history of user experience, and its evolution. For the final assignment, I tested if new players of Hearthstone would have an equal understanding of UI navigability in both PC and mobile versions of the game. As for my research topic, I made substantial progress in defining the main construct of cinematic virtual reality, and how it differs from filmmaking and virtual reality experiences. Based on literature review, I defined cinematic virtual reality as a new media that needs a new visual language, and stated why it should be treated as much more than just a virtual reality experience with elements of film. Using this as a stepping stone, I will continue my research. The next step is to analyze production methods from film and from virtual reality games, and define which production practices overlap, hopefully, I will be able to come up with a guideline or a set of good practices to follow when producing cinematic virtual reality experiences. This relates to the GDC topic of production, as it directly aims to define a production method for an emerging media closely connected to virtual reality.

{�9�/

[srgamedesign-blog]

Project and Team Management

The Project and Team Management class was all about producing. Before starting the class, I expected it to be all about SCRUM and Microsoft Project technicalities, but since the first day it provided me with in depth content of project management and the role of a PM. I learned different project management methodologies, different types of leadership, different types of team members and personalities, among others. The main functions of the project manager are to Plan, Lead, Organize and Monitor a project, and I learned different ways to do each one of them. I was also able to apply all the content learned in class to a personal project, a virtual reality application that I plan to finish before graduating from the GDMs; I was working on it before the start of the class, but my team, schedule and budget lacked structure and I started to think that maybe it would be best to put it aside for a while. Fortunately, on Project and Team Management I learned how to define and execute a project, I know have the structure that I lacked before and I feel ready to lead my team (with team members based on 4 different countries), overcome challenges, obstacles, and even pitch my project to potential stakeholders. The class was divided weekly in the same way of a project cycle: Project definition, work breakdown structure, risk management and budget, project pitch, and team and quality assurance (Initiating, planning, executing, monitoring and controlling, closing). Working in this order really helped me understand the content of the class, and how to apply it to real life situations. Each week provided me with new relevant information, new ways to improve my project and increased chances of bringing it to completion. The teacher was eager to help all the time, and made available a vast amount of extra resources that have been helpful to further improve my VR project.

After this class, I feel much more confident and prepared to achieve my goal: working as a producer in the game development industry.    

[srgamedesign-blog]

RTD

In the research and team dynamics class I learned academic content about motivation, leadership, team relationships, productivity, among others. I also became a better team member while doing all of the group assignments and applying the concepts learned in class to my own projects. I feel that this class was extremely relevant to my career goal of becoming a producer, because it gave me concepts and tools that helped me have a deeper understanding of teamwork, how to lead and how to create a team that is productive. Furthermore, it gave me the knowledge required to base my assumptions in academic literature, and how to discriminate which content is good to support my ideas. Concepts such as validity have a great importance in any field, and personally, from now on I will always try to base my ideas in valid research. The assignments fomented team building with my classmates and our personal and professional relationship had a significant growth. For my research topic, I started to work on a paper about similarities between the production of film and the production of games, and my goal is to mix them both to create a production method suitable for virtual reality products.    

[srgamedesign-blog]

Inspiration post: Success stories are always inspiring, if they could do it then so can I. 

GoogleMobileAds. (2010, November 26). Success Stories: How Angry Birds Built a Global Brand [Video file]. Retrieved from                 https://www.youtube.com/watch?v=DpLRQy5cNIc

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]

[srgamedesign-blog]