Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jgodfrey

Pages: [1] 2
DOTween & DOTween Pro / Re: Animate object with moving endpoint
« on: March 28, 2016, 07:15:15 PM »

I appreciate the input. I'm sure I'll be able to work out something satisfactory using your suggestions.

DOTween & DOTween Pro / Animate object with moving endpoint
« on: March 15, 2016, 11:21:14 PM »
I'm working on an endless runner type game (actually, a vertical endless climber).  In the game the player can gather coins as they climb. When a coin is "collected", I'd like to tween it from its current position to a static location on the screen (where the GUI coin counter is located). While this seemed easy on the surface, it turns out to be harder than I expected.

While I have both a start and end position for the tween in world coords (start = coins current position, end = location of GUI coin counter (top left of screen), converted to world coords).  However, since it's an endless climber, the world coordinate system is changing while the coin is tweening.  I attempted to solve the issue using the following:

Code: [Select]
public class CoinMotion : MonoBehaviour
    private float _completionRadius = 0.25f;
    private float _speed = 80;
    private Vector3 _targetLoc = new Vector3(0.075f, 0.85f);

    public void MoveCoin()
        Tweener tweener = gameObject.transform.DOMove(Camera.main.ViewportToWorldPoint(_targetLoc), _speed).SetSpeedBased(true).OnComplete(Finish).Play();
            // keep going until we're "close enough"
            float dist = Vector3.Distance(gameObject.transform.position, Camera.main.ViewportToWorldPoint(_targetLoc));
            if (dist > _completionRadius)
                tweener.ChangeEndValue(Camera.main.ViewportToWorldPoint(_targetLoc), true);

    private void Finish()
        // pulse the coin collector GUI once the coin tween finishes...

Note the "_targetLoc" vector represents the location of the on-screen "coin collector" in Viewport coords.  While the above mostly works, it takes too long to actually reach the destination (even if sped up to crazy values).  Also, the path seems a bit wonky depending on how fast the world coords system is changing.  At times, the world coords can change very fast (for instance, if the character is currently using a jetpack, they can climb quite fast).

It seems to me that the simple solution is to tween the coin as a "UI element" - using UI coordinates, since those wouldn't change with the world coord system.  However, maybe there's a good way to do in Worldspace also?

Any thoughts appreciated.


DOTween & DOTween Pro / Re: Trigger script at each path location
« on: February 24, 2016, 07:56:56 PM »
You're probably looking for the "OnWaypointChange" callback.  Here's an example, straight from the docs...

