Fake it until you make it. Or until somebody else makes it. — Alfred Mirek

Recently the devilishly handsome Nick Breslin asked about an alternative to namespaces in Unity. Namespaces are a familiar concept to C# programmers that solve the problem of naming collisions, but Unity has yet to support them. The documentation promises that this limitation “will be removed in a future version,” but don’t hold your breath. You need to breathe.

If you’re unaware of what namespaces are, you probably won’t care about this post. If you’re a Unity programmer familiar with the construct, you still probably won’t find it overly enthralling. Heck, even I have difficulty mustering enthusiasm about the subject. The reason is that you’re unlikely to encounter naming collisions as a game developer. The issue arises when building libraries to be used by other developers. Distribute a class named Player in your .unitypackage and watch as disgruntled developers ask why Unity’s console shouts at them. If you’re distributing code for others to incorporate into their game, it’s important that it doesn’t require them to rename their existing scripts.

The solution I offered to Mr. Breslin was the use of nested classes. That is, make your classes the children of a single parent class.

To separate each class into separate files for better organization, use C#’s partial classes.

This allows developers implementing your library to have their own Pathfinding class. Unfortunately, it’s an imperfect solution. If one of the nested classes inherits from MonoBehaviour, you are unable to attach it to a game object. Also, Unity prevents two files from having the same name, so if your library contains a file named Pathfinding.cs and the developer has a script named identically, Unity’s compiler will shake its fist and curse rudely. Furthermore, you can’t simply jam a using keyword at the top of your class and have the child classes available without the SuperAI accessor.

Of course, other options are available. For one, your library can be distributed in assembly (DLL) form and use actual namespaces. But again, classes are unable to inherit from MonoBehaviour and be used as a component. Also, your code becomes unmodifiable once it’s in DLL form, which may be undesirable if you want to give developers the ability to make their own tweaks.

The simplest solution, and perhaps the most obvious, is to prefix all class names with the name of your library.

When I worked at OverInteractive Media, this is how we avoided naming collisions in dimeRocker’s client package. With classes like Util and Debug, we needed to ensure that our naming decisions wouldn’t cause grief for developers using the service. We simply prefixed every class name with “dr”; no nested classes, partial classes, or awkwardly named files. We needed scripts that inherited from MonoBehaviour and which could be modified by the developer, so this option was also our only one.

As usual, the simplest solution is often the most effective. While faking namespaces through a combination of nested and partial classes might strike your fancy, simply giving your classes unique names might be the best choice for keeping those dastardly naming collisions to a minimum.

I’m going to remake The Godfather… in 3D! — Zhang Rou

Today I’m releasing the cutscene editor I worked on as part of Unity’s Summer of Code last year. The version number is 0.1 — it’s several features short of what I envisioned and it’s not as user-friendly as I’d like it to be — but I feel it’s important to get the existing code out there for other eyes to see. What’s missing now is a sample scene, proper documentation, transitions, and a decent live preview, among other things. The “filters” concept (which basically applies full-screen effects to cameras) is half-baked. Transitions didn’t even make it to the oven. In other words, not all functionality you might expect is there, and the usability is frightening.

With that disclaimer out of the way, I intend to continue improving the editor and get it to the point where it’s indispensable to developers building cutscenes. I have set up a project on Google Code where the .unitypackage can be downloaded. The code hasn’t yet been saved to a subversion repository, but it will be shortly. The code is licensed under the liberal MIT license, so feel free to use it however you wish. I welcome any and all contributions; additional developers would be fantastic. Bug reports and feature requests, which I encourage you to make, can be logged on the issue tracker.

If you have any questions or would like to lend your developer talent, you can email me at matthew@matthewminer.com. In the coming weeks I’ll make some posts on how to use the tool, and hopefully some improvements as well.

I’ve had enough of your mumbo jumbo. Unless your mumbo jumbo encompasses coroutines. Those I dig. — Kaj Gottlob

After my last two borderline useless posts, perhaps today’s code snippet will be more valuable. I’m optimistic.

In the dimeRocker Unity client, of which I’m a developer, coroutines are used to send information to and from the servers. Conveniently, coroutines can execute in parallel with your own code or they can be called from another coroutine in order to wait for their completion. Such functionality is useful in Unity for a number of purposes, and seasoned developers will certainly be familiar with them.

In the code above, the first coroutine finishes execution before the second one starts. An easily made mistake though is to call a coroutine without using StartCoroutine, as you would a regular method. In this scenario, the coroutine instructions aren’t executed and no errors are thrown. Luckily there’s a way to prevent such a ghastly mistake. Let’s say I have the following coroutine.

Tantalizing, I know. If I add an additional function that returns a Coroutine object…

I can now execute the contents of the coroutine simply by calling the public FetchSomeInfo method. I don’t even have to be aware that I’m executing a coroutine. If I wish to wait for the instructions to complete, I can still pair the method with a yield statement.

