Week 5 development

This devlog will largely focus on the testing, testing results, and what the team will do with the results. 

PRE-TESTING:

The morning before the testing was quite rough. Since the level designer had a copy of the project on a personal machine and it had libraries that the main project didn't have applying updates was quite troublesome. Some things also weren't working as intended due to the changes in other scripts and required quick fixes. The level also did not display all of the functionality that the game had and had things that were not planned for (mainly the curvature of the floor) that broke some mechanics. However, the game was tested prior but most functions were left out of the testing due to a misunderstanding.

TESTING:

During the testing, a big problem became known: performance. This came as a surprise since the game was tested on multiple machines and performance was never an issue, however, as we realised during testing the CPU is taxed much more heavily than expected due to the app being web based. All of the machines that the testing was on had quite powerful CPUs so it never was an issue. Performance would not be a big issue by itself, however, it caused the camera to be extremely unwieldy at the start of the game while assets were still being loaded. This caused great trouble for a lot of players and some were not able to play the game properly. The players that did manage to get through the laggy camera provided great feedback. A lot of mistakes were found in the tutorial part of the level as well as the main level. Sadly, the level was not filled out with items properly which caused players to not be able to progress through the crafting tree as expected.

POST-TESTING:

Main takeaway was simple: the pieces of the game did not come together nicely, even if they did work by themselves. This was due to a degree of independence too large and not clear enough communication between the team members. The solution is also quite simple: quality assurance. Freedom in development is good, however the entirety of the project needs to be held up to a specific standard so that it all comes together. We decided to create two more positions: the QA for code and functionality, and the QA for the level design and gameplay. Functionality QA is quite formal. There exists a document that contains steps that the tester needs to go through without receiving any errors or unexpected behaviours for the game to be considered functional. There is a dedicated person that will test functionality of the game whenever the code goes through changes to ensure that those changes did not cause any unexpected behaviours to occur. The level design will be slightly less strict and will test the ability of the player to complete the level, the ability to craft every item available, as well as the timings of the player and the fun factor. The level will also be tested on machines with weaker CPUs to ensure the performance.

Other smaller changes that needed to be done were: improving performance, improving the movement system, making breakable walls more obvious, making the IQ mechanic/crafting more obvious, displaying keys needed in the tutorial rather than in the description and other small improvements. We decided to address a big portion of those by rebuilding the level. The new level will have more text in it, will not have fancy graphics or curves in the terrain, will be checked and adhere to QA, and the resources will be distributed more thoughtfully. The other problems will be addressed by giving the breakable walls more explicit textures and improving the UI.