
Methodica is a game that was developed as a direct continuation of the thesis, devoted to researching alternative navigation methods in repetitive game environments. Game environment was specifically developed to resemble case study game – Control – featuring and exaggerating its main issues in terms of navigation: lack of visual access, repetitiveness and complexity. The design includes 3 sectors, every one of them focusing on one of these issues specifically. The main purpose of Methodica is to test my LL navigation system, offered in the thesis as an alternative for classical map + signage approach as present in Control. LL system is a concept idea of creating new or supporting existing game navigation with a combination of light and landmarks, created from a combination of fill, key and pattern lighting.
The project has shown that the concept of LL system can be successfully implemented in a game featuring brutalist or similar repetitive environments and even present as the only navigation tool, can guide players effectively to the key locations and goals of the game. The main complications for a designer were two points: complexity and intensity values distribution. Area 2 of the game showed that high level of architectural complexity requires a very precise lightmapping plan for the system to stay clear for the player and, therefore, functional.

Complexity causes the need to watch the light intensity distribution, to mark more and less important locations to visit. An issue to consider here is how to distribute light values in case, when several important doorways happen to be nearby within one field of view. But taking into account that Methodica’s environment was designed as “sterile”, meaning that the intention was not to involve much architectural hints, textures, colours, signs, etc., the light navigation system proved to be functional.
In further development of the game it’s worth trying to develop its visual aspect more, especially it concerns texturing. Since the environment has brutalistic features, the game would benefit greatly from playing with concrete textures, geometrical shapes and even colours, what could even benefit and strengthen the navigation as well. Additionally, the game can be supported with some storytelling features, that were present in the original plan, but were not implemented in the final product. The reference here could be one of the mini games in the Beginner’s Guide, with levitating icons throughout the map triggering messages.

As a substitute allowing players to speculate on the story of the place was derived from NaissanseE, by introducing the cube creatures or specific places of interest. That was needed to provide players with more entertainment and encourage them to explore the map apart from main pathways. Technically the game would also benefit from post-processing, what will make lighting more distinct and natural.
Problems encountered during game development were majorly technical, which was caused by the fact that Methodica was the first attempt of creating a 3D game. This resulted in learning modelling game environment from scratch in Blender, importing it to Unity, setting up the lighting, scripting etc. At some point with major problems during first attempts to generate light maps of acceptable quality, there was serious fear of having to rework all the technical concept of the game, and move it from 3D to 2D as the main element – lighting schemes – couldn’t be implemented correctly. Since 2D would distort the concept of navigating virtual space as close to real life as possible, a lot of approaches to make lighting work have been tried, which, eventually, ended up in success and the working pipeline of light generating was settled. After that point the game could be developed as planned.
Thus the game didn’t intend to have complicated scripting, creating 2 puzzles became a struggle as well as solving some minor functions that relied on scripting. For example, block puzzle 1 can be considered as unfinished, because it can be “solved” just by activating all of the blocks, but not specific ones as planned. Apart from that it would benefit from solution hints as playtests showed that players didn’t seem to understand the task clearly and went for just activating most of the blocks, that included the correct ones. This issue was considered while implementing path puzzle to one of the keys, so that puzzle can be solved only in one correct way.
In general, playtesting gave important feedback on whether or not players would follow the lighting navigation as planned, and reassured greatly about the key points of light distribution as well as showed several weak points that were fixed or updated to be more clear:


Another important outcome that influenced the game greatly was the importance of feedback on players’ actions. Initially the game required player to guess what happened after activating something and where, which was not productive and confused player instead of encouraging to explore and check, what had changed. It resulted in learning to work with cut scenes, which became the main source of the game communicating with the player on their progress.
Overall, the project became a major piece of technical experience, where most of the elements had to be learned from scratch. Thus it caused a lot of anxiety over failures at some stages due to the lack of knowledge, I was gradually learning the basics, that eventually resulted in the most complete game I’ve ever created during the course. I learned to search for answers to technical issues quickly and became much more confident in coding, with less fear of experimenting and checking if the idea will work or not. I believe this work to be my strongest, and thus there’s more ways the game can be developed further, I made it as polished as I could for the current level of game creating skills so far.