My Critique of GUI Systems – Part 1

This blog post is a sequel to the post written earlier this year on my other blog (eDriven.Gui Development Blog):

There’s a thread on Unity forum discussing the next Unity GUI system.

I posted a few posts, criticizing the direction the new GUI system is going to.

Critique is a method of disciplined, systematic analysis of a written or oral discourse. Critique is commonly understood as fault finding and negative judgement,[1] but it can also involve merit recognition, and in the philosophical tradition it also means a methodical practice of doubt.[1]

A tricky subject

This is a very tricky subject though!

A typical game developer doesn’t need (or doesn’t know about) GUI abstractions – the ACS (Atlas-Collider-Script) type of GUI is probably good enough for his needs.

So most of the people consider criticizing the new GUI system as:

1. Over-engineering
2. Trolling

However, I’m being constantly asked for – instead of “only criticizing” – explaining my opinion on how I think the GUI system should be built.

Another GUI system

I also created a GUI system for Unity called eDriven.Gui.


Considering its sales – eDriven was never comparable to many of the “simpler” GUI solutions out there in the Asset Store.

I developed my GUI system making no compromises.

It just had to be perfect and capable of many of the things the other GUI systems (on other platforms) are capable of.

There’s a huge difference between what I (the “business app programmer”) consider a decent GUI system and what an average game developer needs.

Unity like Flash

In my opinion, Unity had a chance to become much more than a game engine, and become a platform.

Much like Flash became a platform, and Flex framework was built on top of it.

Note that in the beginning everyone thought of Flash as the animation tool. It turned out that Flash is a powerful platform, capable of many “serious” things.

Unity really could have become huge in many user interface areas, given its ability of exporting to multiple platforms, and C# scripting (much like Xamarin).

Choosing the easy way out

GUI system architecture is hard.

Creating a well-abstracted GUI system, being robust, recursive and performant is a form of art.

To be able to accomplish these goals, any decent GUI system must be “programmatic” in nature.

One must be able to do anything from code; visual editor is then built as sugar on top.

But I could agree that – for games – the ACS type of GUI could (in most scenarios) be just good enough.

This is probably the reason that Unity took this route.

They gave up building a serious, programmatic GUI system and are focusing on the editor instead.

More read

I’m planning to do a series of articles on GUI subject, covering different GUI technologies such as Flex and also Javascript frameworks (such as AngularJS and WinJS).

The truth is that I’ve been writing about GUIs for years – however my posts have been dispersed throughout the web (and my e-mails).

I decided to “compile” all the existing and future materials to my blog.

Readers are welcome for giving suggestions on subjects I should write on.

In part two of this post, I’m writing about GUI abstractions – and how the other systems I’ve worked with differ from Unity’s approach (and what Unity could have learned from those systems, if they chose to).