Devlog Week 11

Liam - Programming

Scroll speed

Following on from last week, I finished implementing the rotation of the gears on the blunderbuss. Now they respond to input from the scroll wheel and spin at about the same speed by default.

Next was implementing the speed of the spinning gears to change based on the speed of the objects currently being connected. This is done by taking the velocities of both objects and get their average, then adjust the resulting value by a certain amount of scaling so it feels good. This means that heavier objects will result in the scrolling feeling more sluggish, while lighter ones will feel quicker.

Overlay Camera

Previously the blunderbuss would stick through objects if the player got too close to them. To fix this, the blunderbuss needed to be rendered on a seperate layer and then added to the main render afterwards, while being excluded from the main render. This was achieved using a second "overlay" camera that would only render objects on the "overlay" layer, sticking the blunderbuss on that layer, and excluding that layer from the being rendered by the main camera. Finally, this overlay camera is added to the main camera's "stack" of overlay cameras.

Pressure Plate V3

So, pressure plate v2 didn't work on moving physics based boxes, due to being kinematic. V3 is now entirely non-physical, and only uses a single trigger. While is isn't as satisfyingly physical, it now plays ball when joined onto other objects.

Death Plane for Objects

The death plane previously only triggered if the player went below it, resetting the level. With more physics objects in puzzles that might fall off the stage, we want to also allow for resetting these objects so we don't soft-lock the player.

To accomplish this, the upon the scene loading the death plane finds all objects with physics that have no parent objects with physics. It then copies them and all of their child physics objects along with their starting positions and rotations. Upon any object within these groups hitting the death plane, every object within the group is immediately moved back to their origin points with all velocity removed.

Below we see this happening with the new V3 pressure plates.

At some point, I would like to add a nice effect to this, along with some sort of sound to show the player it had happened, but it's serviceable for now.

Adam - Programming

This week was very mostly uneventful. The primary focus was for me to optimize some aspects of the code and fix any bugs that Ethan found while setting up the levels. All of the issues we encountered were very simple fixes, usually something not being connected properly or a bit of logic not working as intended. For the most part many of these things were fixed.

There were some issues with the selection effect, especially when used with the new models that Aiden created. For some reason the effect would not cover the whole object so it could be almost impossible to determine whether or not an object was selected.

I tried a few methods to fix this. The first was to try and get the effect to act as the last layer to be drawn on objects. This unfortunately had no effect. The solution was instated to give every object that can be selected a clone that has the same shape and is a little bit bigger. Whenever the player selects something it is turned on and given the correct colour. This is good because for something like a door that has a unique shape the object can be made to share that shape very easily.

Selection effect on doors

Enemy Stuff

I started some preliminary work on the enemies as well. I had already learnt how to make enemies that chase the player using the nav mesh during the portfolio tasks so was able to set that up quickly. If I had an enemy model I would probably have to make adjustments to things like turn speed and chase speed to make it look good but the base work is there for now.

As the player cannot technically be killed the effect we wanted them to have was to push the player about and hinder their progress. This effect was actually somewhat tricky to implement as the generic unity character controller we use is difficult to apply physics to. Ideally we could just add force to the player in the direction they get pushed but the character controller doesn't work that way. Luckily I found a ten year old solution online that gives the effect we want.

https://answers.unity.com/questions/242648/force-on-character-controller-knockba...

The end result

Ethan - Level Design

This week, I can finally announce the completion of level 3, our electricity-themed level.  After the two previous levels which introduced the player to basic mechanics fairly quickly, I wanted level 3 to be more open-ended and really showcase the variety of puzzle possibilities that our mechanics are capable of.  Our goal was to have this level playable by the end of this week so that it can be included in a build that will be play-tested by other students in our class.  Various bugs hindered the development of this level so the implementation currently isn't as polished as I'd like it to be, but nonetheless a relatively functional level has been made.  Below is the layout of this new, larger level:

To break the level down: the small blue dots are batteries, which must be brought over to power spheres (the larger blue circles) to activate a bridge.  The yellow squares show where the checkpoints are.  The black and purple squares are moving platforms which are used to transport batteries across large gaps.  Currently, the size of the power sphere indicates the required charge: the smallest needs one battery, medium needs two, and the large final sphere needs four, so players will be challenged to work out how to collect every battery at the end of the level.

By combining various mechanics that Adam and Liam had made, I was able to create some other interesting interactions that I thought were appropriate for this electric-themed level, such as activating/deactivating rotating platforms.  

Some visual changes were also made: the floor now uses a different texture made by Aiden, along with different settings on my customisable shader, to better differentiate it from the connectable objects in the scene.

Aiden - Modelling

Power Sphere

As what was promised from last week, this is the power sphere that could be activated by dropping a battery cell within its vicinity. If there is not a battery in the immediate area, the power sphere will have the appearance of a solid, greyish icosphere.

And once it identifies the presence of a battery cell source within the predetermined area, it will light up and transform into a power source in order to assist in solving puzzle related to the usage of electric device.

Floating Platform - Updated Graphics

The floating platform that assists the player and/or item in getting past barriers has had their visuals improved so that they are now more appealing to the eye.

Connecting Cube - Updated Graphics

The connecting cube, which helps player solve puzzles, has also been redesigned with new images to go with the game's overall tone of darkness and machinery. All of this is thanks to Ethan's feedback provided during one of our discussion.

Floor Texture

A fresh new look for our floor's textured surface. It has the potential to provide additional variation to the overall concept and aesthetics of the game.

The texture can be further modified with the help of Shader Graph within Unity.

Thank you for tuning in with our DevLog this week!

Hope you have a great day and see you guys in the following update!