I’ve mainly been working on two things at the moment, which is coding the throwing for the last puzzle and a proper/pretty respawning process. Both are not 100% polished yet, but they work, and I’m confident that they won’t make any trouble implementing.
For the throwing we decided on using a kind of gauge that decides the angle, so the player will need a mixture of planning and timing skills to throw the m&m in the right angle. Here’s the result first:
Things that are still TODO with this mechanic:
-limit throwing speed (rof) -finetune positioning of angle-gauge -use proper animation of Pan -how to leave the throwing state and the rest of the puzzle itself, the mentos stalactites, platforms and fountains!
The throwing mechanic mainly consists of two pieces of code, the first in the “PlayerInteractScript”, and the second in a “ThrowableScript”. As well as an animation for the red “Aimer” line to bob up and down, and a short animation for the m&ms to shatter.
Below is the relevant code from the PlayerInteractScript:
There are two interactions that deal with the throwing. The first is for entering the throwing state, which currently just starts the “Aimer” animation and enables the second interaction. The second interaction does the actual throwing. For this it uses the transform.positions of two objects which I manually placed at the beginning and the end of the “Aimer” line, subtracts one from the other, and uses the resulting vector to provide the direction for the throw, which uses normal Unity 2D Physics.
Next is the “ThrowableScript”. This script is attached to the m&ms that Pan throws. The Script simply detects collision with any object, and reacts accordingly. “TargetMentos” will be the object the player has to hit in order to solve the puzzle. When the m&ms hit any object (except the player) they will be triggered to enter the “Shatter” animation state, which is directly followed by the “AnimDone” state. Once in this state, the object will destroy itself through its Update() function.
We hadn’t thought much about how we would do the respawning/death animations, but anna and I suddenly got the idea of “falling down the map and then falling on respawn from above”, and Patrick later expanded on it with the idea of the blackscreen to smoothen the transition between locations. So for this I had to redo the whole death/respawn/reset-progress code AGAIN because it wouldn’t look nice as it currently was. But I managed to reduce it a fair bit. Even then, it still looks like a bit of a mess, but to me it makes the most sense like this. The code for this process is almost entirely in the “PlayerInteracScript”, and I’ll go through that in the order the program would go.
The first method is Kill(), which is called by anything that can Kill Pan (like the chocolate River), giving the ‘killing object’ to the method via constructor. This method primarily disables the level-floor’s collider causing pan to fall through the ground and sets the trigger for the camera’s ‘DeathZoomAnimation’. It also causes Pan to do a little jump, and sets the global variable deathCause.
After the CameraZoom has completed its animation it calls this function:
It instantiates the blackscreen and puts it below the player, directly below the area the camera can currently see. It also sets the deathBlackScreenInstantiated bool to true, which sets the Update() function in action next and destroys the colldier that made pan go up, causing him to fall down from now on!
Once the blackscreen has been instantiated, and now that pan is falling, the Update function will let pan fall until a certain point, where the camera only sees the blackscreen, and calls the HandleRespawn() method.
The HandleRespawn() method reenables the floor collider, so pan can land again, and calls the appropriate ResetProgress and Respawn functions (see below).
Respawn() simply relocated Pan and the blackscreen to the pre-set respawn location.
And here is the result (you may want to watch it twice, first the Game-view, then the Scene-view):