Category: FINAL MAJOR PROJECT

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.

Finally the playtest (final, I guess) happened and I’m happy to see that a very small amount of alterations needed that I fixed the same day.

First of all the lighting pathways really work and testers managed to complete the game and find all the keys. However, I noted some of the “problematic” areas, which I thought were clear, but in practice – not. So I fixed them a bit like here:

Another major alteration was skipping the cutscenes, which were irritating if we had to reload the game and get to the place quicker. That wasn’t much of a coding problem for me, but for the intro cutscene, which aborted the first switch of the cameras, but din’t the rest of them. That’s when I was introduced to a new function for me – CancelInvoke. That solved the problem.

Apart that there were some very minor bugs, which I missed due to inattentiveness. Like I forgot to destroy the trigger of the cutscene that shows the door to second puzzle being open. But after another person played the game, I decided to leave it, in case player gets lost and want’s to see the hint again.

Another bug was with puzzle 2 where I placed the trigger that destroyed the reset trigger, assuming that if the player got to that place, they solved the puzzle first, in the wrong place. So I just moved it just behind the barrier, so that player will definitely get to it only is the first barrier is retracted. And player can’t have it retracted completely until they solve the puzzle.

And one more thing I noticed is that players tend to rush too much while playing and not paying attention to lights and where they lead. So I decied to add a disclaimer in the main menu, with some information on how the game works and what to expect from it. Hope that helps a little.

Conclusions

I believe that is the last developer entry as I feel like I’ve achieved everything I planned for the project. I only need to recheck everything one more time and make the final build. To playthrough video is coming up together with critical reflection on the project. Stay tuned!

After coding troubles with puzzle 1, I was a bit reluctant to start developing puzzle 2. So I wanted to reuse as much of the code I already had as possible. Version 1 of the puzzle looked like that:

Basically is was a “find the correct path” type of puzzle. The Strange Brigade puzzle is a reference here, where player had to move only to blocks with a correct symbol. The right combination was hanted somewhere nearby:

So I wanted to place the key in the centre and player had to activate the correct tiles which could form a particular pattern. Reference image can be placed somewhere across the map as a hint, or just be present on one of the walls in the same room. I also thought about the possibility of upper floor, so that player could see the whole picture from above wether they’re getting the correct image or not. Same as in puzzle 1, tiles would change colour on collision.

But some dayf after I decided that this plan was too complicated and I didn’t feel like it was thought through. So I came up with another plan:

Eventually I refused the idea to place the key in the centre. I considered it as not worth developing and making things simplier. So now player has access only from one side and the correct path is the only way to get to the key. I already clearly saw what functions each tile must do, so started coding.

There was a minor issue whith colour change, when the same proved to work colour changing code from puzzle 1 suddenly stopped working. It worked in the inspector, but didn’t work in the game. I’ve spent evening and morning to try to understand, what was wrong, till I foind out it was a pure inattentiveness mistake as there was a copy of the same tile underneath that didn’t change colour. (Another proof that good rest is needed despite the amount of work you need to do).

But another problem waited overhead, which was complicated for me to solve. The problem was that when I tested mechanics on just one right and one wrong tile – it all worked fine. Once I multiplied it to build the puzzle – it all broke. In particular, wrong tiles stopped blocking the right ones and changing their colour back to black. I’ve spent a couple of hours looking for the problem, thus all the coding was right and worked when I’ve left only 2 tiles as in the beginning.

The problem turned out ot be in one command here

That’s how I usually refered to variables from another script. Which, as I found out, happens to refer only to the first ever object with this script, which the system finds in the hierarchy. Which means that I had to create a copy of that script individually for each of the 14 wrong tiles. It was time consuming, but still I was happy, that I found the reason. The puzzle was complete in 7.5 hours in total in one go. I also added a hint just near the door to this puzzle.

Completing the puzzle means that most of the work for the project is completed and the game is ready for the final playtest. I’m pretty confident in what I have now, and, hopefully, I won’t need too much alterations.

I continue with easy, but time-consuming work of getting the area ready for gameplay.

While I was testing the area for lighting, I thought that so many secondary rooms are empty, and since the game is explorational, I must place there something interesting to see. So what I decided to do is to create many simple animations of cubes, doing their fun stuff as habitants of this weird place. I was inspires with NaissanceE (one of my initial references), which had cube-like creatures that were afraid of light. I liked the concept for its simplicity and started to place cubes doing stuff over the empty areas. I crrated them quite randomly, without any particular plan in mind. Some examples:

