Shawn asked on Twitter:
We only get to pick ONE? :).
How do we decide?
There’s two ways to slice this. There’s “private APIs that would hugely benefit us / our projects / everyone’s projects / 3rd party code that I use (e.g. other people’s Asset Store plugins I buy/use)”. We can judge that largely by looking at what private API’s I’ve hacked access to, or decompiled, or rewritten from scratch.
Then there’s “what CAN’T I access / hack / replace?”. That’s a harder question, but leads to the truly massive wins, I suspect.
Stuff I’ve hacked access to
The Project/Hierarchy/Scene/Inspector panels
So, for instance, I made this (free) little editor extension that lets you create new things (scripts, materials, … folders) from the keyboard, instead of having to click tiny buttons every time.
There are no public API’s for this; that’s a tragedy. Most of these Unity panels haven’t been improved for many years, and are a long way behind the standard with Unity’s other improvements. They “work”, but don’t “shine”.
What could I do with this?
Well … a few studios I know have completely rewritten the Scene Hierarchy panel, so that:
- it does colour-coding of the names of each gameobject
- clicking a prefab selects both the prefab and any related prefabs, or vice versa, or hilights them
- added (obvious) new right-click options that are missing from default Unity Editor
- automated some of the major problems in Unity’s idea of “parenting” (parenting isn’t always safe to do; you can enforce / protect this with a custom scene hierarchy)
- made it put an “error” icon next to each gameobject that is affected by a current error.
- …etc
All massively useful stuff that helps hour-to-hour development, reducing dev time and cost.
It’s all “possible” right now by writing lots of horribly ugly and longwinded boilerplae code, and using the antiquated Editor GUI API.
But to make it play nicely with the rest of Unity requires also hacking Unity API’s for the various panels/windows, and detecting popups (and adding your own popup classes, since Unity keeps most of theirs private), and detecting drags that started in one panel but moved to another, detecting context-sensitive stuff that is not exposed by current API’s, … etc.
A better List editor
The built-in sub-editor (like a PropertyDrawer – see below) is very basic – really a “version 0.1” interface.
There is a much nicer one, that does what most Unity developers need – but it’s private and buggy (last time I tried, it corrupted underlying data. That’s presumably why it’s still private?)
Editor co-routines
Co-routines work perfectly in the Editor. (EDIT: thanks to ShawnWhite for the info): Unity doesn’t use co-routines outside of runtime; what appears to use them is OS-provided multi-threading. Strangely, when using that, I haven’t seen any of Unity’s ERRORs that are usually triggered by accessing the Unity not-threadsafe code from other threads – something weird happening in the OS?
Why doesn’t Unity support co-routines in the Editor?
I’ve no idea. There are many people who’ve re-implemented co-routines in editor, exactly as per Unity’s runtime co-routines. As a bonus, you end up with a much better co-routine: you can fix the missing features. But there’s some strange edge-cases, e.g. when Unity is reloading assemblies (which it does every time you save any source file), for a few seconds it presents a corrupt data view to any running code, and you if start running a co-routine in that time, it will do some very odd things.
Unity recently exposed some API’s to detect if Unity was in the middle of those reloads, but last time I tried it I couldn’t 100% reliably avoid them. An official implementation of Unity’s own co-routine code, that was automatically paused by Unity’s own reload-script code, would neatly fix this.
Until we have something like that, we’re forced to write two copies of every algorithm (C# doesn’t allow co-routine code to be run as a non-co-routine) so we can test in Editor, do level editing, debug and improve runtime features, etc … which is silly.
Stuff I CANNOT hack into/around
Serialization
Unity is the only engine I’ve worked with where the core data structures and transformations are opaque, hidden, can’t be extended, can’t be debugged. Tragically: also has many missing features, bugs, and serious performance issues.
There are good reasons for why this remains in such a bad state (It’s hard to fix. Meanwhile … it sort-of works, enough to write games in – you just have to occasionally write a lot of bad code, have to rewrite some ported libraries, have to know a lot of Unity-specific voodoo, etc).
But if it were exposed – we could (I would start on it tomorrow!) fix most of the problems. I’ve done proof-of-concepts with some terrifying hackery that show it’s possible – and a lot of the architecture is well explored, other ways it can be implemented, that could be given to developers as options (some would work better for your game, others might not; but you could pick and choose).
It’s too much to ask for (it intersects so much of the engine, and it would unleash a horror of potential bugs and crashes), but my number 1:
Callbacks for ALL core Unity methods
This sounds small but would have positive impact on a lot of projects.
c.f. my reverse-engineered callback diagram for EditorWindow in Unity:
…but we have the same problems for MonoBehaviour, for GameObject, etc. Not only are lifecycles poorly documented, but they’re inconsistent and – in multiple places (c.f. above diagram “Open Different Scene”) – they’re not even deterministic! It’s random what methods the Editor will call at all, let alone “when”.
Under the hood there must be reliable points for doing these callbacks … somewhere.
Undo
Undo has never worked in Unity. The worst stuff I narrowed down to ultra-simple demos that Unity’s own code was broken, I’ve logged bugs and Unity fixed them – but the current system is a horrible mess, much too hard to use. Many methods only randomly do what they’re supposed to, and there’s no way to debug it, because the internals are hidden.
If Unity exposed the actual, genuine, underlying state-change points, we could correctly implement editor extensions that support Undo 100%. I’d be happy to also use them to write an Asset that implements “easy to use Undo”, based on how other platforms have implemented it (e.g. Apple’s design of NSDocument is pretty clear and sensible, based on lists of Change Events).
Unity could then make “Undo that works” a mandatory requirement on the Asset Store. Currently it’s listed as mandatory, but no Asset has ever been checked for it (so far as I can tell).
Not least because Unity’s own code has had such problems supporting it!
PropertyDrawer: doesn’t quite do what it claims to (yet)
Recall what I said above: most of the Editor GUI/UX itself “hasn’t been improved for many years”. Unity made it user-extensible/replaceable many years ago – so in theory you could update / replace whatever you want. There’s a huge amount we’ve been able to update and customise (although it’s very expensive in coding time, due to a lack of modern GUI API’s, sometimes it’s well worth it).
But you can only replace the Inspector for a particular Component/MonoBehaviour. You cannot say “I want to replace the Inspector for GameObject’s that have Components X Y Z”.
Worse, if you wanted to replace e.g. the part of the Inspector that automatically draws a Vector … you can’t.
Unity had a great idea to solve one of these: Property Drawers. These would let you customise the rendering of sub-parts of an Inspector – the rendering of individual labels for member variables, list items etc.
IN THEORY this would let you write your own list-renderer that would work everywhere, and make lists very easy to use in the Editor – but only write the code once.
IN PRACTICE it was only implemented in a very basic way, and most of the things you want to use it for are blocked / inactive. There is NO WAY to fix this in user code.
(well, actually there is … c.f. . But this is a horrendous amount of work – AI’s author did a Herculean task! – and means you’ll never the benefit of future Unity UX / GUI updates, if there are any).
So: big upvote for exposing more of PropertyDrawer
