Daikon Forge

Daikon Forge lets you edit your UI live in the scene editor and preview it in the game view.
Daikon Forge lets you edit your UI live in the scene editor and preview it in the game view.

Progress continues on Project Weasel, and last weekend I bought a license for Daikon Forge ($90 in the Unity Asset Store) after mulling over the Unity GUI situation for over two years (basically since Unity announced its new GUI system in San Francisco in 2011). Like many Unity developers, I’ve been waiting for Unity to fix its execrable GUI library for some time, and had avoided investing in nGUI, Daikon Forge, or Coherent because something better — and free — was coming out real soon now.

I reached the point where not having a functional UI library was blocking progress, so I decided I was going to buy a better UI library — the question was which one? nGUI has been the market leader, but from what I’ve seen the API is pretty terrible (and the fact that the nGUI dev is the guy building the new Unity GUI does not fill me with enthusiasm). Coherent — based on HTML5 — seems like a great idea, but according to reviews I’ve read it consumes quite a bit of CPU on mobile devices (and you’d expect it to, given that web browsers can tax mobile devices). From what I could see, Daikon Forge was the least expensive option and possibly the best (if not as widely supported as nGUI). It’s very well reviewed, including by quite a few nGUI refugees. It also struck me that the Unity GUI would probably be, in effect, an improved nGUI, so I’ll have the best of both worlds once it actually ships.

Anyway, so far I’ve found Daikon Forge is pretty nice but not without issues. But it’s worth noting that all of the weaknesses I’ve seen so far affect the developer and not the delivered product.

(Mostly) Good Stuff

I whipped up a 3d pinned information panel in less than an hour
I whipped up a 3d pinned information panel in less than an hour

To create a user interface with Daikon Forge you use a wizard to set up a “manager”. On the plus side, it works! On the minus side it’s a “wizard” — automatic fail. I’d prefer you to be able to drag a prefab into the scene, or drag a script onto a GameObject, or select a GameObject and pick a menu item. The sad thing is that there’s no reason it can’t work that way. Functionality A. Usability C.

Next, you need to assign a default skin and a default font to the UI gadget. In my opinion it should Just Work without this. (How? Easy — stick a default skin and a default font in a Resources folder and load them on the fly if needed.) This particular bit initially stymied me (the picker didn’t “see” the relevant assets), and I needed to find the relevant components manually and drag them into place. Functionality B. Usability F.

Daikon Forge makes creating and maintaining a UI atlas very easy
Daikon Forge makes creating and maintaining a UI atlas very easy
Using Sketch (this is the old version) you can whip up a UI skin in a matter of minutes
Using a tool like Sketch (this is the old version) you can whip up a UI skin in a matter of minutes

The tools for creating your own skins and fonts are almost brilliant. (Select the assets and pull a menu item — and you can easily add items to and remove items from your UI atlas any time you need to.) Functionality A. Usability B.

Next, you can right-click the UI “gizmo” in the scene editor and add controls to it directly. This also stymied me because the context menu does not work when your inspector panel is in debug mode, which mine happened to be in at the time. (Who knew?) Again, on the plus side it works, on the down side many controls come with idiotic defaults (e.g. huge or dimensionless). Functionality B. Usability C.

So I finally managed to get my Galaxy working so that I could click on a star and have a little information display pin itself to the star and show information like the name and spectral class of the star and how many planets it has orbiting it (and the display is not scaled, renders in a minimum of draw calls, and is pixel perfect, but is pinned to the projected 3d position of the star — very cool). On the downside, I found the documentation for binding values to controls to be incomprehensible, and did it all by brute force. Functionality C (so far). Usability F.

Bad Stuff

Every widget has a lot of properties, and they're not given sensible defaults
Every widget has a lot of properties, and they’re not given sensible defaults

First of all, there’s a big workflow problem. When I first imported Daikon Forge into my project it didn’t work properly (e.g. when I tried to assign a skin to one of Daikon Forge’s UI managers it wouldn’t find the relevant assets). This problem eventually “went away” (no idea why) but it was a sign of things to come.

Second, I keep my project in Dropbox and would work on it from my laptop and desktop at different times. When I switch machines, the other machine would load changed files and Just Work. But after I installed Daikon Forge this process became completely broken. Daikon Forge would become completely broken and need to be reimported whenever I switched machines. Worse, every script component assignment would become detached from its relevant script (only for Daikon Forge scripts) and have to be manually repaired. I don’t have a fix for this except to stop using DropBox, which might not be a Bad Thing.

