#also the whole deal with the minor antagonist pirates of the week

[waywardsalt]

shooing away all my doubts with the bellum x linebeck plans bc It Is A Draft but now im thinking. whose pov should the confession be from

[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.

[brockgilbert-blog]

Team 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.

[zion3dt-blog]

Pirates of the Ice Coast Team and Individual Postmortem

These are the postmortems me and my team made for our month nine class within our game design masters at full sail university.

(Team)

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.

(Individual)

Zion Ellis

Asset Management - Individual Postmortem

Pirates of the Ice Coast – 03/29/2018

 Pirates of the Ice Coast was a fun game to create a prototype for, and I really enjoyed learning more about RPG maker. There was still a lot of friction within the team however tasks were assigned in a manner to attempt to work around this friction this month. Despite this, discontent was present between some team members. Having stated this, it is also important to state that all team members stayed professional this month and there was little trouble working with one another. The biggest problem this month was absences and terrible communication with some team members.

Week One

Within the first week everything went very slowly and there were assets turned in far too late, making implementation very last minute. The QA tests this week pointed this out quickly, and the lack of documentation also showed that we were not working together efficiently to plan for the next three weeks. This was not due to discontent between the team however, as it was more attributed to difficulty with arranging meetings and absences. There was still a bit of refusal to plan for weeks two through three however, as when I had mentioned a few times that we were asked to plan for all four weeks there was disagreements about that.

Week Two

After the First presentation, everyone was corrected on their errors and new motivation was instilled in all members. Everything was hastily pulled together in an attempt to make corrections to almost all aspects. Due to this rush however, some problems arose as things got overlooked or barely missed. There was in addition to this still one member who was majorly absent, which resulted in assets turned in late and either implemented last minute or not at all. There was still a little difficulty with communication and from some there was nearly none. Documentation suffered some from the rush as well, and while most of it was now present, it was still riddled with minor flaws.

Week Three

By now, we had all had strict discussions and made a more concentrated attempt to correct errors and hold people more accountable for when assets were turned in. Most of the art was prepared earlier, however there was still some a bit late for the QA tests, and one piece still accidentally missed at the end. The documentation was much better, however some errors persisted as everyone had a bit of trouble making sure not to accidentally miss something. Still, effort was much more prevalent by now and it showed as the production process was becoming smoother.

Week Four

Now Under the pressure of a reduced deadline, everyone put in their best effort to get everything in and all errors fixed. The communication by now was exceptionally better and nearly no art assets were late, with the few exceptions only being minor. It was still extra hard to crunch as this time we made our final deadlines extra early to give time for multiple QA tests with nearly all assets present. The team by this point had become much more solid, and I believe that any further contributions would be much smoother. The difference between the first week and forth is truly an extreme difference.

[royyuanfs-blog]

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.