Unity

That's gonna be a short post, because all you need to know is over on Robert's¹ blog:

Say you're making a Unity game that takes place in a large landscape dotted with windmills, and some of these windmills have tunnels that lead underground. But in Unity, the terrain collider is generated from heightmap data: it's essentially one giant bumpy plane. You can't punch holes in it.

Can we hack it to achieve the same result? Yep. Here's one way, there are two parts to it:

1. Hiding a piece of terrain geometry with a "depth mask" shader.
2. Disabling the collider so the player (or whatever) can pass through the hole, but collides with terrain other times.

If you need more detail,

please head over to Robert's blog, where everything is explained. Just had to get that out there, because it seems like something other people might find useful.

Source: Flickr

Since I happen to be ranked somewhat high when it comes to mentioning Unity 3D and XML, and some of the posts¹ happen to be outdated by now since I learned stuff². But most of all, I intend to learn even more.

That's why I choose to release those two projects into the wild and publish them on github.

Animation curves in the new Unity 3 can not only be used for animation, but can be directly accessed by scripts.

By defining

AnimationCurve curve;

you can add a specific curve to the script in the editor. Using AnimationCurve.Evaluate() you can get the y value at a specific time. Using those curves, you are no longer limited to use Lerp() at every corner (or one of the additional functions provided by Mathfx).

Thanks to Mario von Rickenbach who mentioned that in a lesson as an aside …

Exporting an animated armature with a mesh for Unity using Blender 2.5 can be a bit of a hassle. With the armature parented to the mesh, I could either export the mesh or the armature with the animations, but never both.

Having the armature separate from the mesh seemed to have worked – I have now everything set up in Unity, both mesh and armature with animation.

Though the animation looks slighty wobbly …

This might work for simple animations; more complicated set-ups might still fail to export, since Blender 2.5 and Unity3D 3.0 both have not exactly extensively tested.

When preparing my game for Fantoche, I ran into problems several times, since upon building my game, the screen either remained black or parts of my game did not work, with the log showing a NullReferenceException.

In both times, it was related to me tagging objects in the Unity 3D editor. This is caused by the somewhat peculiar implementation of tagging in Unity which only allows one tag to be added to an object.

Pitfall No. 1: EditorOnly

Tagging objects in the editor as EditorOnly will make the game work in the editor – but not in the build, as those objects won't be included when building your game.

Pitfall No. 2: Trying to Access One of Several Objects with the Same Tag

When accessing GameObjects using the FindObjectsWithTag() function, make sure that only one object has this tag added.

The function returns the first object with this tag it encounters.

Just in case you are as stupid as I am and place the imported models in your Unity 3D scene and later realise that prefabs would have been rather fab: This is the solution: Drag your new prefab onto the old model in the hierarchy pane while having pressed alt – instant replacement. And once again, the day is saved.

Today when working on my Unity3D game for Fantoche, I noticed it again: a short little squeak at the start of a triggered sound clip.

This has happened before in my prototype, but I chalked it off to my inferior post production skills when doing the first sound clips. The new sound clips, however, were pristine, I was sure of it.

So the problem had to be somewhere else. Changing a suspect in my trigger script did not change a thing.

Yet turning off 3D Sound in the Audio Importer Inspector did the trick: no more weird squeaks.¹

Of course, there are situations where you would need the 3D Sound property set. I have yet to test this out. Maybe the squeak only occurred because my Audio Listener was so close to the Audio Source.

Since I want to make some basic statistics for my game at Fantoche, I needed some basic logging function of the player's position.

Of course, this could also be done using a simple CSV file, but the perfectionist in me insisted on an XML format. A preliminary test showed me, that I would be able to transform the XML to a CSV later on, so that my S.O. would be able to use it in his own programs.¹

Having set up my development environment in MonoDevelop, I started to work on the problem on how to get my data into a well-formed XML representation and onto the hard disk.

The first approach was to use serialisation. I created a Location class, with all the necessary attributes – until I realised that this would only allow me to get one dataset into a file. I wouldn't be able to add more data to the file.

Conclusion: Serialisation is only good when you have one clearly defined object you want to dump onto the drive as a well-formed XML file.

So I tried to work with the XMLWriter.

Just a hint on how pictures generated by Processing could be integrated into Unity (at least in an exhibition – the technique requires an instance of Processing running, which won't be available on an ordinary setup).

1. Processing produces an image (i.e. from a webcam) and writes that to the disk. When it has finished writing, it will place a lockfile in the same directory.
2. Unity reads the picture and when finished reading it into memory, removes the lockfile again.
3. Processing notes the missing lockfile and generates a new image; as well as a new lockfile.

Why the lockfile? The lockfile is placed to keep Processing and Unity from overwriting/reading each other.

What are the downsides? This solution is very processor intensive. May not work in all cases. Requires Processing running besides Unity – which may mean that Processing could crash in the background and the game tries to keep running ...

Since I want to dive into C# and code most of my game in that language, I was searching for a tool to make my life a bit easier – I just love stuff that writes for me ...

Since C# is, once again, a rather Microsoft-centric thingy, there aren't that many editors out there – except for MonoDevelop, which works like a charm on many systems.

Add the factor, that MonoDevelop supports VisualStudio files – and that Unity actually can export those. With a snap you have set up MonoDevelop to work with Unity. Now add some documentation – and presto, nothing keeps me from outputting nice XML files with statistical data about the whereabouts of the player.

Well ... nothing except my apparent inability to wrap my head around the XMLWriter ...