Third, the documentation is good as a class reference, but bad as a guide/overview/cookbook. The tutorials are good but video only and somewhat lengthy. The examples are good but no substitute for actual documentation. Then there’s the website. To post on the website you need to register, and when I try to register it tells me my username or email address flags me as a spammer and that if I want to fix this I need to reply (how?) or use the contact form (where?). I tried my usual handle (podperson) and my usual email address, and my real name and my gmail address — all spammers apparently.

The WYSIWYG editing of your interface is great as far as it goes, but that’s not far. E.g. there are guides, but nothing snaps to them. There’s a grid but nothing snaps to it. There’s a tool to distribute multiple controls horizontally or vertically, but it doesn’t work properly. Worst of all, simply moving and editing things is very finicky. You can easily get into a state where the transform widget is overlapping some other control (e.g. a sizing handle) so that whenever you try to move a control you actually resize it. I ended up resorting to the keyboard for moving controls, and directly entering values for sizing them most of the time.

In a nut

Daikon Forge delivers on its promises in terms of functionality and performance. It renders user interfaces efficiently and attractively. It’s very easy to create and maintain texture atlases. And it supports scalable fonts. Furthermore, its design leverages idiomatic Unity development (e.g. you can make and reuse prefab controls in the obvious manner.) But it is far from perfect: ironically for a UI building tool, its own UI is spotty to put it charitably. Thus far I’ve found the website to be borderline useless and the documentation weak. I’m not sure if the video tutorials and examples really fill the gap (I haven’t had the time or inclination to watch all the tutorials).

C#’s Belt and Suspenders

In discussing my (fairly minor) annoyances with C# with a colleague, I finally figured out the nub of the problem. C# tries to protect you from certain bugs (overflowing bounds and buffers in particular) in so many different ways that the relevant warnings and fixes become irritations and noise, probably making code less reliable rather than more

E.g. why does assigning a double precision value to a float stop code from compiling? What’s the problem this solves?

Another example, why does moving values from unsigned to signed integer types stop compiles? The main reasons for worrying about integer overflows or getting a negative number when you expect a non-negative number is array bounds checking, but C# has array bounds checking, so why do this at all?

It seems to me that C# ought to treat all numbers with periods or exponents as double precision by default and allow assignment to float with implicit casting. This emphasizes correctness (precision) over performance by default, which is as it should be. Similarly, assigning an int to a uint should simply be allowed. (The compiler can insert code to throw an error if the value is negative if so desired.)

Now, I should say I’m using Unity’s (i.e. Mono’s) C# compiler here, so perhaps Microsoft deals with these annoyances at IDE level (e.g. by offering to automatically fix the relevant problems) in much the same way as Apple has leveraged compiler technology to provide automatic fixes, optimizations, and suggested improvements in XCode.

C# Part II

Galaxy Generated and Rendered in Unity 3D
Galaxy Generated and Rendered in Unity 3D

In the end, it took me four evenings to replicate the functionality in my Javascript prototype. I’d have to point out that I was able to do some really nice UI stuff (e.g. drag to rotate, mousewheel to zoom) in Unity that I hesitated to mess with in Javascript (the galaxy was rendered to a canvas in Javascript).

On the whole, I have some impressions.

First, C# is very strict about types, and while I can see some benefits, I think a lot of it is utterly wasted. E.g. having to constantly cast from one numeric type to another is simply a pain in the butt (I routinely expect to have to tease apart a bunch of cryptic type-related errors every time I compile a few lines of new code).

// given an array of weights, pick an index with corresponding weighted probability,
// e.g. [1,2,3] -> 1/6 chance of 0, 2/6 chance of 2, 3/6 chance of 3
public uint Pick( uint[] weights ){
    int s = 0;
    uint idx;
    foreach( uint w in weights ){
        s += (int)w;
    }
    s = Range (1, s); // returns a random int from 1 to s, inclusive
    for( idx = 0; idx < weights.Length; idx++ ){
        s -= (int)weights[idx];
        if(s <= 0){
            break;
        }
    }
    return idx;
}