Code: [Select]
void Start() {
   transform.DOPath(waypoints, 1).OnWaypointChange(MyCallback);
void MyCallback(int waypointIndex) {
   Debug.Log("Waypoint index changed to " + waypointIndex);

DOTween & DOTween Pro / Re: Trouble with AppendInterval timing
« on: February 16, 2016, 07:29:18 PM »
So, the timing issue in the above Sequence seems to be caused by the Ease setting.  If I change the ease to "Linear" and change the StrobeOnTime and StrobeOffTime properties to be the same value (say, 1 second), the on/off times look reasonably equivalent (visually).

That said, I don't understand why the Ease setting has any bearing on this particular Sequence, since it's made up of only:

- zero-length tweens
- callbacks
- intervals

Why does an ease setting impact any of the above?  Seems wrong to me, but maybe I'm missing something...

DOTween & DOTween Pro / Trouble with AppendInterval timing
« on: February 15, 2016, 01:00:25 AM »
I'm trying to create a strobing platform using the following Sequence:

Code: [Select]
_seq = DOTween.Sequence()
            .SetLoops(-1, LoopType.Restart)                 // loop forever
            .Append(_ren.DOFade(1f, 0))                     // instantly fade the sprite renderer to 100% opaque
            .AppendCallback(() => _coll.enabled = true)     // enable the platform collider
            .AppendInterval(StrobeOnTime)                   // wait for the designated "platform on" time
            .Append(_ren.DOFade(0.25f, 0))                  // instantly fade the sprite renderer to 25% opaque
            .AppendCallback(() => _coll.enabled = false)    // disable the platform collider
            .AppendInterval(StrobeOffTime);                 // wait the designated "platform off" time

The idea is to have a platform that's "on" (opaque, collider enabled) for a given amount of time and then "off" (see through, collider disabled) for a given amount of time - and loop forever.

The above works as expected, except the two "intervals" don't seem right.  If I set the two values equally, the last one (StrobeOffTiime) is always shorter than the first one.  I'm not exactly sure which one is wrong, but the timing is not as expected.

Is there anything wrong with the above?


Additionally, since it's likely that both the min and max anchors will be moved together (to simply tween a UI element on/off the screen), maybe some additional, single-tween variations might make sense:

Code: [Select]
DoAnchor(Vector2 targetMin, Vector2 targetMax, ...)
DoAnchor(Vector2 relativeTargetBoth, ...)

DOTween & DOTween Pro / Re: Sequence - basic usage verification
« on: February 04, 2016, 04:01:59 PM »
Hey - the first response drawn by any of my questions...  Thanks for that!

My input on your "if" vs. "switch" dilemma is this...

The speed differences are so negligible that I would never consider one over the other due to speed alone. Even in the tests you link, the results are quite close for a *billion* iterations. Also, I'd bet that the IL generated by a modern .NET compiler for a simple if/else and a 2-element switch are likely identical.

Since I don't think the speed difference is worth considering, I much prefer to code for readability / maintainability. With that in mind, I prefer a simple if/else over the more verbose switch when only dealing with 2 conditions.  However, once the number of conditions grows, I much prefer the look and feel of a switch, so I change to that.

DOTween & DOTween Pro / Re: Moving platform - can't quite get it right
« on: February 04, 2016, 01:02:14 AM »
OK, I finally have something that's working satisfactorily.  Here's what I'm currently using:

Code: [Select]
        float duration;
        if (Random.value < 0.5)
            // Horizontal motion
            duration = Random.Range(2.5f, 4);
            transform.position = new Vector3(ScreenManager.ScreenLeftWorld, transform.position.y);
            _tween = transform.DOMoveX(ScreenManager.ScreenRightWorld, duration);
            // Vertical motion
            duration = Random.Range(1, 2);
            float vertDist = Random.Range(.5f, 1f);
            transform.position = new Vector3(transform.position.x, transform.position.y - vertDist);
            _tween = transform.DOMoveY(transform.position.y + vertDist, duration);

            .SetLoops(-1, LoopType.Yoyo);

        _tween.Goto(Random.Range(0, duration));

Essentially, I physically move my platform to one end of the linear motion just prior to creating a tween to the other end of the motion. Then, I set the tween to loop infinitely with an appropriate ease-type.

Next, I attempt to randomize the starting location by calling _tween.Goto(0, duration).  Which, I think, should push the start timeline to somewhere between the defined start and end.  Finally, I start the tween.

I was trying to do this with a Sequence of 2 DoMove tweens (one for both passes until I realized I could just use a loop).  Initially, I left the Sequence, but eliminated one of the 2 tweens - in favor of setting up looping.  So, basically, I had the same code as above, but with a Sequence containing only a single tween.  However, the easing did not work the same at both ends of the motion.  I'm not sure if that's expected or a bug, but it seems like it should have worked the same way.

Anyway, problem solved.

DOTween & DOTween Pro / Re: rotation on nodes (dotween pro)
« on: February 03, 2016, 10:05:34 PM »
While I assume the answer to your question is "yes", it's a little vague to be sure. If you could provide some more details regarding exactly what it is you're trying to do you'll likely get a more helpful response.

For instance, is the object in question already being tweened between 2 positions and you simply want to rotate it as a function of where it is in the motion tween?  If that's the case, I'd think you could accomplish that with a Sequence, consisting of something line this:

Code: [Select]

However, based on unknown details, that may be way off base for your needs.


Using Unity's new UI features, it's my understanding that the proper way to move UI panels on and off of the screen in a resolution independent manner is by modifying the associated RectTransform's anchorMin and anchorMax vectors. Currently, I'm accomplishing that via a sequence of generic tweens something like this:

Code: [Select]
        .Join(DOTween.To(() => rect.anchorMin, x => rect.anchorMin = x, new Vector2(1f, 0f), 1f))
        .Join(DOTween.To(() => rect.anchorMax, x => rect.anchorMax = x, new Vector2(1f, 0f), 1f))

The above moves the RectTransform 1 full screen to the right without knowing anything about the screen resolution - which is the whole point.

This seems like it might be a reasonable candidate for some "shortcut" methods, such as:

Code: [Select]


Thanks for your consideration and a GREAT product!


DOTween & DOTween Pro / Moving platform - can't quite get it right
« on: February 03, 2016, 05:42:44 AM »
I'm trying to tween a series of moving platforms.  Each platform moves either up/down between 2 points or left/right between two points continuously. For sake of discussion, let's consider a horizontally moving platform. Really, I just want to move it continuously back and forth on a known line segment, easing in/out of the endpoints.  On the surface, that's easy enough. However, the complication seems to be that when the platform is instantiated, it's already (randomly) somewhere within it's motion segment. 

So, I need to create a tween that moves from the platform's initial, random position on the line to one end of the line and then back to the other end - all while easing in/out of  the line end points.

I've tried this using transform.DoPath (with a closed, 2-point path) and with a Sequence, using 2 separate transform.DoMoveX tweens. While both generally work, I can't figure out an appropriate way to deal with the random starting location of the platform.  It seems that the path always gets an extra point inserted in it (where the transform starts out) and then the easing happens around that point - which doesn't feel right.  The Sequence method also seems to suffer from similar problems with getting the easing to happen at the endpoints.

I've even tried to move the platform's transform to one end of the segment and then doing a random "goto" to advance the tween to some random position along the line prior to playing it.  However, I always seem to end up with results that are close to what I want, but not quite right.

This seems like a simple problem on the surface, but I haven't quite figured out the secret sauce.

Advice appreciated.

DOTween & DOTween Pro / Re: Sequence - basic usage verification
« on: February 02, 2016, 08:55:23 PM »
Hmmm... I guess unless someone says otherwise, I'll assume the above-outline is a valid approach.

DOTween & DOTween Pro / Re: How Can I Animate With Code
« on: February 02, 2016, 03:31:03 PM »
Did you follow the 3-step installation/setup process outlined here?

Hmmm... It seems that something was messed up with DOTween's independent timing functions.  Not sure where or why, but after some fiddling in the Utility panel, everything started working.  I still have a few issues, but it seems I'm over the "tween won't play" hurdle.

I'm attempting to move UI panels on and off of the screen (in a resolution independent way) by tweening the anchorMin and anchorMax members of the panel's RectTransform component.  Essentially, I've parked all of my panels just off the left side of the screen by setting their anchorMin and anchorMax properties to (-1, 0) and (0, 1) respectively.

When it's time to slide a panel into view, I call the below code and pass it the GameObject containing the panel.

Code: [Select]
private void ShowHudPanel(GameObject panel)
    RectTransform rect = panel.GetComponent<RectTransform>();

        .Join(DOTween.To(() => rect.anchorMin, x => rect.anchorMin = x, new Vector2(1f, 0f), 1f))
        .Join(DOTween.To(() => rect.anchorMax, x => rect.anchorMax = x, new Vector2(1f, 0f), 1f))

The result is odd.  Essentially, it seems like the tween is only playing for a single frame.  With the one second duration above, the panel is made barely visible on the left edge before the tween (apparently) finishes.  As I decrease the duration, the above makes the panel more visible (as each frame would have to move the panel further).  If I decrease the duration to something silly (like 0.01), the entire panel is made visible - but only because it needs to move the entire distance in a single frame.

I'm using "DOTween.defaultTimeScaleIndependent = true" to make the tweens Unity time independent.  Though, I even set that to false and ensured that my Unity time.timeScale was set to 1 and I get the same results.

I've also tried the above with and without the "SetRelative" (making appropriate adjustments to the end vectors), but the results are the same.  Originally, I assumed I had somehow misdefined the tweens, but I no longer think that's the case (since short duration's prove the tween works as expected).

It just seems like I'm only getting 1 frame of animation from the above for some unknown reason.  I'm using the most recent version of DOTween (1.1.135) and Unity 5.3.1f1.

I also tried initializing DOTween with "LogBehaviour.Verbose", but that doesn't indicate any problems in the log panel.

Thanks for your input.


Pages: [1] 2