Unity GKL - Runic Plains - Testrun - 5/2/2023

        Nearing the end of our level design course, it was finally time to unleash all the skills we've learned thus far and develop one final level to display all we've learned. With this project, I set aside as much time as possible to deliver something I hope my audience would really enjoy. As always, layout should come first, so for the concepts, I attempted to deliver on utility and aesthetics using engaging platforming, scenic overlooks, and open vistas. Rather than build a level that was purely eye-candy, I continued asking myself- "Is it fun?". 

        As I had hoped, that section was a hit with those who tested my level, but a new issue arose with this project- hardware and software limitations. At the start of this week, the strongest of my two number-crunchers (a dated though sturdy desktop) proved to be less stable than expected, with a surge frying its motherboard for some reason or another. For the second half of the design process, I've rendered navmeshes, baked lighting, and done just about everything on my laptop. More than once, baking the navmesh took many hours- within which no other work could be done, but little could be done besides moving onward when able.

        The day before testing carried its own challenges as well. External emergencies led to sleeping through alarms, and the following morning, I was unfortunately late to testing. C'est la vie en université, so only a few tests were able to take place, though the feedback quality greatly made up for the quantity. Though a simple reminder, "Is it fun?" quickly proved itself in my first playtest. Such a simple reminder had such an impact on my philosophy with the design process. One of the best examples of this was a destructible fort on the rolling plains. With adopting this new outlook of game design, this section would've remained another boring hill with more of the same 2 enemies littering it. In the first playtest, the tester particularly remembered and enjoyed that section because it let him explore the mechanics in a freeform way by letting him absolutely demolish the fort's outer wall. One playtester even let out a "hell yeah!" while busting through the bricks.

        After the fort came the bridge section. Around here, I tried experimenting with the mechanics of the game kit, trying out vertical moving platforms, enemy scaling, etc. While this did add some variety to the gameplay, several issues arose from the additions. If a platform moved up too quickly, the playable character's model would perform the falling animation and sounds repeatedly. Despite the annoyance, it had little to no hinderance on the gameplay. 

        The other major issue that came to be was that the running game would freeze and glitch the player's view and position in precise intervals. For the remainder of my development process, I assumed it was just an issue with the scale of my project and my poor little laptop being unable to keep up, but in one of my playtests today, the subject noted that the freezes only occurred once they were within range of the bridge. It was this acute observation that helped me discover that the glitch only happened when the player was within range of a rescaled spitter enemy. From there, we noticed that their projectiles were also scaling, though not in direct proportions like I had assumed. It would seem that the code written for the projectile might have it scale by another, unknown factor, spawning the absurdly large projectiles partially in the ground, confusing Unity's physics/collision systems. Whatever the matter, the spitter enemies have already been rescaled for the next iteration.