Week two and things are kicking off. Getting right into it, Jack and I made some massive progress on our fixed constraint rope system.

As you can see here, the rope actually works like a rope instead of a weird stretchy thing. We managed to get this working after we had a meeting with our old studio lecturer Greg, who gave us feedback on what we were doing incorrectly.

Here’s a summary of what was incorrect with the above gif:

• Each segment was being updated instead of the entire rope

This meant that each link only cared about the link next to it, meaning the value wasn’t a good representation of where it should be.

• The rope wasn’t being iterated multiple times a frame

To increase the “stiffness” of the fixed constraint, its required to recheck the values multiple times before applying the final value. The more iterations, the less elastic the rope would be. As we weren’t doing ANY additional iterations, the rope was just a long stretchy noodle.

• Each segment was adding force

Because each segment was using a physics addforce function, it wouldn’t add enough power to the movement to get to where it needed to be. As a result, it would get further and further behind, and never connect properly. We changed this by manually overriding the velocity of the rope segments so that the transition was much more snappier.

So by re-writing the code (for the third time) on the fixed constraint system, we ended up with the first gif. However, you can see that EHU (the yellow capsule) is only moving from one player, while the other players seem to have their own rope. This is because at the time of taking the footage, each rope was being updated one at a time. And as the player and EHU need to be connected and updated like a rope segement, they are included in the lists of each rope. However, this means that EHU’s position gets updated by EVERY rope, and as a result, only useses that last ropes value. We plan on fixing this by updating each rope and then adding the position EHU is supposed to be on each rope, and then normalising that value. This should hopefully create a position that forces EHU to move in the direction with the strongest pull on the rope.

 

The other thing I worked on this week was implementing controller handling for the players. By creating a script that checks for the controller input, I can then allocate a player to each controller based on who presses the A button first.

if (InputControl.GetButtonDown(Controls.buttons.P1A))//check for the first controller
{
if (!player1Control)//if the controller already has a person, ignore the input
{
player1Control = true;//this controller can no longer get a player
players[index].AllocateControl(Controls.buttons.P1A);//send this controller to the player to allocate on the player
++index;//next input will effect the next player
LevelController.instance.currPlayers = index;//tell level manager how many players we are
}
}

And in the player control script we can then set the controller inputs to the movements and inputs:

if (_APress == Controls.buttons.P1A)//check what controller was passed in
{
//apply controls
jumpKey = Controls.buttons.P1A;
breakKey = Controls.buttons.P1B;
horizAxis = Controls.axes.P1LeftX;
vertAxis = Controls.axes.P1LeftY;
triggerAxis = Controls.axes.P1Triggers;

Debug.Log(“Controller 1 given to ” + ps.playerNum);
}

This means that when we set up a lobby system, we now don’t have to worry about if a controller is being read as player 4, and there’s only three players. This system ensures that each player will be able to player without screwing with the controllers. This is still a basic system however, as I’ll need to be checking if controllers are unplugged or changed around. It’s also not flexible at all, as if someone drops out in the lobby, and the first player is then made available, then there’s currently no way to fill that position first. I’ll probably be checking a list of available players instead of using an index to fix this.