[DEV] Further work on the UI, and adding animations to the final character.

My first task of the week was re-adjusting the main menu. Wiktoria finished a detailed model of the Ocrait this week. I then changed to main menu, to incorporate the new model into the UI. I additionally made it bob and rotate, to add some life to it. To achieve this effect the canvas render mode was changed to screen space – Camera (instead of overlay). By doing this, we can place objects in front of the canvas (relative to the camera). In addition to adding the Ocrait, the buttons were also slightly altered. All the textures, were replaced by sprites, using slightly updated buttons.Bobbing_Ocrait.gif

Another task bestowed upon me this week, was to try and get the new characters animations ready. Most of the animations are operational, but the character is not yet game ready, as some animations still need to be finalized. Zaen is mostly complete, but his crouch animation still needs tweaking. The enemy animations are also ready, but still need to be implemented, which will likely be done during the next week.Animation03.gif

In addition to working on the main menu, I also made minor adjustments to the pause menu. The hexagonal buttons were previously unusable, but can now be selected, clicked and used. I also swapped remade all the textures into sprites. At first this might seem simple, but I had to re scale each element separately, so that it’s dimensions were a multiple of 4, to allow compression. Doing this decreased the size each texture used drastically.Week10ProgressD.PNG

Lastly this week, I updated a couple of the new UI elements. The interact pop-ups have been revamped with help from Wiktoria. Our previous pop-ups no longer matched the style used for the rest of the UI, thus this was an important, yet minor update. Now when the player cannot teleport (because the beacon was placed too far away), a pop-up will appear, alerting the player that the beacon is out of range.

Tex_InteractKeysTex_InteractXboxTex_RangePopUp

[DEV] Toon shader, and other upgrades

This week my main objective, was to get a decent toon shader working. The toon shader will be used for the main character, Zaen, and the enemy guards. The shader currently supports a diffuse and an emissive texture. In addition there are a couple of settings that can be tweaked to get the correct look. The diffuse color tints the material in that colour, whilst the levels parameter gives control over how many shading levels there should be. Half-Lambert toggles whether the material should have Half-Lambert diffuse shading or Lambert diffuse shading. To change the width of the stylized outline, you can use the slider. The outline can be toggled between either a fixed color, set by the user, or a darker version of the diffuse color. If the darker version is selected, the user can also change how much darker the color has to be. The emissive texture, and color, works just like with the standard shader.

ToonShader

ToonShaderEditor


The lasers also got reworked this week. Using a line renderer with additive blending, I managed to create the effect bellow. Also on the points of the laser, I placed a small particles effect, to give the look as if the laser were hitting the end, and not just going through it. The beam itself also using a simple vertical linear gradient, so that it has a rounder and smoother look.

LaserBeams

Besides the laser beams being reworked, the pattern trap at the end of the second level, was also adjusted. Previously it was unbeatable, because even when the lasers were no longer hitting the player, they would still get caught. The root cause was simple, the lasers switched on before having moved to their new location. One of the adjustments to the script was that the lasers now smoothly move to their new position, unlike previously where they would snap to their new locations. This adjustment alone could have already fixed the problem. Other, less visible changes were also made to the script.

LaserPattern


The smallest, but not least important change of the week on my side, was adding the auto save pop-up icon. It’s main purpose is to alert the player, that their current progress in the level has been saved. In other words, whenever the player reaches a checkpoint the game stores their progress, and the icon serves to alert the player of this. The icon also blinks, to draw the player’s attention, in case it wasn’t already clear enough.

AutosaveIcon

[DEV] Off-screen indicators, and cleaning assets

Off-screen Indicator:

This week was a busy week. I had decided to eventually remove the old sound indicator. It didn’t work as intended, and was an inaccurate way of displaying the distance the sound would travel. Instead, I have made an arrow indicator which points to the guards. The indicator only shows when the guard is not on the screen, and when the guard is nearby. When the guard is busy doing it’s normal duty, the indicator remains it’s neutral cyan color, but when the guard has heard you and is inspecting the sound you made, the marker turns red to alert the player. In addition to the marker being red, it will remain on the player’s screen, until the guard is no longer inspecting the noise the player made. The indicator itself was also designed by myself, using Photoshop. This was my main task this week, and even though it might seem like a simple element, I discovered that implementing this was not.


Pop-Up manager, re-invented:

The first change of the week was to the pop up manager. Before the changes the manager, was made very quickly and in theory could only support one pop up at a time. This week I made a change to this. The manager now stores a dictionary of pop ups. These pop ups consist of the pop ups name, the UI element responsible of drawing the pop up, the texture that should be shown when a controller is connected, and the texture that should be shown when no controller is connected. When the pop up needs to be used, all that has to be given to the manager is the name of the pop up. The manager will the decide which texture to use and enable the pop up object showing that texture. This also applies to hiding the pop up.

PopUpManager


Other small fixes:

Last week I changed the Ocrait manager, but this change brought an unforeseen bug, which meant that after the player was caught the first time, all the Ocraits would no longer reload. After some thorough searching, it was revealed that a bool was set incorrectly. The new manager caused a lot of confusion, as it did not have a logical way of working with the Ocraits, leaving me to once again re-invent the manager. The re-invented manager works as should, and has not brought forward any new bugs. In addition to change the manager, I made a general script for devices, that use the Ocraits, instead of having one script per device type.

Ocrait

The enemy manager was also subject to a small change, as it now holds the texture used by all the field of view objects. This removes the need for each field of view object to store it’s own texture, as it can retrieve it from the manager. This small change decreases the possibility of making a mistake, when changing this texture, and also makes the task less tedious.


Correcting scale, unwrapping, and texturing:

