playMaker

Author Topic: What's the economical approach to "tethering" objects? [SOLVED]  (Read 5637 times)

Designopolis

  • Playmaker Newbie
  • *
  • Posts: 6
Sorry if what follows are a barrage of what might turn out to be stupid questions (in the sense that there's some incredibly immediate resource I should have seen and missed detailing exactly this) :-[ I picked up PlayMaker yesterday morning, spent the day watching some videos from the company's incredibly well documented YouTube channel and started experimenting today. I only got Unity free a week ago so I'm as novice as they come at the moment.

As a testbed, I'm making a rudimentary railshooter in the vein of Starfox64. "Making" in this current sense meaning make the ship move along said rail, then work out how to do more advanced things like actually controlling the thing as it does. I'm away from the computer with the messy project on it but I don't have anything in there in presentable format anyway. So, here's a quick graph showing what I was thinking would work:

http://i.imgur.com/GZaxLN3.png

The idea is that the player character is made up of a two-object construction consisting of a Tether and the Ship itself. The idea I had was that the Tether would follow a rail along the Z axis (which I kind of know how to do - I found iTween has a move action that makes a path out of waypoints that works swell for this sort of thing) while the player controls the ship's X, Y and local rotation variables. Extensively, it'd be nice for the player to be able to slow down and speed up the Tether's speed along the rail dynamically (i.e. break and boost) but I'm getting ahead of myself. Right now the issue I'm facing is making the ship actually stay within a certain distance of the Tether.

I managed an unsatisfactory solution by getting a vector variable, using that to control X and Y and having the ship's FSM GetDistance every frame and contrast this against a float switch. If the switch was triggered, an event notified another state to move the ship towards the rail a bit (1 or 2 units closer than the max distance the switch was checking for) and then send back to the main state. This works fine, except that hitting the limit set produces the effect that the ship is "bumping" against an invisible barrier. Some way to have the ship actually hit a constant maximum limit in a smooth fashion would be preferable. Is there a more appropriate action to cover this?

The other tethering issue I'm having is how to construct a good and proper third person camera for a more freeform, conventional third person flier (on the rail the camera would possibly just follow the Tether). I managed to get the camera to look with the ship in a pleasing manner by dropping a game object out in front of the ship and having the camera SmoothLookAt that, but I'm not sure what is the best way to keep the camera behind the ship but in a manner where it can "sway" or "lag" from side to side as the ship turns rather than occupying a rigid position in space local to the ship itself (which gets nauseating). Actually is there a tutorial out there I overlooked specifically about constructing third person flying vehicles in playMaker?

Thanks for the help fellas.

EDIT: This fellow has the sort of thing I'm trying to describe in that second point:


The term slipped me by earlier. It's called a "chase cam" that I was trying to construct, where the camera has a limited degree of rotation behind the ship it can swing to rather than being locked to an absolute point in space behind it.
« Last Edit: March 11, 2013, 08:07:57 PM by Designopolis »

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2511
  • Mender of the past
    • Cleverous
Re: What's the economical approach to "tethering" objects?
« Reply #1 on: March 11, 2013, 07:16:14 AM »
There could be a lot of ways to do that..

The first thing I would try is doing as much as possible with the hierarchy. Maybe create an empty game object (PathManager or something) that follows the rail path, absolutely, at a speed, then put the Ship child to it and setup your controls FSM on the ship object. Then the ship always follows the rail since it's parent is locked on the path. The ship should now be first following the path, then inherit any input the player gives it. That should feel pretty solid so now the limits..

First thing that comes to mind for the limits is making a new empty game object, parenting it below the PathManager and putting a box collider at the top, bottom and sides that the ship will hit and stop. It's child to the Path Manager so it will follow it and stay inline with the ship, effectively creating limits as long as the ship has a collider on it as well.

A more technical solution would obviously be better for more dynamic situations but this should work okay for what you're trying to do and would be hugely economical.

With the camera I don't know specifically how, but smooth follow is probably what you are looking for. Add it and play with the settings, testing after small changes.
« Last Edit: March 11, 2013, 07:19:25 AM by Lane »
Products by Cleverous
|| Vault Core : Database
|| Vault Inventory : Multiplayer Inventory
|| Vault Attributes : Character Stats
|| That Hurt! : Dmg Floaties
|| Quinn : 3D

Designopolis

  • Playmaker Newbie
  • *
  • Posts: 6
Re: What's the economical approach to "tethering" objects?
« Reply #2 on: March 11, 2013, 10:28:25 AM »
I'm back at my station this morning, so I had the opportunity to screen-capture what I have and give you a clearer picture:



I drew a few boxes in to quickly visually represent the setup. The ship does have a collider on it (the central chassis does anyway - there are other mesh colliders assigned to the wings and pop-out engines but they're just triggers. I don't know if that's even a remotely appropriate way to handle collision detection as I'm not that far yet and just have them there for later reference  ::)) and I was thinking that an encompassing collision box or other shape would work, there must be a much more straight forward option out there for keeping objects within a specific radial proximity to a defined point in space.

At least with a non-physics item. The Unity manual mentions caution when combining transform and physics, and I was thinking hauling a physics object along a rail powered by more absolute forward motion would be a bad idea.

Anywho, I tried something else this morning and I like it quite a lot: I rearranged the above setup a bit so that there were two nodes out in front of the Tether: An Aim node and an Aim Center node. The idea is that the Center node is always absolute to the Tether (say, 20 units ahead on the Z axis) and the player controls the Aim node directly. The Ship looks at the Aim node and moves to match its X and Y values. That setup has produced this effect:



Which is functional, but I want to get the ship to tween into position rather than lock to it as you see here. Is iTween itself the best solution for this or would a simpler solution be in order?