Apart from cubes, I also made some “weird spaces”, with just some unknown objects, some of which work as landmarks:

Apart from that there was a bunch of small works, that were fast to complete, and I don’t think they’re worth much attention to describe. I’ll just list them here:

• Remove doors from area 1 (which were placed just for the purpose of first playtest)
• Remove trigger texts (the ones “area under construction”)
• Change material of keys to match panels
• Change sector signs under main door panels
• Attach puzzle 1 to the door with square symbol (previously it was attached to the 2 doors blocking the way to half of area 1)
• Animate the rest of the elevators (like in area 1)

So, basically those were some touch-ups to blend area 1 and area 2 as well as fixing some of the issues of playtest 2. For example, I connected keys with main door more, so that player will get feedback on their actions. Now it has a cutscene that indicates players action and progress:

Among other works:

• animate the rest of elevators and set triggers for them
• Create an intro cutscene (I felt there’s a need in one, and I tried to merge it with some sort of instructions. I showed that lights form a pathway, what objects to find and the game goal – which is to open the door)

• Set up trigger button to door to puzzle 2:

There was nothing new or complicated, I reused the same scripts and mechanics as for the opening of the door after puzzle 1. I just wanted to highlight the brilliantly easy code I came across for triggering any animation from any object without the need to spend time on setting transitions and booleans to trigger by writing in the code. The only thing you need is to attach the object with desired animator and write the name on animation

For now I consider the area as ready, and I proceed to creating puzzle 2, which gives access to key of the square sector

Since playtest showed that area 1 mostly works as intended, and I was tired from working with it, I decided to postpone post-playtest alterations and switch to modelling area 2 instead. Area to was planned as representation of 2 navigation issues: repetitiveness and lack of visibility. Lower part was designed as analogue of Maintenance secror in Control.

Modelling took some time, but went much faster and efficient due to previous experience with area 1. I took into account some modelling mistakes that resulted in light artefacts in area 1, and this time checked thoroughly for the object not to intersect one aonther.

Modelling resulted in this kind of labyrinth:

Compared to the original plan,

you can notice that I had to expand the area as I came to the conclusion that original map lacked decision points, which means the route was still corridor-like with one doorway in and one doorway out despite decorative intersections within a room. This didn’t work for the original intent to test my lighting navigation with complexity issue, which means having several important decision points, and the system that should aim to target player to the desired path.

My only worries were about importing the model to unity as I had some negative experience when trying to reimport area 1, which resulted in loss of all lighting work done and having to restore the project from a backup file. (And resetting lights for the second half). So instead of importing it as a new object (or blend. file, I tried all options), I imported it as the same prefab as area 1, but then deleted all double elements of area one. It worked very well, didn’t flip the normals and later on calculated lightmaps correctly without ruining lightmaps in area 1.

Setting the lights

Again, this time setting the lights was much easier technically. I’ve worked out optimal area light settings that give a nice smooth base light to illuminate rooms and then goes work with windows and spotlights, to form pathways of pattern key lighting. The pipline is set up spotlight and panel (to cover the outside) to a pre modeled “window” of a particular shape (that indicates a sector pattern), and either leaving it as fill light or in most of the cases forming a key light indicating the desired pathway:

Thus the process was easier technically, it was harder conceptually due to the area being more complex than the first one.

I have created one more lighting plan (together with some thoughts on doors and puzzles), and as messy as it may seem, I succeeded to define the main pathways.

Pathway arrows mean that these rooms must be especially clear with patterns and brightness. Result of plan execution you can find below.

I tried to make 2 distinct pathways that will intersect and by following the brightest areas player wil eventually get to all key areas. Player is still free to explore and move, but in case they get lost or wish to get to the game goal, they can do so by finding the closest bright spot and just follow the light pathway.

I showed this screenshot to a couple of people to see if they’re able to distinguish the main pathways. And while the bottom-to-top pathway on the right was ok, the left area looked messy. That was about the main problem I encountered in the process – distributing intensity values across the map. I didn’t want to make the rooms too bright to make pattern lights more vivid, but since secondary rooms also had this type of light, it became hard to distinguish secondary from primary ones. Up to the point when I got lost myself while testing it. So despite my wish to maintain a darker atmosphere, main pathways had to be lit more intensely, and so to distribute other intensity values with the reference to the highest value of the main rooms. I ended up with this set up, which was reported to be much better in defining main pathways.

This is another example of the same issue. This area is an important crossroads with 2 paths leading to compulsory objects, which should be identified with a high level of light intensity. At the same time this particular area is also important, and mush be illuminated in the same way. As the result, the area became too light and lost contrast to communicate the message to move to the room in the front, even thought pattern light is still present poining in that direction.