Lastly, the task that used the most of my time this week. As Saskia mentioned, I helped out with finalizing a couple of models . I realized a lot of assets we used were not scaled properly, and thus decided to fix this, with the help of Saskia. In addition to correcting the scale, a lot of objects still had to be textured, thus first unwrapped. By texturing the props we reduce the number of materials the prop uses, and thus reduce the batch count of our scenes. This optimization can make a great difference, as we have large scenes, that re-use a lot of props. In addition with the scaling being correct, the lighting in our scenes will be more correct.

[DEV] New ocrait, and subtle changes to scripts

This week my first task was completing the change to the field of view scripts, namely the rotating cameras. Last week the camera “on rails” got the ability to charge up before recognizing the player character. This week the rotating camera has also been given this ability. In addition to this, the rotating camera also got a small editor script to display how it pivots. I also modified the model of the camera this week. By unwrapping the model, it now uses only one material, reducing the batch count. I also exported the camera, in two separate pieces, so that only the body will rotate, and not the base.

RotatingCameraCharge


The ocrait we had in previous versions was plain and boring. This week I made the ocrait look somewhat more interesting, using a combination of particle effects.

Ocrait

New ocrait

From this week on ocraits can also be taken out of powered devices, and re-used in other ones.

TakingOutOcrait

Inserting and removing ocrait


Lastly, I also replaced all the emissive blocks, that were acting as lights around the level. All the blocks have been replaced with an light mesh.

Light

New light mesh

[DEV] Guard animation, and further development on the FOV.

This week I worked on making an animated guard. At the moment it is just a placeholder, which will later on be replaced by the final model. The guards patrol, the levels, and when they hear something they stop to listen. They briefly look around, and then run to the origin of the noise. If they find nothing, they return to their patrol. If they find the player, the level restarts at the last checkpoint.

Week10ProgressA

I also worked further on enhancing the field of view. It now using a custom editor script to easily change parameters in the editor, whilst also visualizing the results clearly. The field of view itself has also changed. Now it changes color based on how near the player is to being detected by that particular system. For example, the guards now have a blue cone, which means they are doing their regular routine. Yellow means that they are inspect a suspicious noise, and red means that the player has been spotted.

Week10ProgressB

Week10ProgressC

The camera’s work similarly. They interpolate between theses colors to represent how far the camera is, at recognizing the player. This delay also gives the player the chance hide, so that the camera can reset. Not all the camera’s have yet been implemented with this new feature yet. Only the cameras on rails have been implemented thus far. In addition to that effect, the camera also pauses if the player has been spotted (as if it wants to take a clearer look).Week10ProgressE

Lastly I also quickly implemented two post-processing effects to the in-game menu. These effects are namely Blur, and vignette, and are used to draw less attention to the scene, and more attention to the menu.

Week10ProgressD

[DEV] Sound Detection and other minor adjustments

This week my main focus was working on the sound detection mechanic of the game. When the player runs, walks, or sneaks, they make noise. Also the faster the player is moving, the more noise they make (for example, sprinting makes more noise than walking or sneaking). The range of this noise is  shown by the sound indicator underneath the player. I also adjusted the look of this indicator, as some feedback mentioned that it was too distracting. The indicator no longer expands, but remains still and pulses. In addition I toned down it’s brightness as well. Below in the GIF you can see how the player alerts a guard by generating too much noise. When the guard hears the noise, it changes it’s path to inspect the noise’s origin.Week9Progress


I also experimented with editor scripts this week. The old path editor has now been replaced by a custom editor. This editor, no longer requires people to use game objects as way points. It uses UI elements to add and remove way points. Theses way points are stored in an array of Vector 3’s, and the path is then visualized in the scene. The points also have handles, allowing them to be easily modified within the scene as well. Arrow heads are also used to display the direction the guard will the path in.

Week9Progress_PathEditor

Week9Progress_PathEditorScene


In addition to the path editor script, I also added a few other smaller scripts, which might make some tedious task easier and more efficient. I also continued trying to find areas where we could further optimize our game. One of which was decreasing the batch count again. This time, I unwrapped the pillar, and made it use a single material, instead of two. This might sound minor, but when an object uses more than one material, it apparently can’t be batched, thus by unwrapping and texturing the object, this was resolved. Just doing this decreased the batch count by another 100 batches. This might not seem like a lot, but some of our objects use up to 6 materials, thus by unwrapping these objects and texturing them, the batch count could once again drop significantly. Another issue mentioned before was the game crashing. This week I might have found another cause of this problem, instead of the batch count. The sound indicator rendered a new render texture every time “OnRenderImage” is called, and was created in video memory, but this was never released. After running the game for an extended period, my computer’s used memory started to escalate, until it reached it’s limit (literally 100%). Releasing the render texture from video memory resolved this problem, and might also have resolved the problem of the game crashing.

[DEV] Decreasing batch count

This week I tried to resolve our largest issue at the moment, performance. After profiling the project, we discovered that the game was having severe issues during the rendering stages. When examining further, I noticed that our batch count would increase to above 3000 batches. My first thought was that this was caused by objects using more than one material, thus not batching properly, but this was not the case. Later I found the root cause to these high figures. All the lights ( over 50 lights ) in our current scene, were being rendered real time. To resolve this, all the lights that didn’t require being real time were changed to static and baked. This solution alone dropped the batch count from 3000+ batches to just more than 700.

Week8Progress

Even though this is an awesome find, I’m not 100% sure if it was the cause to our game crashing. Unfortunately I cannot find out if this solved the issue of the game crashes, as my team’s computers never actually experienced this crash. The crash came to our knowledge from the feedback session, and I will need to verify with those people if my solution fixed the problem. This might not have solved the problem, but I gained new knowledge on the topic batching ( which I had no awareness of prior to the problem ) that can guide me in my future work. So even if the crashing hasn’t stopped, all my research would not have been in vain.