H!'m noo(b)! I will obviously be taking a stab at this when I get into trying the C3 engine after going through some of the Beginner tutorial mats. And if I figure it out for myself, I will post / update this OP with the method I utilize.
However, curiosity has the better of me and I am wondering: Just how difficult is this likely to be to figure out for a shiny noob?
The entire movement system for the initial game I am getting into C3 to prototype, hinges on multiple closed, looping paths being set on the map, with the player obj. moving along one until control input will alter it to another. And another, and another. So this is very important for me to figure out sooner, rather than later.
I also foresee a potential problem with the transition of the player obj. from one path to another. Paths are node based, correct? So if/when the play.obj. is redirected to another path while it is already moving to a next waypoint on the previous path, it will leave the previous path easily, but it will then seek a specific waypoint on the new path...correct?
I need the play.obj. to maintain its speed and general, original direction and 'split the difference' between momentum and redirecting to engage the new path, but to also join the new path at its nearest line of movement. Not to head for the nearest waypoint on the new path, in the same direction.
I know this is probably an unusual movement mechanic to wrap one's head around, but I think ^all that^ nicely explains what I want to do…?
If You tell me it will be very difficult to figure out or CPU-intensive to utilize, then I should obviously consider any alternative method(s) to achieve the same player movement mechanic. I have another thought already…
Solid - transparent - slots/guides. I think they will be obj. heavy, though. They would need to be comprised of segments, and on both sides of the player path, to create bounding. And once the control input to shift to the one side(or the other) is triggered, the next bounding segment on that side would have to be deactivated, so that the play.obj. could slip free, in the desired direction. Furthermore, the next bounding loop would need the correct segment(s) deactivated to receive/allow in the play.obj. Or, the entirety of the new bounding loop would have to be activated as soon as the play.obj. moves 'in bounds'.
The only other solution I can think of is pseudo-/magnetism. The play.obj. will have to be attracted to invisible obj.s which are de-/activated, based upon both relative speed & proximity parameters that will have to be set. Is a magnetism effect a standard C3 physic? *wanders off to search the forums* *pops back momentarily* Nope, nothing about "magnetism". I have a really bad feeling about this.
Anyway, Thanks for reading! Think on it, will you? ^-^' Gawd knows I'll be...