Recently I’ve been thinking a lot about how a high-quality ECS would appear \/ present itself within Unity, how it would interact with standard Unity3d game-code at the API level, how it would appear in the Unity Editor, etc. This evening, I had a go at making some of that within Unity itself.<\/p>\n
NB: a few weeks ago I made a small Editor Plugin that used Reflection to upgrade and fix some of the core Unity Editor code\/GUI. That was practice for what I’m doing here. It’ll hopefully appear on the Asset Store at some point (pending review right now!) – it has the full source unobfuscated, so you can see for yourself both what<\/em> and how<\/em> I got it to do its clever bits.<\/p>\n <\/p>\n Some things to read if you haven’t already:<\/p>\n (that last one is particularly important; working around Unity’s broken Serialization system is a whole mega topic in its own right, and I’ll be largely assuming you already have read up on it. If you don’t know Unity Serialization yet (enough to fear it!) go read that article)<\/p>\n There’s been one thought in particular nagging away at me for a while now:<\/p>\n \nIf we’re going to really, truly, genuinely replace Unity’s core scripting architecture (which sucks for game development) with a modern ECS one, then we MUST create a new custom panel for the GUI Editor.\n<\/p><\/blockquote>\n …until \/ unless we do that, it’s just a Programmers’ Circle Jerk: it loses 90%+ of the audience of Unity developers, people who chose Unity because of the Editor. 1st-class Editor integration is more important than anything else (certainly a lot more important than – say – performance).<\/p>\n If the scene changes, we’ll be looking at a new Entity System (different entities, different components). You would naturally expect that Unity automatically repaints all windows when Unity changes the Scene, right?<\/p>\n Wrong.<\/p>\n (incidentally, this is why it’s also very hard to be sure that a scene has actually loaded when you double-click on it – Unity gives no indication to the user that anything changed, if the Hierarchy for the two Scenes was the same)<\/p>\n The undocumented method “EditorWindow.OnDidOpenScene()” which you can override. Amusingly, in Unity 4.5 they “fixed” the “bug” that this was documented; now your only way of discovering it is by finding a Mystical Unity Guru who knows The Secrets of Unity.<\/p>\n This isn’t even funny any more…<\/p>\n public class EntityID : ScriptableObject … you have to manually write a serializer and deserializer for System.Guid. Because C# built-in structs weren’t considered important enough to be supported by Unity. WTF!!!??!??<\/em><\/p>\n We know why: it’s because Unity Serialization is crap.<\/p>\n Unity Serialization requires every class to use a zero-argument constructor and has a bizarre array of hacks to try and restore state.<\/p>\n If – for instance – you need to create a ScriptableObject and guarantee that it gets an internal globally unique ID … you can’t. C# supports it, but Unity removes that support. Joy!<\/p>\n New discoveries:<\/p>\nReferences<\/h2>\n
\n
Initial thoughts\/plans<\/h2>\n
Core Unity bugs that got in the way<\/h2>\n
Unity never repaints windows when Scene changes<\/h3>\n
Workaround to Unity bug<\/h4>\n
ScriptableObject: fundamentally broken<\/h3>\n
ScriptableObject System.Guid properties are wiped by Unity Serialization<\/h4>\n
\n{
\npublic System.Guid GUID = System.Guid.Empty; \/\/ this will NEVER be saved by Unity
\n}<\/p>\nScriptableObject breaks C#: no constructors allowed, no initialization allowed<\/h4>\n
ScriptableObject data loss<\/h4>\n
\n
\n
\n
\n