So Week 1 of final project has come and gone, and so starts the insanity.

For those who don’t know, I jumped into the team Tiny Sail Games last trimester, as the Final Project team I had planned on working with unexpectedly dissolved. The game I’m working on now is GIANTS (Guests in a new time and Space), and I spent two weeks of my holiday familiarising myself with the project and how everything would go to plan. In addition I was given the Lead Programmer due to my work on the New Intelligence App (find out more about that here). In the leadup to last week, I spent a lot of time with Jack, one of our other programmers, in developing the technical design side of things so we could hit the ground running.

On Friday I first started off by importing the InputControl settings that was used in the prototype for GIANTS. Because the button mapping was already set up, it was a breeze to implement, and simply required allocating the controls to the specific player, and to make the movement based off camera position instead of local position. I could do this by simply multiplying the input float by the cameras forward and right transforms.

Vector3 dir = vertInput * Camera.main.transform.forward + horizInput * Camera.main.transform.right;

Next, I started implementing a basic version of Tethering.

The core mechanic of GIANTS is that there are 4 players that can connect to this mysterious robot named EHU. When “tethering” to the robot, they can pull EHU around. However, if they have a crystal, they can change their size to be able to solve the puzzles.

The Designers wanted the following:

• Players tether automatically when close enough
• If they carry a crystal, they can consume it while near EHU to change size
• The tether distance has a max

So what I did was create an enum to track what the player is holding, so we can easily check if they’re holding a crystal. Then the player does several distance checks to see if they need to be tethered or not.

if (Vector3.SqrMagnitude(offset) < EHURopeDist * EHURopeDist)//if player is close enough
{
if (resetDist)//this is needed so the player doesn't continuously tether while in radius
{
isTethered = EHUinst.CreateTether(gameObject);//tell EHU to attempt tether
resetDist = false;//don't tether again while in radius

if (isTethered)
Debug.Log("Tether Successful");//if returned true, tether was successful
}
}

Next, I needed to check if the player was close enough to use a crystal to change their size. This was far less cpu intensive, as we only needed to check when the player pressed the interact button.

public void InteractObject()
{
case Holding.e_crystalShrink:
if (isTethered)
{
changeSize = TestCrystalDistance();//another distance test (smaller)
if (changeSize)
ApplyValue(shrunkenValues);//change size if they’re close enough
}
break;

…

This was the result:

The image shows that you can break the tether, while still in the circle, but will have to leave the zone to become tethered again, and it also shows the player shrinking when they press the activate button near EHU.

However, this doesn’t have the “rope tether” that the designers want yet. Jack was put in charge of creating a fixed constraint system, but unfortunately, the start of the flu season hit him hard, and he didn’t finalise the code. However, I could still create the system that creates the fixed constraint system as a rope.

Now when EHU creates a tether to the player, we can insert a function that creates the rope objects. It was simply a matter of instantiating the number of rope segments needed in a for loop, and telling each segment to connect to the previous one. The only checks I needed to do in this process was for the first and last segments. The first one connects to EHU itself, and the last segment needs to tell the player to connect to the final part.

I also used a neat bit of code created by our other programmer Pritish, (who prototyped the initial tether system) to place each segment in between EHU and the player.

Vector3 pos = ((_player.transform.position – transform.position) / numofSegments) * index + transform.position;

This nicely places each segment in an equal space, meaning the rope never gets dumped in one spot.

This was the result:

While the fixed constraint system clearly isn’t working in any form like a rope, its making an attempt to keep all the segments together in a “ropey” kind of fashion.

The last thing I did before moving onto the next part of the project was removing that temp line renderer from the player to EHU, and make the rope segments draw lines between each other. When we reach Alpha, we can change those bright pink noodles into something cool and “laser like”

In the next week, I plan on implementing 4 player controller handlers, start on a level loading system, and get the team started on the puzzle systems.