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.