And all of this rigor didn’t actually prevent or even help debug an error I ran into with overflowing a uint (I have a utility that picks weighted random numbers, but I overflowed the weights leading to an out-of-bounds error. (A simple fix is to change idx < weights.Length to idx < weights.Length – 1.) On the whole it would be nice if you could simply live in a world of “numbers” (as in Javascript) and only convert explicitly to a specific representation when doing something low level.

Second, there’s this weird restriction on naming classes within a namespace such that the namespace and class sometimes may not match and the class you want is often not in the namespace you expect. (E.g. I wanted to create the namespace LNM.PRNG and define the class PRNG in it, but this confuses the compiler, so I ended up calling the namespace LNM.Random — so code referring to this is “using LNM.Random” which mysteriously causes a class called PRNG to become available.) I don’t see why namespaces and class names can’t be the same.

Oddly enough in some cases I am allowed to name the class the same as the namespace, and I don’t know why. So LNM.Astrophysics implements the Astrophysics class, but I had to rename Badwords to BadwordFilter at some point because the compiler started complaining.

I’ve been using Monodevelop, which is an editor produced by the Mono folk and lightly customized to work with Unity. It’s a bit of a slug (if it’s developed using Mono, then it’s not a terrific advertisement for Mono). In particular, its autocomplete is great when it works, but utterly frustrating far more often. It fails to match obvious words (e.g. local variable names) and often makes it impossible to type something short (which matches something longer) on the first attempt. The autocomplete is darn useful, or I’d simply switch back to Sublime.

Flying my untextured spaceship around an undecorated, partially implemented solar system
Flying my untextured spaceship around an undecorated, partially implemented solar system

So the current reckoning is that I ended up producing the following:

  • Astrophysics.cs — defines the LNM.Astrophysics namespace and implements the Astrophysics utility class, some useful enumerations, and the Galaxy, Star, and Planet classes.
  • PRNG.cs — defines the LNM.Random namespace and implements the PRNG class which provides convenience functions for the Meisui.Random Mersenne Twister implementation I’m using.
  • Badwords.cs — defines the LNM.Badwords namespace and implements the BadwordFilter class which checks to see if any of a pretty comprehensive list of nasty words is present in a given string. (Used to prevent obscene star names from being generated.)
  • Billboard.cs — a Monobehavior that keeps a sprite facing the camera. It’s a little cute in that it tries to save CPU time by only updating a given star every 10 physics updates. There’s probably a better way.
  • FixedCamera.cs — a Monobehavior that implements a mouse/touch controlled camera that keeps a fixed view of a specified target unless explicitly moved. I’m planning on using this as my main view control throughout the game.
  • NewtonianScoutship.cs — a Monobehavior implementing an Asteroids-style player ship. I’ve also experimented with a “Delta Vee” style abstracted Newtonian ship controller but good old rotate and accelerate just feels better, and makes movement a pleasant challenge in and of itself. (It also makes becoming “stationary” in space almost impossible, which I think is a Good Thing.)
  • GalaxyGenerator.cs — a Monobehavior that instantiates a galaxy and renders it with sprites. (Right now every single star is a Draw Call, so I’m going to need to do some optimization at some point.)
  • Starsystem.cs — a Monobehavior that instantiates a Star (and its planets) and renders them, a navigation grid (to provide a sense of movement when passing through empty space) and orbits using a bunch of Prefabs.

So, while I continue to find C# quite tedious to develop with, I am making significant progress for the first time in over a year, and while C# feels much less productive than real Javascript, I do think it’s very competitive with Unityscript, and it’s been quite easy to get over the hump.

C#

Screen shot of my galaxy generator in action
Screen shot of my galaxy generator in action

I’ve been developing stuff with Unity in my spare time for something like eight years (I started at around v1.5). I was initially drawn in by its alleged Javascript support. Indeed, I like Unityscript so much, I defended it vocally against charges that using C# is better, and wrote this article to help others avoid some of my early stumbles. I also contributed significant improvements to JSONParse — although the fact that you need a JSON module for Unityscript tells you something about just how unlike Javascript it really is.

I’m a pretty hardcore Javascript coder these days. I’ve learned several frameworks, written ad unit code that runs pretty much flawlessly on billions of computers every day (or used to — I don’t know what’s going on with my former employers), created a simple framework from scratch, helped develop a second framework from scratch (sorry, can’t link to it yet), built services using node.js and phantom.js, built workflow automation tools in javascript for Adobe Creative Suite and Cheetah 3D, and even written a desktop application with node-webkit.

The problem with Unityscript is that it’s not really Javascript, and the more I use it, the more the differences irk me.

Anyway, one evening in 2012 I wrote a procedural galaxy generator using barebones Javascript. When I say barebones, I mean that I didn’t use any third-party libraries (I’d had a conversation with my esteemed colleague Josiah Ulfers about the awfulness of jQuery’s iterators some time earlier and so I went off on a tangent and implemented my own iteration library for fun that same evening).

Now, this isn’t about the content or knowledge that goes into the star system generator itself. It’s basic physics and astrophysics, a bit of googling for things like the mathematics of log spirals, and finding Knuth’s algorithm for generating gaussian random distributions. Bear in mind that some of this stuff I know by heart, some of it I had googled in an idle moment some time earlier, and some of it I simply looked up on the spot. I’m talking about the time it takes to turn an algorithm into working code.

So the benchmark is: coding the whole thing, from scratch, in one long evening, using Javascript.

Now, the time it took to port it into Unityscript — NaN. Abandoned after two evenings.

I’m about halfway through porting this stuff to C# (in Unity), and so far I’ve devoted part of an afternoon and part of an evening. Now bear in mind that with C# I am using the Mono project’s buggy auto-completing editor, which is probably a slight productivity win versus using a solid text editor with no autocomplete for Javascript (and Unityscript). Also note that I am far from fluent as a C# programmer.

So far here are my impressions of C# versus Javascript.

C#’s data structures and types are a huge pain. Consider this method in my PNRG class (which wraps a MersenneTwister implementation I found somewhere in a far more convenient API):

// return a value in [min,max]
public float RealRange( double min, double max ){
    return (float)(mt.genrand_real1 () * (max - min) + min);
}

I need to cast the double (that results from mt.genrand_real1 ()). What I’d really like to do is pick a floating point format and just use it everywhere, but it’s impossible. Some things talk floats, others talk double, and of course there are uints and ints, which must also be cast to and fro. Now I’m sure there are bugs caused by, for example, passing signed integers into code that expects unsigned, but seriously. It doesn’t help that the Mono compiler generates cryptic error messages (not even telling you, for example, what it is that’s not the right type).

How about some simple data declarations:

Javascript:

var stellarTypes = {
    "O": {
        luminosity: 5E+5,
        color = 'rgb(192,128,255)',
        planets = [0,3]
    },
    ...
};

C#:

public static Dictionary<string, StellarType> stellarTypes = new Dictionary<string, StellarType> {
    {"O", new StellarType(){
        luminosity = 50000F,
        color = new Color(0.75F,0.5F,1.0F),
        minPlanets = 0, 
        maxPlanets = 3
    }},
    ...
};

Off-topic, here’s a handy mnemonic — Oh Be A Fine Girl Kiss Me (Right Now Smack). Although I think that R and N are now referred to as C-R and C-N and have been joined by C-H and C-J so we probably need a replacement.

Note that the C# version requires the StellarType class to be defined appropriately (I could have simply used a dictionary of dictionaries or something, but the declaration gets uglier fast, and it’s pretty damn ugly as it is. I also need use the System.Collections.Generic namespace (that took me a while to figure out — I thought that by using System.Collections I would get System.Collections.Generic for free).

Now I don’t want to pile on C#. I actually like it a lot as a language (although I prefer Objective-C so far). It’s a shame it doesn’t have some obvious syntax sugar (e.g. public static auto or something to avoid typing the same damn type twice) and that its literal notation is so damn ugly.

Another especially annoying declaration pattern is public int foo { get; private set; } — note the lack of terminal semicolon, and the fact that it’s public/private. And note that this should probably be the single most common declaration pattern in C#, so it really should be the easiest one to write. Why not public int foo { get; }? (You shouldn’t need set at all — you have direct internal access to the member.)

I’m also a tad puzzled as to why I can’t declare static variables inside methods (I thought I might be doing it wrong, but this explanation argues it’s a design choice — but I don’t see how a static method variable would or should be different from an instance variable, only scoped to the method. So, instead I’m using private member variables which need to be carefully commented. How is this better?

So in a nutshell, I need to port the following code from Javascript to C#:

  • astrophysics.js — done
  • badwords.js — done; simple code to identify randomly generated names containing bad words and eliminate them
  • iter.js — C# has pretty good built-in iterators (and I don’t need most of the iterators I wrote) so I can likely skip this
  • mersenne_twister — done; replaced this with a different MT implementation in C#; tests written
  • planet.js — I’ve refactored part of this into the Astrophysics module; the rest will be in the Star System generator
  • pnrg.js — done; tests written; actually works better and simpler in C# than Javascript (aside from an hour spent banging my head against weird casting issues)
  • star.js — this is the galaxy generator (it’s actually quite simple) — it basically produces a random collection of stars offset from a log spiral using a gaussian distribution.
  • utils.js — random stuff like a string capitalizer, roman numeral generator, and object-to-HTML renderer; will probably go into Astrophysics or be skipped

Once I’ve gotten the darn thing working, I’ll package up a web demo. (When Unity 5 Pro ships I should be able to put up a pure HTML version, which will bring us full circle.) Eventually it will serve as the content foundation for Project Weasel and possibly a new version of Manta.

node-webkit

C3D Buddy 2.0 in action — built in an evening using node-webkit
C3D Buddy 2.0 in action — built in an evening using node-webkit

I don’t do very much desktop software development these days, and I’ve become increasingly frustrated with Realbasic (now Xojo), so the prospect of forking out $500 for an upgrade that may or may not be usable did not fill me with glee. Furthermore, as the years roll on, there’s more and more functionality tied to the web that desktop-centric development tools struggle to work with.

I was dimly interested in a thread on Hacker News this morning concerning a workflow for developing desktop applications with node. Turns out that the workflow was mostly to do with things like angular and jade, which I’m not especially keen on, and not so much with the actual desktop stuff — the heavy lifting for which is all done by node-webkit. So I started looking into node-webkit.

I like a tool which has you up-and-running in about three paragraphs.

It goes something like this:

Download an appropriate node-webkit binary. (Disappointingly, the Mac version is restricted to 32-bit.)

  • Write an index.html file. (The sample “hello world” app calls node inline.)
  • Write a package.json file. (The documentation suggests it’s like a “manifest” file, but really it’s more like a configuration file.)
  • Zip this stuff into a file into an archive whose name ends in .nw.
  • Double-click the archive.
  • Voila, your app works.

After working on this for about fifteen minutes, I knocked up a bash script (which I turned into a .command file, allowing me to double-click it in Finder) which does the archiving and then launches the file in one step. (It does leave dead terminal windows lying around, and it doesn’t quit the app if it’s still running. I think I may build an app for building apps if I do much more of this.)

And to build a distributable application you can simply put the archive in the application bundle (on the Mac) renaming it “app.nw” or name the file package.nw and put it in the same directory as the application (for those benighted platforms that don’t have bundles). One minor annoyance is that it’s not clear exactly what needs to be changed in the Info.plist file to fully customize your application.

So what is node-webkit? It’s essentially a version of Chromium that puts node.js alongside the DOM in your web pages, along with a few custom HTML and DOM extensions that let you do things like handle platform-native file requesters).

I should note that it’s a potential security nightmare as it stands. There’s no sandboxing (that’s kind of the point), so deploying an app that loads your banking website and then watches you press keys is totally doable. That said, it’s a desktop app so it can also delete all your files or encrypt them and hold them hostage.

Anyway, I had a lot of fun this evening rewriting a utility application I originally wrote in Realbasic a few years ago. It probably took me about twice as long to write it as it took me to do it in Realbasic. Part of that is I know (or knew) Realbasic very well, and I don’t know node very well. Another part of it is that Realbasic is almost always synchronous while node is almost always asynchronous. Writing code that spelunks a directory tree asynchronously is a lot more complex both conceptually and in practice than doing so in linear fashion, but the payoff is quite impressive — despite running an “interpreted” language, a task that took significant time in Realbasic (loading and displaying hundreds of thumbnails) happens in the blink of an eye.

One of the things that’s especially intriguing about node-webkit is that it gives you control over the browser you normally don’t have (e.g. window placement, file system access) — these are a constant usability sore-point in the project I am currently working on (which is a web app that is replacing a suite of desktop apps). It would be so much easier to get a lot of the things we want to do working smoothly using a hybrid desktop application built on top of something like node-webkit — it’s kind of a lemma of Alan Kay’s observation that anyone who wants to write really good software needs to build hardware — anyone who wants to write really good web apps really needs to build the browser.

The github repo for my project is here. It’s not a very general-purpose application; if you don’t use Cheetah 3D it’s completely useless.