Recent Blog Posts
A lot of games in Unity are organized into several scenes, most notably a title scene and a play scene. If your game has background music, you're likely to want different background music for each scene.
Just sticking a music clip on an AudioSource in the scene would accomplish that, but the music would cut off abruptly when you change scenes, which is jarring and unprofessional. Much better to fade it out over several seconds. That requires not letting the object be destroyed when the scene changes, and handling the scene-change event — which thanks to recent changes in the Unity API, is not as easy as it used to be.
A frequently asked question in both the Unity forums and on Unity Answers is: How do I make a projectile arc to its target, like an arrow shot from a bow? I've seen (and given) lots of different answers to this question, and honestly, most of them are unjustified hacks.
The right (and easy!) way to do this is: just add a bit of arc to your standard movement. Objects in freefall (ignoring air resistance) follow a parabolic arc, and the equation for a parabola is very simple. So, we can just use that equation to compute how must extra height we should have, and simply add it to our Y position, and the job is done.
Cheat codes are secret ways to alter the functionality of a game. It's a term that makes me cringe as a parent, since we teach our kids never to cheat — but once a game starts to grow complex, cheat codes are absolutely essential testing tools. They let you bypass minutes or hours of gameplay you already know is working, in order to get to the part you're trying to fix.
So, how do you actually implement them? This post explains how we do it in our Unity games.
One of the most general and common tricks ever to come out of industrial control theory is the proportional–integral–derivative controller (PID controller), sometimes known as a "PID loop." It is a simple equation that you can use to control any one-dimensional variable, such as a throttle, a motorized hinge, etc. All it needs for an input is an "error" signal — that is, a measure of how far off something is from where you want it to be, plus three constants. Most importantly, it does not need any model of how the value it's controlling relates to the output.
In this post, I'll give you well-encapsulated code for a PID controller in C#, and show how to use this in Unity to control the throttle of a hovercar. The hovercar physics involves momentum, drag, and controls that don't respond instantly, just like a real hovercar! But the PID controller doesn't care about any of that; once you have the three constants tuned, and hook up the error signal (in this case, the difference between the current altitude and the altitude you want), it does the rest.
In many game projects, I've often found the need to execute some bit of code at a later time. Often this relates to audiovisual flourishes. For example, when the player does something scoreworthy, we may want to start a particle effect and sound right away, but then spawn a different effect after a short delay, and actually update the score a while after that.
You could certainly spread the code to do those things out into different classes or methods, triggered by events or other custom code. I've certainly been known to do that; I love Unity Event, and most of my classes that do anything over time expose events for when they start and finish their work, making it easy to chain them together.
But sometimes, dividing up the logic that way makes the code less clear, not more. There may be one place in the code that is handling everything related to this set of actions, and the only thing driving the code apart is that you want it to happen at different times.
CallLater was created to handle just this situation. It lets you write some code, right there in the middle of a method, to actually be run later, after whatever delay you specify.
For our High Frontier video game, we wanted a data file format that would be easy for people to read and write. This is partly for our own use — we would be hand-editing files defining various parts of the game internally — and partly for mod authors, who would be creating new content for the game.
The big players in the serialization space are JSON and XML. XML is, to be blunt, horrible. It's fine for data that is only ever looked at by computer programs, but for anything that might be read or written by a human, it's just awful. JSON is much better, and it's what we've often used in the past. But it too has more syntax than feels necessary. And at the same time, it lacks some features we really wanted, like comments.
So we have designed a new serialization format: GRFON (General Recursive Format Object Notation). We've been using it for over a year now, and loving every minute of it. And today, we are making it available for everyone else to use too, under the permissive MIT open-source license.
When doing rapid iterations of an app (a cornerstone of agile development), testers sometimes find themselves with an older version of the app. This could be because they didn't get the update email, or they clicked the wrong link, or DropBox didn't sync like it's supposed to, or something got cached along the way... whatever the reason, there are few things less helpful than getting a bug report for something you've already fixed.
In C/C++, it's easy enough to use the standard __DATE__ macro, which the C preprocessor fills in with the actual build date. You can just display this on the title screen or wherever, and testers can easily see whether they're running the latest build. But, surprisingly, C# doesn't have any such feature. This makes displaying the build date in a Unity app a bit harder.
Fortunately, it can be done. Here is the arcane magic you need.
I've been a cross-platform developer for many years. Lately my development tool of choice is Unity, which makes it trivial to build Mac, Windows, and Linux apps right on my Mac.
However, there is an important step that Unity doesn't do for you: code-signing your built apps. If your apps aren't signed, then recent versions of Windows (or Mac OS X, for that matter) will throw up scary warnings and make your users jump through extra hoops to run them.
I'm currently doing a job where I need to take 3D polygon data and display it in Unity. These polygons are planar, but oriented arbitrarily in 3D space. Moreover, they can contain holes (possibly multiple holes). Think of a building wall with window cut-outs, and you'll get the idea.
This turns out to be a surprisingly thorny problem in Unity. There is a simple script on the Unity wiki called Triangulator, but it only works with Vector2D and doesn't support holes. I found a blog post on Advanced Triangulation in Unity, but it was neither sufficiently advanced (only works in the XY plane) nor actually in Unity (it wrote each polygon out to a file, invoked an external command-line tool to do the triangulation, and then read the result back in).
The utility referenced in that blog post is called Triangle, which is widely regarded as a very good triangle library. It's open-source C code, so one could make a Unity plugin out of it. But it's not licensed for commercial use, which is a problem for this project. Also, making a native plugin means setting up a build chain for every platform you want to support. For both reasons, I kept looking — I really wanted something in pure C#.
Unity has provided a built-in state machine editor for managing animations since version 4. This is the officially recommended approach to animating a game character. However, it often leads to game logic being divided between code and the animator state machine. I would prefer to have all my game logic in one place, to simplify development and debugging. Moreover, in some cases — especially simple 2D sprite games — the Animator can seem like more trouble than it's worth.
To help clarify the pros and cons, I built a 2D game character using three different approaches:
- A simple home-grown animation system that eschews Unity's built-in animation support completely.
- Use of Unity animations, but without using the Animator state machine; instead each animation is invoked directly from code.
- Full use of the built-in Unity components, with all game logic in the state machine, and only minimal supporting code.
For the rest of the story, see the full article on Gamasutra!
All blog posts