#puzzlestore | Explore Tumblr posts and blogs

inb380-n9493841 · 7 years ago

Text

Puzzle Knight Development - Perspective Door Task 7 - 8 - (17/05/17)

My task for today was to complete Task 7 of the Perspective Door development. As a recap, that was to make the puzzle interactive.

The task it seemed was a massive undertaking, requiring the entirety of today to accomplish.

If I were to split up the task into different tasks they would be as follows;

Model the piece pusher

Create the piece pusher script that enables movement

Integrate the piece pusher with the puzzle pieces

This would be the end of Task 7, and I would then move on to Task 8, making this into more of a puzzle.

Task 8 would contain the following;

Make the pieces randomly relocate upon starting

Make sure the pieces don’t start outside of the puzzle

Make sure the pieces don’t collide

Alright, let’s write it out:

TASK 7 - Make the puzzle interactive

Part 1 - Model the pusher:

Fairly simple, it’s just a block with a shrunken top and beveled edges. Not too bad, I’d say a negligible amount of time went into this, about 10 minutes really.

Part 2 - Script the pusher

Scripting the pusher did take a bit of consideration. It took a long time to realize that, instead of trying to use the distance between the end point of the transform.right/forward vector to determine which side the player was on, I just needed to project the vector between the block and the player onto both of those axis, and which ever was longer would be the negative direction to push.

Then I just got the normalized version of the chosen vector and multiplied it by the scale of the block, which was 0.3 to fit with the size of the puzzle.

Part 3 - Don’t let them collide

I’m sure you could imagine why it’s important to be sure that the pieces don’t collide, then two pieces would be in the exact same location and won’t be able to be separated.

To achieve this, I used the code above to set important variables that will be used in the moving function to determine if any collisions occur.

To start with, the variable that contains all the piece pushers gets updated whenever the player or anything enters the trigger colliders attached to the piece pusher, just to be sure that I have all of them contained in each of them.

Then in the TriggerStay function, you can see the magic happen.

First it sets the previous location, in case there is clipping and it needs to be reset.

Then it sets up the vectors to test the lengths. It projects the vector between the block and the player on both the forward and the right transform vectors. It compares which one has the larger magnitude, and whichever one has the largest is the direction it chooses.

It then normalizes the chosen vector and displaces it by the block’s scale.

Right, so that’s Task 7 done, in about 5~ hours total (1200 - 1800, give or take some procrastination). Most of it was trying to figure out how to reference two separate colliders, and then realizing that I didn’t need to, that I could just project the vectors and use the longest one.

On to task 8.

TASK 8 - Make the puzzle puzzling

Part 1 - Randomise the puzzle

I did this part in two steps, first, I relocated the puzzle pieces themselves in the z axis to allow them to be resized by the PuzzleStore code, then they will spawn the block underneath them, then the block will take over.

This is the code that resets the locations of all the pieces, first it makes up a random z value for the initial position of the pieces, then it checks if there are any pieces that share that z value (I had to use the piece’s transform as opposed to another way due to the way I set up the for loop) and resets the z value accordingly.

After it makes sure that the piece falls on the vector between the cameraLocation and the doorLocation, as in, it makes certain that the pieces are in anamorphic location.

Next it it resizes the piece so that it looks right.

Finally, it sets up the block that will be pushing the piece, the next part of the randomisation is handled by the blocks.

This method is run at the tail end of the init function that sets the puzzle store and the piece it moves.

It first gets a random location from the left and right to set the block’s position, nothing fancy has to happen here, since the first part has the blocks all in the proper location, and then scrambled. They end in a line.

The second step is to move them forward and back, using largely the same technique.

Part 2 - Keep them from leaving the puzzle

As a simple way to prevent them from leaving the puzzle is to just make a border that the pieces won’t move outside of. The most obvious one was the door, if the block ended up on the outside of the door then obviously the player couldn’t move it. So if the block is outside, just move it in following the grid until it’s movable again.

Part 3 - Keep them from spawning inside one another

Now, this is where the trickiness comes in, as it is likely that with the use of randomness, one of the blocks could be colliding with another.

So, it iterates though the list of blocks to see if it collides with any of them, and if it does, it just moves the piece forwards one move, and then checks through them all once more to make sure that the next move didn’t just put it in another collider’s way. It will keep resetting until all the pieces have their own location.

That’s all, the culmination of this can be seen in this video:

youtube

TOTAL TIME SPENT: ~9 Hours

(1200 - 2300 with some procrastination)

TASK 7: ~5 Hours

TASK 8: ~4 Hours

#Puzzle Knight #week 11 #puzzles

1 note · View note

inb380-n9493841 · 8 years ago

Text

Puzzle Knight - Perspective Puzzle Development (Part 2) - (11/05/17)

Now begins the fun bit, trying to implement the functionality of the perspective door into Unity.

I’ve split up my task into 7 parts:

Lay out the puzzle pieces

Make the puzzle pieces collapse upon success

Make the camera go to a certain location, dictated by the current puzzle

Find some way to dictate whether or not a piece is in position

Write code to scale the pieces so that they are the right size in the view

Have the player interact with the button so that when they stand on it, the camera will go to the dictated location.

Make the puzzle interactive

Unfortunately, in the time I had, I could not fully complete task 7, but I managed to complete the first 6.

TASK 1 - Lay out puzzle pieces

Fairly simple, as you can see here, I have two versions of each dynamic puzzle piece, a ‘solved’ version, which is the ones attached to the door, and the ‘broken’ versions, which are the ones floating out of the door itself. I labeled all the pieces except for one, ‘Plane.001′ is the decorative door base, which I had forgotten to rename in Blender.

