As more and more people discover MiniScript, the question is occasionally asked: why? Why was MiniScript created, and why should someone use it rather than some other language?

It's a perfectly valid question, so in this post I will try to clarify. My purpose is not to convince anyone of anything, but to explain why, after years of using other scripting languages, I felt compelled to create something new. I'll do this without attacking other languages, since every language has its fans and I don't want to kick anybody's dog; instead I'll focus on what I think is really cool about MiniScript, and how it offers a collection of advantages that, taken together, can't be found anywhere else.

MiniScript has been available as a Unity plugin since 2017. But it has been such a success with its users that it deserved wider distribution. MiniScript in Unreal games, MiniScript on the command line, MiniScript in your browser... why not? And while it was great to get a little financial support for working on MiniScript in the early days, in the long run keeping it commercial only slows down its adoption. That's why, as of today, MiniScript is open-source.

I've been doing a lot of development for the Oculus Go lately, which is an absolutely marvelous VR platform — inexpensive, easy to use, and high quality (when the development is done right). For the most part, developing for it in Unity is straightforward; the camera automatically tracks the rotation of the headset, and the OVRInput class provides controller tracking and touch/button inputs.

But at some point you may need to use some part of the extensive "Oculus Platform" SDK. This provides information about the current user, such as their Oculus username, and also provides all manner of match-making and social services, including efficient voice (VoIP) chat. Unfortunately, accessing this SDK isn't nearly as simple as you might expect. This post explains how to do it.

I have long thought that Unity did not really support configurable input out of the box — at least not without using the ugly default Graphics/Input configuration dialog (which no polished game would ever inflict on its players). Particularly if you wanted to support hot-swappable joysticks or gamepads, I always believed you had to use some third-party plug-in.

But I recently discovered that this is not true! Making configurable, hot-swappable input in Unity can be done without any plug-ins, and it's not even all that difficult. Read on to see how.

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.

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:

1. A simple home-grown animation system that eschews Unity's built-in animation support completely.
2. Use of Unity animations, but without using the Animator state machine; instead each animation is invoked directly from code.
3. 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!

Unity had a "Live Training" demo called Events: Creating a Simple Messaging System.  This is often pointed to as an example of using the UnityEvent class that was introduced in Unity 4.6.

While this was a fun and educational video, it uses UnityEvents in a very odd way, wrapping them in a string-based notification system and hooking everything up in code. Honestly, you could have done exactly the same thing using standard C# events, and it wouldn't have made any difference. (Indeed, prior to UnityEvent, many Unity developers — myself included — did exactly that.)

So I decided to make my own video, accomplishing the same demo but using UnityEvent the way nature intended. The result is a lot less code, easier to maintain, and harder to screw up.

I've  been teaching my son C# programming lately.  This is a great choice, because it's the best language to use with Unity, and with Unity, he can make games for virtually every platform under the sun. With some luck, he'll be able to make enough money in the various app stores to pay his way through college (or at least pay his own car insurance).  And as a bonus, when you know C#, you can also develop native apps for Mac, Windows, iOS, and Android, using various toolkits (such as MonoTouch for example).

However, the code-run-test-debug cycle is slower in Unity than I would like for his purposes.  Learning a language is easier when you can play around with it interactively.  This is especially true when you're working through small programming problems like those at Project Euler.

We've been delving into Coroutines in Unity lately, and ran into a strange behavior today that took all morning to sort out. In brief, a routine we thought we were calling never got called at all -- a Debug.Log as the very first line of the function never logged anything.

Since I've been using Unity, I've loved it for the most part. Sure, it leaves a few socks on the floor, such my inability to post to their forum without pestering a moderator for help, or the way an infinite loop in your code locks up the whole Unity environment. But on the whole, it's a really great development system.