Okay, I’ll admit that’s a little underwhelming as a major feature, given that most tower defence and RTS games have a way of speeding up time to zip through any lull in the action. But it’s significant since it’s a feature the version of Def currently out on OUYA doesn’t have. Most levels in Def are designed so that there shouldn’t be many moments where you are idle enough to need a speedup feature, but it does happen occasionally. My initial attempt at implementing this before the OUYA release hit some bugs I couldn’t solve[1], and I opted to release rather than have this one non-essential feature hold everything back. That said, it’s a nice feature to have, so I devoted a little more time to get it working, and now it’s coming !

1.For the interested developers: the easy way to do ‘speedup’ in Unity is to set Time.timeScale to something greater than 1.0, and this is what I was doing. However, I was seeing missed collisions at faster timescales – this is often the result of moving rigidbodies during the Update loop rather than the FixedUpdate loop. If you pause the editor and step through frame by frame, you’ll see the objects do appear to collide, however the OnTriggerEnter or OnCollisionEnter callbacks aren’t being called at the right time, since these are called at the rate of the FixedUpdate physics loop, not at the framerate of the rendering loop (Update). I’m usually very careful to ensure updates that might change rigidbody positions only happen within FixedUpdate … but I hadn’t properly considered the tweening library I was using (LeanTween). It turned out this behavior was largely to do with the way the LeanTween (v1.18) uses Unity’s FixedUpdate physics loop (punchline: it doesn’t). LeanTween (v1.18) detects if a gameobject has a rigidbody and sets a field on it’s config object LeanTweenDescr.hasPhysics = true; – however, it appears to only use this to handle rotation tweens – all changes to the transform position still happen in Update. Ultimately this is my fault for not properly reading the source and understanding the limitations of a (free!) library I was using.

In the process of getting to the bottom of this bug, I ended up implementing a flag so I could switch between using LeanTween, iTween or GoKit (GoTween) for any tweening operations in Def. Each tweener has it’s own way of handling rigidbodies and Update vs. FixedUpdate. iTween looks for the presence of a rigidbody and tries to do the right thing automatically. GoKit (aka GoTween) has a setUpdateType(GoUpdateType.FixedUpdate) method on the GoTweenConfig object. I ended up replacing most of the tweening operations with GoKit, properly configured to use FixedUpdate, and the collision bugs during speedup went away.