Due to pattern light forming a nice pathway to key area, I decided to make the crossroads darker. It seems more beneficial and communicates better.

These are just a couple of light values examples, in reality I’ve spent a good amount of time to resolve many similar cases. But eventually the lights were all set up and bakes succesfully. Next I’m going to finish with a big chunk of manual labour – that is to set animations throughout the map and get everything ready for scripting.

Time for a major playtest of the work done so far. The game mostly worked as planned with some points to consider:

1. Light navigation mainly works as intended. Players navigated the space well enough, but some reports about “feeling lost” by the middle of the game were present. I think this can be solved with implementing some story based “instructions” telling players the main principle to follow the light, which is designed in the way to put player on the right track. (destroy some lighting that isn’t relevant after activating a key?)
2. Connection between keys and main door must be increased. Players reported that game is lacking feedback after activating main door keys. This can be improved by: A) changing colour of the cubes according to the panel colour B) when the key is triggered, show cutscene with panel lighting up on the main door (like the final one when all 3 are activated) (might need to learn Cinemachine)
3. Nobody took the front door path which means light in the area is set correctly as players were taking exclusively the path intended.
4. Some technical issues to fix: jump, elevator slow down, bring final trigger closer

Additionally: make intro cutscene, fix clipping cubes, loading scene

After the playtest I see that the game needs minor fixes, but in general the game works as intended, what means I can continue with the rest of the area. I will fix the issues first to have the project ready just in case and then just technical work to develop the game in size and test the navigation system in various environmental situations.

During the last 4 days I made major progress from just an empty area with light to a fully working prototype. My aim was to make a fully complete part of the game, so that after the playtest I can just enlarge the environment to explore and find keys.

First of all from the previous test I figured out that a plan is needed before continuing work with lights and further with puzzles and scripts.

I developed schemes for the current level I’ll be developing now and additional areas according to my scheme from the thesis.

As you can see, I have separate schemes for the intended route (but the player is still free to explore the whole area), corresponding light path and what tasks to complete to proceed further. (I believe that thus wayfinding can be considered as a puzzle itself, but I’m afraid that just wandering around may seem boring. So some simple puzzles will be a benefit). My focus for now is area 1. And the first thing I did is I finished modelling (as it lacked half ) and set up the ligts according to the plan.

Due to I needed to fit in parts of the whole gameplay into a small area, I adjusted area plan, so that for now it can be the game in itself. So the goal is to find 3 keys that will open the main door. In full game they will be distributed over all 3 areas, 1 key per area. But for now I’ll distribute them across just one area, but different parts of it. Aslo I had to adjust puzzle purpose. In full game the puzzle will open a door to another big area, but for now it will just unblock access to the other half of the same area.

Later the puzzle will open this door to a sub-level:

Start scripting

First I decided to make the main mechanics work: trigger 3 keys to open the main door and the cube puzzle.

Keys script was made pretty fast and easy, where I finally learnt how to reference variables from one script in the other one. I also connected it with door animations, which works as planned. So now I can place the keys anywhere across the map, and the mechanics will work.

There might be one feature under the question. If I don’t manage to add the rest of the emvironment to the same scene, I might have to learn how to save the data with scene change. Thus I managed to optimize lightmap generation, so I hope that scene change will not be needed.

Secondly, the puzzle mechanics, which requires player to trigger correct cubes to open the door. Player is able to activate and deactivate cubes (it changes colour) on collision. And though this script seemed easy, I had problems that required me reserching the topic for a couple of hours. But eventually the cube worked as needed:

I wanted light to be the hint to solve the puzzle, so initial idea was to have a light source attached to each of the cubes. The right ones will have a greater intensity, so by walking near each of them, player will understand which ones to trigger. And with that idea I completed the whole puzzle (which took a lot more time than it can seem. With solving all bugs it took around 12 hours).

But I still didn’t like the look of it, and after some time I realized that I can just use the surrounding lights as a hint. So now the right ones are those that are touched by the light strains from the window. It might be less obvious, but when I develop the concept of light showing where to go and what to do throughout the game, this will be more obvious.

The rest of work was to create light for the second half of the area (what I had to do twice due to a glitch when reimporting the model + unity freezes after a couple of times regenerating lightmaps) as well as constant testing and fixing minor bugs.

I aslo tried introducing cut scenes when puzzle is solved and all keys being triggered to show feedback to player and hint on what to do next. I learnt ot animate and switch cameras (and might need to learn Cinemachine for future purposes). Overal a lot of minor technical work that consumed a lot of time.

