Kilan Larsen
Sprint 2
The zip-line mechanic is complete!
In order to make the zip-line, I started by getting the core features of it working and then expanded on the code to improve it over time. Here are the different mechanics of the zipline and the order in which they were built:
​
1). Setting a Line Renderer to appear from point A to point B
2). Making a trigger box that when entered will interpolate an object (or player) from point A to B
3). Ditching the trigger box and creating a method of grabbing the zip-line at any point along its length from A to B, and interpolating from that point down to the last point
4). Allowing the player to jump off the zip-line at any point, without reattaching to it immediately
5). Adding a short interpolation when grabbing the zip-line, from the player to the closest point. This ensures the player does not just teleport to the zip-line
6). Increasing the speed of the zip-line over time as you slide down it
The core of the code can be seen in the Update function, which runs every frame. First, we check if the player is currently using the zip-line. If they are, then run the interpolation to slide down and check if they press the jump button to detach.
Otherwise, the player is not on the zip-line and so we will get whichever point on the zip-line is closest to the player, and then check if the player is within range to grab that point.
The most vital part to grabbing the zip-line at any point was the zipPoints[ ] array. At the start, the array stores a number of points along the zip-line equal to its total length from A to B, divided by the amount of space between each point. (ie: zip-line length 60 / spacing of 2 = 30 points). Below is a screenshot where I have spawned a red sphere at each zipPoint along the zip-line, and each sphere is the exact size at which the player will grab on if close enough. This makes it easy to see exactly where the player is able to grab onto and why you are able to grab on anywhere along the length of the zip-line.
Not everything went so smoothly though. The first major hurdle for me was actually just moving the player from point A to B through interpolation. I could move a cube down the zip-line, but the player was having issues, which I later learned was due to the nature of the default character controller I was using. I switched to using a Rigidbody based character, which helped, but I didn't have much control or understanding of it. So... I did the only logical thing and built my own character controller from scratch. Definitely a bit overkill but it helped me understand how a character controller works and gave me a lot more control of the code.
Another problem that was encountered was the simple fact that not every group member could access and edit the Unity scene. After all, Unity Teams only comes with 3 seats for our 5 members. So we agreed to pitch in to pay for 2 extra seats, and added everyone to the project.
That's more or less it for now.
Goals for Sprint 3:
- Fine tune the custom character controller
- Improve the prototype 'impact landing' effect shown below
- Create a player inventory system?