SNHUProjects
/
GAM305_Green_Repo
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity
Page: Module Four Project Log: Team Reflection
Pages
Home Module Five Project Log Team Reflection Module Four Project Log: Team Reflection Module Six Project Log Team Reflection Module Three Project Log Team Development: QA and Testing Plan Module Two Team Project Plan
3 Module Four Project Log: Team Reflection
kylienencetty edited this page 2024-02-05 02:42:54 +00:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters

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 Four Project Log Prompt Questions:

As a team, you will conduct a QA and test plan of your project using the plan your team developed in Module Three.

After completing your QA and test plan analysis, conduct a team reflection and consider the following:

  • What parts of the testing process did the team perceive to go well?
  • How were bugs identified and corrected?
  • In terms of the QA and testing process, what would you do differently to improve the process?
  • What tools (chosen in Module Two) did you find successful in the development of your Alpha project? Why?
  • Were there any tools or techniques that you did not find helpful in the success of your project development? Why?
  • How did the team approach to the initial analysis of the game design document contribute to the decision to use these tools and techniques?

*Please note: This is a summary of the discussion that was had at our Module Four 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 testing process did the team perceive to go well?

Overall, the actual testing process was smooth and efficient because we developed a thorough test plan. Testing was done concurrently throughout the development process which helped mitigate the number of bugs when we tested the entire alpha in a team meeting. Each member of the team was able to pull the alpha from the repository and go through every previously outlined test scenario. We each made a copy of the test plan using our hard copy in Google Sheets. From there, we all went through multiple playthroughs of the alpha during a verbal team Discord meeting. We were able to share pictures of problem areas and discuss these in real time. It was an efficient process that produced positive results which were easily communicated between team members. (Group Decision).

How were bugs identified and corrected?

Bugs were identified individually through multiple playthroughs of the alpha. When a bug was found, the person who identified it noted the bug, where it was found, and what caused it. We also verbally communicated with the rest of the team where and how the issue occurred. From there, team members would try to recreate the bug in their own playthrough and document what occurred. We were able to take screenshots of the bugs and share those in our designated discord channel in real-time. (Group Decision).

Because we had been testing throughout the development process, most of the bugs that we identified during our alpha test meeting were easily fixable (Joe Rafferty). For example, an issue was found where the viruses were reproducing without a limit (Brigitte Rollain, Kylie Nencetty). We had intended for them to stop reproducing after reaching twenty. This was a game-breaking bug that was causing the game to crash. Therefore, we paused our testing process and gave the lead programmer time to resolve the bug (Joe Rafferty). Once the bug was resolved, we pulled the new alpha test file and started our testing phase over again. However, we did come across a bug within one of the capillaries (Daniel Noel). The issue lies in the modeling of the capillary (Joe Rafferty). It is a branched capillary that if the player encounters it at just the right angle can cause clipping. There were a few documented instances where the player clipped out of the map entirely (Daniel Noel, Joe Rafferty, Jenji Sayre). This is something that we cannot resolve before the alpha release, so we considered blocking off that path before submission, as there are other ways to access that part of the map. Ultimately, we decided to leave the capillary branch accessible, as we were able to minimize the occurrence of the bug by editing the intersection within Unreal Engine (Brigitte Rollain, Joe Rafferty). We have a plan in place to resolve the bug before the beta submission. We are planning to remodel the capillaries and rooms using Blender and then replace the ones that were previously created using splines or static meshes within Unreal Engine (Jenji Sayre). If we do not have the time to do this, we will make the capillaries a larger diameter while also ensuring that the player cannot enter or walk through them while un-crouched (Joe Rafferty).

It should be mentioned that there were other instances where we found that features within the game were still working, but not entirely as intended. For example, we do have an issue where if the player does not hold the crouch button within certain capillaries, the player model can get stuck momentarily (Kylie Nencetty). While this is not a game-breaking issue, we do want to resolve this to create a better end-user experience. This will be resolved using one of the methods mentioned previously on the modeling of the capillaries (Joe Rafferty, Jenji Sayre). Also, we identified some jump pads that are difficult to use. While the jump pads can still be used to get to the above platforms, they need to be hit at just the right angle for the jump to be successful. As a team, we felt that this is too difficult of a mechanic to make the playthrough enjoyable and will be working to adjust the jump pads and resolve the error (Group Decision). This bug resulted from the jump pads being engineered for a flat surface by the programmer (Joe Rafferty). When the design team placed the jump pads throughout the level, some were placed on angled surfaces or in the air. Because this placement was not in the same context as the programmer’s intent, we either must alter the programming of these jump pads or alter the design of the level so that they function within the intended context of either the programmer or the design team (Joe Rafferty, Daniel Noel, Brigitte Rollain). This is something that we must discuss further as a team about how we will move forward in resolving (Group Decision). Finally, another bug was identified within the togglable tasklist. There is a task that runs off the screen of the vector image (Kylie Nencetty). The UI designer will widen the image and then it will be reimported into the UI to resolve the issue before the beta release (Kylie Nencetty).

We were able to package our alpha release. There were no errors while packaging. However, after packaging some of the AI did not move as expected, even though the AI does move as expected while running the game within the Unreal Engine editor (Joe Rafferty). The programmer looked through the output log while packaging. They were able to infer that the packager was packaging the wrong map, and this was causing the issue (Joe Rafferty). The packaging was done again, this time ensuring that the packager referenced the correct map, and this resolved the bug (Joe Rafferty).

In terms of the QA and testing process, what would you do differently to improve the process?

Firstly, it would have been helpful if we had been able to do QA testing of a complete prototype earlier in the process so that we could fix the more complex bugs before the alpha release (Group Decision). We now realize that to do this, we would have had to go about our development process and the assignment of tasks to certain roles in another way. For example, if we had originally had the level designers create only a block out of the level before doing any modeling then we would have been able to pinpoint the issue with the capillaries earlier and resolve the bug prior to submission (Daniel Noel, Brigitte Rollain).

We also need to make sure that any changes that are made to the project are reflected in the test plan to prevent duplicating or adding unnecessary work/testing (Group Decision). For example, we realized that the health pickup test case scenarios needed to be changed upon testing (Joe Rafferty). Originally, we had intended to have the health pickups disappear from the map and heal the player upon collision, we later decided it would be better to have the health pickups stored in the hotbar and allow the player to use them as they wish after receiving damage (Group Decision). We hadn’t updated the test plan to reflect this until we went in to do the testing. Therefore, we had to pause and come up with test case scenarios to ensure that this feature was integrated properly. In addition to this, we also decided that it would be better if the plating around the health bar changed colors after the player picked up armor (Kylie Nencetty). Because we hadn’t updated the test plan to include this, this feature was missing during the initial group testing. Therefore, we had to pause while the UI designer created the alternative color for the health bar, and the programmer integrated the feature into the game (Kylie Nencetty, Joe Rafferty). We then had to restart our testing to make sure that this feature was integrated properly (Group Decision). Had we been more thorough in updating our test plan accordingly with the changes to the game prior to testing, then we would not have had to spend time making these changes during our meeting and rerunning test scenarios (Group Decision).

Lastly, we now realize that we should have implemented the information screen before the alpha release (Kylie Nencetty). It was previously decided that the information screens would be implemented before the beta release but after the alpha release. As we were play-testing, we realized that if someone were to test this prototype without the guidance of the developers then they would not be aware of all of the player controls unless the information was specifically provided to them outside of the game (Daniel Noel).

What tools (chosen in Module Two) did you find successful in the development of your Alpha project? Why?

Various tools and techniques were used throughout the development process for each role. The lead artist found the use of Blender to be very successful in creating models for viruses and other in-game assets such as the syringe gun (Jenji Sayre). Blender allowed the artist to create more dynamic and diverse models with ease and efficiency than Unreal Engine would have allowed (Jenji Sayre). Maya was used to rig one of the viruses because the rigged model was able to be imported into Unreal Engine more easily than importing from Blender (Joe Rafferty). Unreal Engine blueprints were used for all the programming in the game, and there have not been any programming bugs that could not be fixed using this tool (Joe Rafferty). Adobe Illustrator was used to create UI design elements and the end-of-game screens. This was very successful as it allowed the UI designer to create more detailed UI assets than would have been possible if using what was available in Unreal Engine (Kylie Nencetty).

Were there any tools or techniques that you did not find helpful in the success of your project development? Why?

The only major drawback that we have faced was using Unreal Engine to model rooms and capillaries. We found that the tools available in Unreal Engine for the modeling of the landscape and its features were generally unsuccessful and time-consuming; thus, these tools did not help us succeed in this project (Daniel Noel, Brigitte Rollain). While the level designers did great work with the tools they intended to use, we now know that we would be in a better position currently if we had used modeling software to sculpt the rooms and capillaries (Joe Rafferty, Jenji Sayre). It would have been more beneficial to have had the level designers focus on greyboxing the level and placement of landscape features, and then have an artist create the models for the rooms and capillaries using something like Blender or Maya (Jenji Sayre, Daniel Noel, Brigitte Rollain). This would have alleviated much stress from the level designers and given them more time to focus on the actual level design versus issues with capillary clipping, the seams where the tunnels met the larger rooms, shaping the rooms, and material stretching on surfaces (Brigitte Rollain, Daniel Noel).

We also had a slight issue when attempting to import a rigged model from Blender into Unreal Engine. However, we believe that this issue could have been resolved if we had more experience importing rigged models from Blender into Unreal Engine, but ultimately it was more time-efficient to just re-rig the model in Maya (Jenji Sayre, Joe Rafferty).

How did the team approach to the initial analysis of the game design document contribute to the decision to use these tools and techniques?

While analyzing the game design document, the team decided it was best for everyone to explain what tools and techniques they had previous experience in and were most comfortable using (Group Decision). This was also how we were able to break down our tasks and decide who would fit best in each role. It was decided as a team that we would be using Unreal Engine’s blueprints for the programming (Joe Rafferty). This decision was made because the lead programmer felt most comfortable using blueprints, and not everyone in the team was familiar with C++. Because all the team had programming experience using Unreal Engine blueprints, we felt that this was the best tool to use to ensure that if anyone were to help with programming, they would be able to understand what had previously been done (Group Decision). The UI designer felt that they were most comfortable using Adobe Illustrator to create vector images, as they had successfully created vectors in the past using this software (Kylie Nencetty). The rest of the team agreed that they preferred using Adobe Illustrator over software such as Adobe Photoshop (Group Decision). The lead artist explained that they have experience modeling in Blender and thought this tool would be easier to utilize than the Unreal Engine tools for modeling of the in-game assets (Jenji Sayre). Because our programmer felt comfortable importing from another modeling software into Unreal Engine, we decided to move forward with the use of Blender (Joe Rafferty). The level designers felt that they had experience enough to use Unreal Engine to create the level but knew that they would need to do some research into how to sculpt certain shapes (Daniel Noel, Brigitte Rollain). At the time, we felt that this was the best tool to sculpt and layout the level given everyone’s familiarity with Unreal Engines landscaping tools and applying materials (Group Decision).