UI

Lastly, the UI is needed like main menu, pause menu etc., which took me another day in total. I wanted to make the menu with nice animations, pop up windows etc. As usual there were tons of minor bugs to solve like lock/unlock cursor (especially in pause menu), unclickable buttons, keys triggering windows or animations at incorrect times, but most of that was solved successfully. Finally I made some work with audio, just background sounds, separate for menu and game, game sound keeps playing with scene change and stops in the menu (which was also a trick to do). Final reasult you can see below:

To Sum up:

I just want to make a lits of the new things I learnt during this small amount of time:

reference variables from another script

working with mesh renderer component and switching materials on collision

activating stuff after puzzle is complete

DontDestroyOnLoad command and ways to access such objects via script

press any key command

pause menu

lock/unlock cursor

raycasting targets

pop up UI elements

and fast search for answers to coding questions

What’s next

I rushed this buld so much to make a proper playtest this week what will tell me, where to go further. This is already can be considered as a very small, but complete project, so at least I’m not panicking that I have nothing to show for thhe assignment. If playtest doesn’t reveal major problems, I’ll spend the rest of the time adding the rest of the area (what will be more interesting for orientation and key finding) and some more simple puzzles based on the scripts I already have. I’m also thinking to adding some kind of story or comments that player can also find if they explore the area more. Something like the Begginer’s guide. Something a bit philosophical or conceptual. But that will be after I complete the main part and some time is left.

Today we did some playtesting (just people trying to navigate the space, nothing was implemented there yet) and I want to point out some things I have to consider in future development.

1. The light navigation works ok. Testers were attracted to the correct places. Thus I might want to verbally give a hint in the beginning to pay attention to lighting. But even given no instructions testers walked quite intuitively.
2. The area was admitted to look brutalist, which is one of my goals.
3. I should think through what is player supposed to do and where to go.
4. Concentrate navigation lights more to the eye level, as from players camera it looks not as I expected.
5. Might consider brightening up the area. But that depends on the light plan I’m yet to make.
6. Change or alter controller
7. Fill the area with details

Time to reflect of the hard path to setting up lighting for the project. I started with Blender, where I set the lights and was going to import them together with the model. I was aware that it’s possible to do, so I decided that Blender tools were more comfortable for lighting as well than in Unity. I also looked at some tips from BlenderGuru, whose tutorials helped me start with Blender and donut modelling.

I liked the result and confidently imported it to Unity, hoping to get the same lighting result. But it all went wrong. I got horribly looking lightmaps, and each time I got a different result.

It started off as just pure light or pure shadows, which might be useful in some particular case, but totally ruined my idea. I tried adjusting light settings and every time the lightmap was rejenerated, which took about 15 minutes each time.

I was altering the settings dozens of times, reimported the prefab and changed its settings, cleared lightmap data and regenerated again which took time to wait, and nothing worked. I was guided with several tutorials, with this one as the base:

This one helped a great deal to make much better settings, but didn’t solve the lighting problem. I rewatched it, rewatched several more basic tutorials while altering the parameters here and there and again regenerating the map. Nothing worked either. Then I tried unpacking the prefab and taking out lights from it, which produced a little bit better result, that was still useless. (I didn’t even document it, so frustrated with the situatuon I was)

Fail with implementing lighting meant the whole concept of the FMP had to be changed and changed quickly. I decided to leave the problem at the back of my mind for now and think, how the game implementation can be changed.

To switch the game to 2D I had two options in mind ,whith the second one trying to make it a false 3D. The positive side is that player could still explore the area, but the experience won’t be full as they won’t be able to fully control the way they look around and orientate. It will be me, who will define angles or areas that the player will see. Which also a bit ruins the whole idea, but at least it is something.

I decided to take a final attempt to fix the lighting and unexpectedly made huge progress. It turned out that Unity doesn’t work with imported lighting correctly. Though I didn’t like the idea to recreate the already set up lighting from scratch, but when I substituted Blender lights with Unity ones and it actually worked! The lightmap generated pretty well with all the key lighting I needed looking very close to what’s expected.

That means I continue to work with the original idea and since technical part is resolved for now, I need to do some thorough planning on the lighting and what I want the player to do, where to guide and for what purpose. Because while I was setting up the main lights I came to conclusion that I’m not sure where I want to guide the player, so the guidance can be confusing for now. But I plan to implement some simple puzzles like find and trigger to get to another location. Here’s how the area looks now: