This discussion introduces a new series about inverse kinematics for videogames. Before starting our journey, this post will show a few games that use procedural animations, and how they differ from traditional assets-based animations.
This tutorial shows how to extend the class
SpriteRenderer to support intuitive, painless fading transitions. Despite referring to sprites, this approach can be used to easily animate any property of a game object in Unity.
This tutorial shows how to automatically generate simplified colliders for 3D models imported into Unity. The tutorial uses Google SketchUp as an example, but its knowledge and code is agnostic to whichever modelling tool you are using.
In a previous post, How To Integrate Arduino With Unity, we have shown how data can be sent and received through the serial port. The main problem encountered was dealing with the latency and the delays that communicating across different devices introduces. The solution proposed in that tutorial used a coroutine; decoupling the device communication from the game logic attenuates the problem, but it doesn’t remove it. The main problem is that, despite the name, Unity coroutines are not really executed in parallel with the rest of the game. Unity, by design, is not thread safe. This means that true parallelism is intentionally avoided by the engine, as it could result in race conditions. To solve the problem of the communication between Unity and Arduino, once and for all, we need actual threads.