Quietude - Devlog 3

Hi again Quietude followers!

This is Rahad here, the gameplayer programmer and level designer for Quietude!
Myself and the artists are currently at the end of  our production phase and we are looking to finish up any remaining core developing area of our project! Let's get you updated on where we are and how we plan to go forward with Quietude as we head into our post-production phase.

Artists

Maja and Abbey have been super hard at work completing their assets and working on getting them into the engine for me to scatter around the level or place strategically. There are plenty of photos attached to this development log, showcase what they've been up to in the mean time. We have a fully finished assets that are already in engine, like the deer skull and the watchtower (check them out!) 

They tried really hard to get the aesthetics and looks just right when you account for the dark environment and the fog. My criticism is that they look amazing!

Anyways, onto the Programmer

I have been experimenting with the design of the level a little bit and added a road with downhill slope that leads you to the first Point of Interest, being the campfire area. This area is littered with both sourced, and assets that the artists created. Here is the overview of the area!

We apologise if the images seem really blown out, or too bright. To take the images without tweaking the lighting settings on the engine, I had to turn on the auto exposure function within the engine.  I developed a handful of puzzles but some of them had a few problems so I had to end up scrapping them in the end. Let's talk about that.

One of the puzzles was a pressure plate puzzle where the player must stand on the pressure plates on a specific order in order to open a door. This puzzle did not use arrays, which meant that there was no efficient way to check if the player had stood on the pressure plate and check if it was the wrong code. Because the data was not stored in an array, and instead in a single variable using basic set and get nodes within the blueprint editor, it meant that there was no way to clear any data if the player had inputted the wrong code. Because of this, this caused some playtesters to become confused as to why the correct code was not working, as the code stated that 4 inputs are necessary for the code to be cleared but would also index the input that was used to clear the code.  As a result of this, i created a more responsive and interactive puzzle that naturally accommodates a level of user feedback. It is a light puzzle where the player must get the correct color combination to open a door. Since the level is quite dark, it nicely complements the environment with some coloured reflections as well as waypoints them towards uncompleted or completed areas (if they see coloured lights on a wall it means that they have already interacted wiht the puzzle already and should turn around to progress the other way). 

This method of puzzle implementation was far better from my peers as they were able to solve the puzzle with little to no confusion, when the puzzle was deliberately made very easy. These puzzles have been scattered through out 2 of the 4 POI's in the level, as a method of gatekeeping the player from different areas of the level and keeping them centered throughout the critical path of the level. Lanterns have also been placed throughout the level to assist in keeping the player within the critical path, although, players should not be afraid to explore in other areas where lights are not guiding them.  

There is also a quick flyby of the level as it stands right now! Here it is: