Based on the math I had previously worked out, I implemented it in blueprints, but found that the ball was moving towards my hand instead of a distance of l away from my hand. I added a hacky workaround (hacky in the sense that I don't know why it's necessary just yet), where I added l to the position the ball whips to.
In addition, I also added an additional launching force to the ball when it is released, which helps increase the pace of the game. The direction of this force applied is somewhere between the ball's current velocity and the direction of the player's hand when they release, depending on how fast the player is swinging their arm. Faster swinging motions result in the force being closer to the hand's direction than the ball's current velocity.
In addition, as a group on Saturday, we created a title scene that will be used to transfer the player to the game arena. Unfortunately, the computers in the lab still didn't have Visual Studio's Extensibility Tools Update installed, and it seemed our admin privileges were revoked, so we could not reinstall it. We therefore were unable to actually implement the menus.
We did however manage to get some of the assets imported into the project.
I also spent a few hours trying to decouple the logic of the whip from the MotionControllerPawn but ran into issues.
My thought was to have a somewhat-abstract Input class (perhaps it could simply be an Interface) that would have AIInput and MotionControllerInput as subclasses, then make the Whip component *have an* Input component. Then my plan was to add two of these to the MotionControllerPawn. I'd pass the Left Controller in to the first Whip component (to its MotionControllerInput), then the Right Controller into the other component. Since each would be responsible for its own polling input (pulling from the controller passed to it), it should work for both hands.
Then, the AIInput could implement all of the methods needed by the Input (like GetForwardVector, GetLocation, etc.), and they'd essentially share the same interface.
I'm having difficulties setting this up though. I don't see any way to make one Actor *have* another Actor. It can have an ActorComponent though (aside from storing it in a variable - maybe that's the way, which would unfortunately require polling from within whatever is holding the whip). When I try to make the Whip an ActorComponent, I don't see any way to make that component *have a* Spline Component or a Spline Mesh Component, as used right now. So I could make the Whip an Actor instead, then I could make it have these components, but then since I can't make an Actor *have an* Actor, I can't make the MotionControllerPawn have Whip components.
Maybe it'd be easier for now to keep the whip logic coupled with the MotionControllerPawn, then the AI's Actor would essentially duplicate the code. I don't like that solution, but I don't know of any better way. Looking at the PlayerController and AIController, they may be helpful, but I doubt it'd be worth the time investment to learn about them since there's still the issue of tying it with Spline Meshes and attaching it to other Actors.
The current progress is shown below, including the newly created force on the whip.
Time spent: Total: ~15 hours
6 hours - Implementing Resistance to Bending force
4 hours - Creating title scene
3 hours - Trying to decouple the Gravity Beam / Whip from the MotionControllerPawn
2 hours - Rearranging some logic for imported assets
- Our gravity beam feels good enough for an Alpha now.
- Unable to successfully decouple the whip mechanics from the motion controller so far. May need to just copy whip logic to the AI Actor temporarily.
- Still using Git, since I haven't been able to find a free SVN hosting site with enough storage space, while also allowing 10 people to have access.