As you can see, eliminating the need for StartCoroutine makes the code cleaner and more bulletproof (I myself have made the mistake of calling a coroutine directly, to great frustration). Of course, there is a downside to this method of calling coroutines, which is the reason why the dimeRocker Unity client still requires, for the most part, the use of StartCoroutine: developers currently calling coroutines are familiar with using StartCoroutine, and sending it a method that returns a Coroutine object will cause the compiler to throw an error. But, hopefully developers working on libraries to be used with Unity will adapt this system and folks will get used to it, and we can all have the elegant, “there’s no way you can screw this up” code we desire. I’m optimistic.

I am overjoyed at your ability to use hyperlinks. — D.B. Cooper

Recently a somewhat detailed progress report about my Cutscene Editor was posted on the Unity3D blog. Rather than copying and pasting the post here, I reckon I’ll link to the article instead. Enjoy!

A scroll view that tries to reveal its content, how utterly pointless. — Matthew Miner

Today’s Unity discovery: calling Event.Use() every time the OnGUI() function runs will cause scroll views to not work. At least, they won’t respect any dimensions you set and will simply stretch to accommodate the elements contained within it. “A scroll view that tries to reveal its content, how utterly pointless.” Those were my exact words.

In code form, I had something like this:

The scroll view is most certainly not 50 pixels wide. Moving Event.current.Use() inside the if statement fixes it though.

And all is well.

Shouldn’t you be done by now? — Harold K. Bullard

A new requirement for the Summer of Code is to give weekly progress reports detailing what we’ve accomplished in the past week as well as what we intend to conjure up in the next one. I figure to give the old blog some love, I’d post my progress reports here.

Week 1

• Determined desired features
• Fleshed out media metaphors presented to user (shots, actors, audio and subtitles)
• Basic user interface setup
• Researched animations and animation events

Week 2

• Classes: media, tracks, clips are objects
• Media can be added to timeline
• Playback: camera toggling, audio and subtitles
• More user interface setup
  • Custom inspectors
  • A scrubbable timeline
  • Drag and drop media from project Hierarchy and Assets view
• Reviewed third-party code contribution

Week 3

• Add ability to add actors
• Clip editing: drag clips to a new position on timeline
• Manage overlapping elements
• Make a zoomable timeline (currently it’s at a fixed zoom level)
• Razor tool

I hope your software is of higher quality than your analogies. — Bill Bowerman

Work on the Cutscene Editor has been progressing steadily. The GUI is starting to come together and actually resemble a cutscene editor (whatever the heck that looks like; I conveniently have no point of comparison). Building the editor window controls has been frustrating at times, but ultimately rewarding. Frustrating because the documentation can leave much to be desired. Rewarding because the ability to extend the editor is sensational. It’s like a roller coaster, but it code form and without the long lineups.

Above is a screenshot of the current version. Let’s call it 0.1. If it looks terribly unusable, that’s because it is. But don’t you fret, it will be awesome.

I would have pitched a Hello Kitty GUI skin. Way more useful than a friggin’ cutscene editor. — Olof Öhman

Today I was accepted into Unity’s Summer of Code. In their wise words, it’s “a program through which we offer indie & student developers the chance to get paid for doing something cool in Unity.” Applicants pitch an idea and if it’s accepted they get cash, a mentor, and six weeks to complete their project. It’s a rather fine program I reckon — there’s some intimidating talent in the Unity community and a never-ending need for more Awesome Stuff.

My particular idea was to create a Cutscene Editor to facilitate easy creation of realtime cutscenes by developers and filmmakers alike. Think of it as merging Final Cut with Unity, but working with in-game cameras and animations rather than video footage. Creating cutscenes in Unity is currently a bit of a drag and requires the developer to whip out their trusty script editor. The goal of this project is to make such whipping unnecessary, and to make it possible for video editors to work with elements like clips, transitions, and effects in a familiar way. If this sounds interesting to you (and I sincerely hope it does), I encourage you to take a look at my proposal [PDF].

Over the next six weeks I’ll be posting about my progress here and on the forum. Naturally I’d love to hear any feedback and ideas you might have. My development time is fairly limited, but in the given month and a half I hope to make this tool as useful as possible.

XML? Ha! I once wrote some XML! Hilarious! — Juan José Pérez Hernández

This winter I built a basic video player for a website using Adobe Flex. Beside the viewer was a list of thumbnail images, one for each video. When clicked on these would load the appropriate video and display relevant information below the viewer. This information, as well as the paths to the videos and thumbnail images, was stored in an external XML file. The player worked well, perhaps even excellent, until some of the information in the XML file was changed. The video player still worked, but the new information was nowhere to be found. Below is the tag I used to load the XML data.

To my surprise, using this tag causes the XML data to be compiled into the .swf rather than loaded at runtime. Making a change to videos.xml didn’t do a thing — indeed, it wasn’t even necessary that the XML file exist after compilation.

Now, this is not the behaviour I desired. I wanted to allow others to modify the contents of the XML file and have their changes reflected in the SWF. The solution was to not use the Flex XML tag at all, but rather to use the following code.

I’m relatively new to the Flex game, so this may seem obvious to veterans in the field, but for new Flexers (Flexies? Flexettes?) it’s perhaps something to take note of. I sure wish I had.

Sigh.