To finish laying out the puzzle pieces I decided to play around with the ‘CastsShadows’ property for the Mesh Renderer components of the objects. I’ve set the broken pieces to not cast shadows, which you can see in the image above.

For the ‘solved’ pieces, I made it so that the Cast Shadows variable uses the ‘Shadows Only’ variable, which makes it so that the Mesh itself is invisible, yet it still casts a shadow.

I’ve set these pieces like this so that when it will be finalized, no shadows will disappear or reappear, breaking the illusion of perspective.

TASK 2 - Make the pieces collapse upon success

This is a relatively simple task, though, I decided to deviate from the code created last week. Instead of giving each puzzle piece it’s own script, I decided to have them all allocated to a piece of memory in the PuzzleManager object, that being a class called PuzzleStore.

Here you can see the framework of the code. The GameObjects are to be set in the Unity Editor, those individual items will then be compiled into an array for ease of use. To start with, the puzzle pieces will have their shadow casting turned off if they are a broken piece, or will have their shadow casting turned to ‘Shadows Only’ if they are a solved piece.

The two methods you can see at the bottom are there for finalisation. The first one removes all of the broken pieces, and the second one makes all the puzzle pieces on the door turn back to normal. These methods will be called immediately after one another, which will be done far quicker than the human eye can perceive, causing the brain to think that the pieces are singular and that they collapsed.

TASK 3 - Make the camera go to a certain location

This required a whole lot of messing with Unity’s standard camera assets. Specifically, the Free Look Camera Asset. All this required me to do was implement a function in the Free Look Camera that modified; the target of the camera, the transforms of the pivot and camera objects, and the state of the camera clipper protector.

UpdateCameraPositions is called in Update, with the transforms = to PivotCameraTransforms (it is called as UpdateCameraPositions(pivotCameraTransforms);). This is a method designed to be used outside of the FreeCam class, to anything that has the camera’s object. If the transforms inputted into the method differs from the transforms set of the camera, then it will overwrite them.

The method seeks to make sure the transition from each transform type is as smooth as possible.

All that is required to make the UpdateCameraPositions to work correctly, is a call to UpdateTarget, and a resetting of the transforms, the transforms is a 1D array of length 2, which stores the localPositions of the Pivot, and the Camera Object.

The last if statement is used to cleanly turn the clipper back on, as I had noticed that when the clipper is activated again, it snaps the camera back, leading to an unclean camera transition.

TASK 4 - Find some way to tell if a piece is in position

This was relatively simple.

I have two empty objects that stores the transforms of the center of the door, and the position of the camera.

Each piece is exported so that the ‘root transform’ of each piece is centered so that when they are on the door, it falls on the line between the camera position and the door position.

Therefor, all I needed to do to find out if the pieces were in position and ready to collapse, is to check if their x value is the same as the line between the camera position and the door position.

Fairly simple, all this method does is iterate through the pieces and checks their x co-ordinate. This can work for now, HOWEVER, it will only work if the entire puzzle is positioned in such a way that the line between the camera location and the door location falls on a never changing x axis. This could be rectified by either using the transforms relative to the puzzle manager object, or by checking if the pieces fall on the line between the two, using a code and a math function.

The second implementation would be far superior, because then I could have many varied implementations of the puzzle with different ideas attached to them, like people frozen in mirrored dimensions or whatnot.

TASK 5 - Write code to scale the pieces

The next bit is to scale the pieces so that they look right in the positioning. For if I didn’t scale the pieces, they would look like this:

The pieces are all incorrectly scaled. When they are all scaled properly they should overlay the pieces on the door perfectly.

The code to achieve this effect is simple;

All I need to do is iterate through the puzzle pieces and reset their scale so that their sizes are directly proportional to their distance from the door. Using the value of the z position of the piece and the camera location, and the z value of the position of the doorLocation. If I divide the distance from the camera to the piece by the distance of the camera to the door, I’ll get a float number, which is between 0 and 1. This is the scale factor.

The pieces scaled look like this:

Task 6 - Move the camera when standing on the button

This was by far the hardest part of the coding experience, as it required the linking and communication of all three sectors, the Puzzle class, the ThirdPersonCharacter class, and the FreeLookCamRig object.

Essentially;

The player stands in the trigger on the button, the button has the data of the camera point stored in it.

The data of the camera point is sent to the FreeLookCameraRig, and the player is set to be looking (with this isLooking boolean)

While the player isLooking, the camera’s CameraClipping Protector is disabled and will go to the transforms outlined by the target and the ‘cameraZero’ transforms (as in, the camera will go directly to the target as opposed to hover behind it)

When the player steps off the button, the target is reset to the player, and the transforms are reset to the previously selected view point (left shoulder or right shoulder)

The camera’s clip protector is not enabled until the cameras transforms are significantly close to the transforms supplied.

My works in trying to make Task 6 function caused me to not be able to make the puzzle interactive, however, it shouldn’t be too hard to implement interactivity. I’m fairly certain I can accomplish this by next week.

All in all, this is a gif of what I have managed to accomplish this week.

Time Spent: 16 Hours

Task 1 - 0.5 Hours

Task 2 - 0.5 Hours

Task 3 - 6.5 Hours

Task 4 - 0.5 Hours

Task 5 - 1 Hours

Task 6 - 7 Hours

Task 7 - N/A

#Puzzle Knight #Week 10 #Puzzle Development

0 notes