As is, the ship is getting its position like this: On the Aim node, a GetPosition action takes the X and Y values and stores them as two separate global floats. The Ship itself has a SetPosition collecting these global floats and setting the ship's position accordingly, without delay. I imagine iTween would be appropriate instead but I cannot quite figure out how to get iTween to accomplish this.

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2511
  • Mender of the past
    • Cleverous
Re: What's the economical approach to "tethering" objects?
« Reply #3 on: March 11, 2013, 11:18:05 AM »
You can use itween to smooth follow the aim node without having to do the position grab. It is a little confusing at first, but try to use the itween actions and test things out while making small changes and see what happens, you'll start to see how it works.
Products by Cleverous
|| Vault Core : Database
|| Vault Inventory : Multiplayer Inventory
|| Vault Attributes : Character Stats
|| That Hurt! : Dmg Floaties
|| Quinn : 3D

Designopolis

  • Playmaker Newbie
  • *
  • Posts: 6
Re: What's the economical approach to "tethering" objects?
« Reply #4 on: March 11, 2013, 11:38:53 AM »
In the meantime I ended up doing this:



Here's what's happening. The three moving nodes from front to back are the Ship Node, the Aim Node and the Camera Node. As is, the Camera and Ship nodes get their X and Y values from the Aim Node (brutally unnecessary because I'll just strip that bit of the FSMs out and just make the two nodes children to the Aim Node for the same effect  ::)). The ship has an iTween Move Update node telling it to look at Aim Node while following Ship Node with a Time of 2. That's the only Action present for that. The Camera is using Smooth Look At the Camera Node while itself being a parent to the Tether (not seen - its on the same vertical plane as the ship and its node and everything here is a child to it).

I think this works well, but I still haven't found a good solution to the radial check issue on the Aim node itself that I made the topic for. That GetDistance > Transform idea works, but the actual process of transforming it back and then giving control back to the player (who is still holding down the control to move into the set limit) produces a bumpy effect that reverberates with the entire structure, including the ship. There must be a simpler way to tell a given GameObject to stay within a radial set distance of another one and take action to stop it if it moves past the threshold. One without the jitter. Or would applying a collider to the node and then a larger one around the center actually be the appropriate, streamlined solution?

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2511
  • Mender of the past
    • Cleverous
Re: What's the economical approach to "tethering" objects?
« Reply #5 on: March 11, 2013, 12:07:02 PM »
I think this works well, but I still haven't found a good solution to the radial check issue on the Aim node itself that I made the topic for. That GetDistance > Transform idea works, but the actual process of transforming it back and then giving control back to the player (who is still holding down the control to move into the set limit) produces a bumpy effect that reverberates with the entire structure, including the ship. There must be a simpler way to tell a given GameObject to stay within a radial set distance of another one and take action to stop it if it moves past the threshold.

You described it, then described it at a higher level. It will still have to do the check either way.

You could add the check at the input level, where the player presses the key and if the check is less then you cant move, if not then proceed with the move.

Or
Quote
One without the jitter. Or would applying a collider to the node and then a larger one around the center actually be the appropriate, streamlined solution?

Setup collision either by a collision box triggered by a collision exit or 4 boxes (at top/bottom/left/right) that throw a switch that interrupts the move command on collision enter.

There are lots and lots of ways to do this. You're on the right track, just keep tinkering around and you'll find a way that works for your scene.
Products by Cleverous
|| Vault Core : Database
|| Vault Inventory : Multiplayer Inventory
|| Vault Attributes : Character Stats
|| That Hurt! : Dmg Floaties
|| Quinn : 3D

Designopolis

  • Playmaker Newbie
  • *
  • Posts: 6
Re: What's the economical approach to "tethering" objects?
« Reply #6 on: March 11, 2013, 07:21:11 PM »
The collision box approach is bugging me (I need to find a good resource to learn how these things work soon) so I tried something else that actually works quite well: I made a Manager that grabs the X and Y axis for the mouse (I want mouse steering as an option) and drops those variables to two global floats (called MouseAxisX or something like that). It then uses Float Clamp and Float Add to create a "threshold" variable (itself defined by some other global variable so I only have to change it once for tweaking, as is it's 100 to -100) for each axis and store the result as another float called MouseThresholdX or something like that.

The actual Aim node uses Translate to steer with the MouseAxisX float, and does per-frame Float comparisons to see if MouseThresholdX hits that 100 or -100 limit. if it does, an event hands everything off to another state that puts a float clamp on the MouseAxis that only lets it move back into the proper zone.

The only problem with this is that flicking the mouse a lot really fast outruns the checks, so you can throw off the entirely relativee center that you start on. Is there some way to define for the Mouse Axis that where it is when the game loads should be rooted as "center?" Or should I re-arrange the top-down order of these states to ensure priority to the clamps and checks?

Designopolis

  • Playmaker Newbie
  • *
  • Posts: 6
Re: What's the economical approach to "tethering" objects? [SOLVED]
« Reply #7 on: March 11, 2013, 08:15:09 PM »
All right, I got this figured out finally:



Get Position for the Aim node, drop its X and Y variables into floats (they probably don't need to be global but at some point I had a manager referring to them), compare that against numerically defined hard values designating the borders, and if they hit it move to another state that restricts that axis to only the other direction.

The only issue now is if someone rubs up against one border and slides to a corner, they can supersede the one that forms with it. As in move to the left then slide up and go past the top, because that Stop Left state doesn't also check top and bottom. I'll have to play for a possible cleaner solution than just dropping the checks for both edges that meet the one being barred for all four states cause that seems redundant  ;D
« Last Edit: March 11, 2013, 08:27:25 PM by Designopolis »