Table of Contents
- Module Five Project Log Prompt Questions:
- What parts of the plan did the team perceive to go well in relation to the last stage evaluation?
- What parts of the plan did the team perceive to go wrong in relation to the last stage evaluation?
- How were the previous evaluations wrapped into this latest stage?
- What would you do differently to improve the process?
- Were there any tools or techniques that you did not find helpful in the success of your project development? Why?
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Module Five Project Log Prompt Questions:
As a team, you will routinely conduct reviews based on your progression towards the plans that you created. Evaluate the plan that your team created in Module Three from a technical/programming standpoint.
After completing your plan analysis, conduct a team reflection and consider the following:
- What parts of the plan did the team perceive to go well in relation to the last stage evaluation?
- What parts of the plan did the team perceive to go wrong in relation to the last stage evaluation?
- How were the previous evaluations wrapped into this latest stage?
- What would you do differently to improve the process?
- Were there any tools or techniques that you did not find helpful in the success of your project development? Why?
*Please note: This is a summary of the discussion that was had at our Module Five Team Project Log meeting. This meeting was held using a Discord voice channel. Group participants were Kylie Nencetty, Daniel Noel, Joe Rafferty, Brigitte Rollain, and Jenji Sayre. Any information that is followed by parentheses and a group member’s name indicates that this person contributed to the idea during the discussion.
What parts of the plan did the team perceive to go well in relation to the last stage evaluation?
In the alpha testing stage, we were not always consistent in updating our traceability matrix or test plan document accordingly to reflect changes or additions that we made to the game features. For the beta testing, we were more thorough in updating any game design documents that needed it to reflect these changes. This helped us avoid duplicating work or wasting time during our playtest to make changes to the game design documents or actual prototype. (Group Decision).
In the alpha testing stage, we were not prepared to do QA testing until almost the last minute. This made the testing process somewhat stressful and did not allow us much time to resolve more complex bugs that were found while testing (Group Decision). We stepped back and readjusted our timeline to get back on schedule. We also had backup plans in case a tool or technique we were using failed to be successful—this helped us immensely and ensured that we had a playable prototype ready on schedule for testing (Group Decision). As a result, we were able to start fixing any additional bugs that were found immediately and have continued to test as we implemented those fixes.
What parts of the plan did the team perceive to go wrong in relation to the last stage evaluation?
For the most part, the team considered this testing stage an overall success (Group Decision). However, we do see room for improvement in our test plan process. There were issues that we noticed during our alpha testing which we thought were not ‘game-breaking’ but took away from the end-user experience in terms of how difficult the mechanics were (Group Decision). A primary example of one of these issues is the jump pad in the stomach. At the time, we believed that this was just a bit too difficult of a jump to make successfully, but we were unsure that it needed to be resolved because it was still working. However, once we fixed other issues in the game the question of whether this jump pad was an issue or not became glaringly obvious—not only was it an issue, but it could almost be considered a game-breaking issue to a player who was not involved in the game development process (Brigitte Rollain, Daniel Noel). In retrospect, we should have focused on every issue even if we weren’t sure that it was truly a problem (Joe Rafferty). It is important to have a fix ready to implement if it becomes a larger issue once other bugs are addressed (Kylie Nencetty). In the future, we will be broadening our focus when implementing bug fixes to a wider array of what we consider a ’bug’ (Jenji Sayre).
How were the previous evaluations wrapped into this latest stage?
Previous evaluations were wrapped into the beta testing by going through each alpha test case scenario again. We were sure to test every scenario again, even if it had previously passed the test case scenario in the alpha stage. By doing this, we were able to determine that none of our bug fixes had introduced new bugs to previously tested features (Group Decision). We also continued to test frequently throughout the development process prior to the formal beta testing stage (Group Decision).
What would you do differently to improve the process?
To improve our testing process, we would like to have handed out our alpha and beta prototypes to our friends and family for unbiased player feedback (Joe Rafferty, Kylie Nencetty, Daniel Noel). There are often things within the game that as developers, we easily understand. However, what seems obvious to the developers may not seem as obvious to an outside player (Jenji Sayre). We tried to think in terms of the end-user experience, but it can be hard to completely detach yourself from the vision of the game (Kylie Nencetty). We have now begun showing the beta test to friends and family to get their feedback, but it would have been beneficial to have started doing this earlier in the process (Group Decision).
Another improvement to our testing process would have been to include sound integration earlier in the project development (Kylie Nencetty). The idea of creating and integrating sounds was overlooked until alpha testing when it became clear we had created an almost entirely silent game (Brigitte Rollain). For immersion, we thought it was important to start working on adding sounds to certain features of the game (Jenji Sayre). However, because this was an afterthought it was not easy to include this in our schedule. We have been having multiple roles working on adding sounds here and there throughout the testing phase, which is not ideal (Daniel Noel, Joe Rafferty). By doing this, we run the risk of duplicating work and losing focus on other aspects of our bug corrections (Group Decision). For example, we achieved some great sound integration in our level but forgot to complete work on correcting one of the bugs prior to testing (Daniel Noel). We have since gone back and fixed the bug, but had we remembered to include sound in our original game design document this mistake could have been circumnavigated (Daniel Noel).
Were there any tools or techniques that you did not find helpful in the success of your project development? Why?
Some tools and techniques that we found were not helpful in the success of our project development were previously discussed in the Module Four Project Log wiki page. However, we did come across a technique that failed us in this latest stage as well. We wanted to try various ways to address our issues in the capillaries. One of the solutions we discussed was using the hollow brush tool in Unreal Engine to construct the capillaries as one large static mesh (Joe Rafferty, Brigitte Rollain). However, our level designer found this technique to be too time-consuming and difficult to use. The level designer had to click on every face and extrude them but realized that it just wasn’t coming together as it was envisioned (Brigitte Rollain). Because of this, we quickly pivoted and began reconstructing the capillaries using one of the other methods that we had previously discussed (Jenji Sayre, Daniel Noel).