This week I’m paralysed on some of my simplest decisions while happily making complex decisions quickly, and being incisive and highly effective on others. This problem occasionally crops up in my work and personal life, and it frustrates the hell out of me; I’m going to write about it here, see if it helps me find a new way forwards. Hopefully this may also help others who’ve experienced a similar problem in their own lives.
(One of a series of posts about converting Unity3D into a 1st-class Entity Component System. Read others here)
It’s a year and a half since I wrote about choosing Data Structures for high-performance Entity Systems in A-AAA games. I always had a followup post in mind, but never wrote it down (thanks largely to the demise of #AltDevBlog). These days I’m too busy to write such big articles, but it’s long overdue … This post is a shorter version of what I had planned, but should have enough to get you going in the right directions.
(One of a series of posts about converting Unity3D into a 1st-class Entity Component System. Read others here)
How to store game data: GameObject? MonoBehaviour? ScriptableObject?
Those three pillars of Unity’s architecture are the curse of game implementation and performance. Architecturally, they’re great: they’re a big part of what makes Unity easy for newcomers to pick up and understand within hours, instead of taking weeks.
On large Unity game projects, they’re hated for being slow and hard to work with when you get to hundreds of thousands (or millions, tens of millions, …) in a single scene. Unity provides zero tools and support for this situation – it just gets harder and harder to work with, and slower and slower to run.
In Entity Systems world, we hate them because they are inherently slow and buggy – no matter how great Unity’s coders, they’ll never make them work as well as our preferred approach (See below).
But … replacing them forces you to replace most of the Unity Editor!
Most of the features of our Entity System need new Editor GUI anyway. If we’re going to be adding big chunks to the editor, replacing GO/MB/SO is going to be much cheaper than normal. And it potentially has huge benefits that are independent of the Entity System.
If we’re going to replace them, what will we replace them with? Custom versions that have almost the same name and work the same way? Or something very different?
What is Unity’s ‘GameObject’ anyway?
As far as I can tell, the real meaning of GameObject is:
def. GameObject: Something that exists inside a Scene, and has a Position, Rotation, and Scale. It can be “embedded” inside any other GameObject, meaning that any change to the other object’s Position, Rotation, or Scale gets merged onto this one. It’s the ONLY thing that can have Unity “Components” (MonoBehaviours) attached to it. Anything that is not a GameObject, and is not attached to a GO, gets deleted every time you load/reload/play/resume a Scene.
From a code perspective, looking at the backend systems, there’s a lot more to it. The GameObject (GO) has a slightly weird name, when you think about it. You use it so much during Unity dev that you stop noticing it. “Game … Object” … wha?
Other purposes GameObject serves
Here’s a few obvious ones (I’ll edit later if I think of more):
- Guarantees everything has the GetInstanceID() method
- Needed for Unity’s Serialization system to work (because of how it’s been designed, not because serializing requires this – C# has built-ins that would have done the same job)
- Enables the Editor to “select” anything in any tab/window, and that thing is ALSO selected in all other tabs/windows (e.g. click in Scene, and the Inspector updates to show the components on that thing)
- …probably loads of other things. It’s so commonly used I hardly notice it
- When doing in-Editor things, Unity can often “ignore” classes that are “not part of the game, because they don’t extend GameObject”
- Reading between the lines of official docs, and simplifying vastly, this is what happens behind the scenes. Especially with Serialization, I suspect.
- This can be a huge pain. It’s hard to debug code when “GameObject subclasses” magically behave differently to “all other classes” with no indication of why
- Since every GO has a Transform … you can do automatic, general-purpose, high-quality, Occlusion Culling
- NB: for this to work perfectly, you’d also want every GameObject to have a .bounds variable. Why did Unity’s original architects leave that out? Dunno, sorry.
How to store game-data: the Entity Systems ideal way
We know this, it’s been discussed to death: if your programming language supports it, use structs.
By definition, structs are the most memory-efficient, CPU-efficient, multi-thread-safe, typesafe way of storing data, bar none. There is no better way to do this in mainstream languages. C# and C++ both support structs; I think we have a winner!
There are probably some awesomely clever advanced Math ways of doing things better, or by using raw assembler and code optimized for each individual CPU on the market. Or, or … but: in terms of what’s ‘normal’, and commonly used, this is the best you’re going to get
But how will this work in practice? What about all the “other” roles of GO etc in Unity?
Structs in … Identity (GetInstanceID)
Simple ECS implementations often hand-around raw pointers to their Components; that gets messy with Identity.
But most (all?) advanced implementations have some kind of indirection – a smart pointer, or an integer “index” that the Component Storage / Manager maps internally to the actual point in memory where that lives.
If we turn that “advanced” feature into a requirement, we should be fine.
Structs in … Serialization
- Start writing your own version of the Unity Serialization system that only uses structs
- Finish it the same day
- Discover it runs 10 times faster than Unity’s built-in one
- …with fewer bugs
Structs are the easiest thing you could possibly try to serialize and deserialize. Unity coders probably wish that they could restrict us all to structs – it would make their live much easier in some ways.
User-written structs: special rules?
Do we need to add special “rules” to user-written structs that appear in the game?
Nope! It turns out that C#’s built-in Reflection system is able to inspect every struct, shows us every field/property/etc, and lets us easily read and write to them. Both private and public.
CAVEAT: structs break C# .SetValue()
A little care is needed when we implement the Entity System internals. But it has no effect on user code / game code.
Structs in … SceneView (Transforms)
No! Just … NO!
This is one of the architectural mistakes of Unity we’re going to fix in passing: we won’t require everything to have a Transform.
However, it foreshadows a more subtle problem that we’ll eventually have to deal with:
Entity Systems are a table-based/Relational/RDBMS way to store and access data; such systems are very inefficient at storing and retrieving tree-structured data (e.g. OOP classes + objects)
The transform hierarchy in a Unity scene is a massive tree. As it turns out, it’s bigger than it needs to be (because of that law of Unity that everything must have a Transform) – but we uses trees all the damn time in game-development. So it’s a problem we’ll have to come back to.
Bigger storage: where do the structs live?
Fine; at the lowest level, the individual ECS Components, we’ll use structs.
But how do we store those?
Choosing the right aggregate data-structures for your ECS is a major topic in itself. C# gives us (almost) total control of how we’d like to do it – plenty of rope to hang ourselves with.
At this point: I’m not sure.
As a temporary solution, I’m going to focus on making the storage-system swappable, so that I can implement a crappy version quickly, and then easily swap-it-out with something much better – without having to rewrite anything else.
Does it work?
Yes. I tried it – I wrote a complete replacement for the Unity Inspector tab that only works on Entities-with-Components, where “Component” is any struct. Ugly, but it works:
Everything there is auto-generated (including the colour; every struct gets a globally unique background colour, which I find makes it much easier when you have hundreds or thousands of Component types).
The only tricky bit was the problem with C# FieldInfo.SetValue(…), as mentioned above.
…some things I might want to pick up on in future posts:
A first-class Entity System for Unity3D
Unity is a great 3D engine and a good editor – but the programming environment is 10-15 years behind the curve. Entity Systems are a much better way of writing games, but they are surprisingly difficult to add to Unity.
I’ll bring the latest in modern ES techniques to Unity, turning parts of it from a “weak” programming environment into “one of the best”. In game-engine terms, this will put it far ahead of the pack.
This blog post is testing the waters:
- You can give me direct feedback on the proposed contents/scope
- I can start to see how much interest there is in making this
First round of feedback
A lot of people read this and got the impression I was going to charge them extra for the final product, and provide a library with no tutorials. Big confusion and misunderstanding! So, I’ve reworded those bits to be clearer.
Kickstarter: planning the campaign
Target Audiences (Expected)
I think I have four target audiences:
- Newbie devs, and non-programmers (artists, designers), who find the “coding” parts of Unity overwhelmingly difficult today
- Unity devs who’ve never used an Entity System on a real game project, and don’t know what they’re missing. They may have a lot of experience (shipped multiple games), or none (University/College students).
- Small Indie teams / sole coders who’ve used Entity Systems elsewhere, and feel that coding in Unity is slow, error-prone, boring, frustrating, and time-wasting by comparison
- Large Indie teams whose games won’t work in Unity because Unity is so bad at scaling to large projects. They’ve already re-written or replaced substantial chunks of Unity’s core so that it’ll work fast enough / reliably enough.
Types of Reward
Reward type 1: Discounted License
Everyone who backs the KS gets a copy of the library / license to use it. By backing the KS (at any level) you’re getting a substantially cheaper purchase compared to the final launch pricing on the Asset Store.
There might be some options here for different team sizes, different levels of support, etc.
Reward type 2: Expert Knowledge
When you have non-trivial questions about ES design and usage, it’s hard to get the attention of experts. They’re usually experienced, older, programmers with young families, or working in senior jobs. They have little free time.
Big developers fix this by hiring experts for a few days at a time. But small teams/individuals can’t afford the “entry” cost – as a Consultant, you need to charge at least $5,000 per engagement to cover all the admin overhead and hidden costs.
So, we have some options here to give everyone this kind of access.
Reward type 3: Source Code
In mainstream IT, when you purchase a library you rarely (if ever) get the source code. If you find bugs, or missing features, the vendor works hard and fast to fix them for you.
In the games industry, it’s the other way around: vendors take no responsibility for the code they’ve sold you, and in return … they give you full source access. “Fix it yourself, dude!”
If I let everyone have source, it raises my support costs. With each change, it won’t work for some people – because they’ve modified their copy – and I’ll have to help them update it.
On the flip side: Source code is your “Plan B” in case I get sick, or sell-out, or lose interest in the project, etc. It also gives you an easy way to add features of your own and send them back to me (which I then take on responsibility for maintaining).
I’m offering this, but it’ll be a high-cost. The teams that really need it should have no problem justifying the cost.
Types of Stretch Goal
To clear up confusion: these are things that would be present in the core product (e.g. the GUI is going to be a major part of the library!), but stretch goals would allow me to add extras to each of them.
Goal type 1: Editor GUI
In my experience the biggest effect on programming speed – once you get past your innate ability + level of experience – is the quality and “friction” of your tools.
As soon as you go beyond the simple stuff it’s damn hard to extend the Unity editor. But I’ve been hacking the Editor for a few years now, and I’m willing to do pretty much anything. Especially if it makes it easier to make games with!
Goal type 2: Example Games
The core will have some form of tutorials, but it probably won’t have a complete demo game.
Writing a game just to demonstrate an API is extremely time-consuming, and it’s not what you’re paying for when you buy the library.
But … it’s also a great idea: it improves the quality of the API, by giving me a reference product to check everything is as easy-to-use as intended. So I’d like to write one (or several), but I can’t do that on the base funding.
(Aside: If I ran the technology division at Unity corp, they’d be writing and publishing games every quarter)
Goal type 3: Tutorials
There will be tutorials with the core library. They’ll cover the basics of how to use it.
But … I’d like to go further, and do tutorials for every aspect. I’d like to do a written tutorial for everything, and I’d like to ALSO do a video tutorial for everything (some people only use written tutorials, other people only use videos. I’d like to make it great for both groups).
With a new library, tutorials are extremely expensive to write. Minor changes to the API – bug fixes, refactorings, feature additions – invalidate whole pages of tutorial at one stroke.
Pricing and Funding levels
These are approximate based on extrapolations of cost and expected “version 1.0″ feature-set.
- License: $50-$150 (after launch, general public can buy at $200-$400 in Asset Store)
- Source code: $300-$1000 (various amounts of support)
- Access to experts: $150-$750 (various levels of privacy + interaction)
UPDATE: One person has stated they would “never pay these prices”. That’s fine – they’re way outside my target audience. I’m more likely to increase these prices than decrease them. If you know what an ECS is, and understand the value, this is probably too cheap already.
This is what it’s going to cost to build:
- Minimal version that’s usable in most game-dev: approx. $15,000
- My preferred v1.0: approx. $75,000
- High-quality version for large games: approx. $200,000
I can write-off about 50% of the cost as this is a project that I need and will use myself – and it’s a labour of love. I can also add a %age in expected additional sales that happen naturally after the campaign has ended (from the Asset Store, etc).
But Kickstarter takes a cut, and the government takes a cut, and Amazon takes a cut. In the end, I need a KS campaign to raise something like:
- Minimal funding: $5,000
- Preferred funding: $30,000
- High-quality funding: $75,000
Who are you, anyway?
In case you don’t know … I’ve run Technology/Development for a couple of game companies (e.g. Mindcandy, NCsoft Europe). My StackOverflow score is somewhere north of 20,000. I’ve contributed to a few open-source projects, but the one I’m most active on is the SVG rendering library for iOS and Mac, where I’m the project lead and one of the top 3 contributors.
I started writing about Entity Systems back in 2007, mostly because I was frustrated that so many game studios were “doing it wrong”.
What I’m doing now
I teach non-technical people how to program. I work with schools, teachers, and directly with children/adults. I invented a new system of programming using physical objects and toys.
Working with a local school, I’m making a new course where I’ll be teaching children “how to make games with Unity3D”. I’m particularly interested in what I can do to the Unity Editor to make it more user-friendly and better for use in the classroom.
Depending on how this goes, I have a few people in mind I’ll hire to share the burden of writing this library. It’s something I need both in my day-job and in all my personal game projects. Doing it as a Kickstarter gives me the excuse to spend 100x as much time and effort on it as I would otherwise, and gives me a much better library than I’d get on my own.
I suck at Marketing. The biggest risk factor to this project is that I fail to make enough noise, and hence there’s too little money coming in to pay for the ongoing development and support. As a result, dev gets sidelined while I pay the bills.
A Kickstarter is my way of testing “can I find a critical mass of people who need this project, and get them to put their money where their mouth is?”.
It’s going to be hard – I suck at marketing – but to be honest I’m leaning heavily on the idea that this is something people want badly enough they’ll help me market and promote it. With KS, there’s no risk to you for helping here … if the campaign fails, you pay nothing. If it succeeds, I get enough cash (and enough users!) to guarantee development through to a production-ready version.
Are you in?
Sign up here to be kept up to date on the project Kickstarter (if you’re already signed up, it won’t add you again)
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.
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 and how I got it to do its clever bits.
In Unity, hundreds of times a day you do “new (folder)” or “new (C# script)” etc. But Unity makes this ridiculously hard: you have to hunt and peck a tiny button and then hunt-peck a tiny item in a huge dropdown that is very easy to miss.
And you can’t do any of this from the keyboard. Even though you’re fully in keyboard mode and about to write the name of the New Thing (required!) and if it’s a script: type in the source code.
UPDATE: Now available in Asset Store – get the source
Source is included. If you want to see how I did it, knock yourselves out…
My context-sensitive New for Unity
So, what I’ve made today:
- Select any folder or object in the Project window
- Hit “shift-N” (because Unity sucks and steals Ctrl-N and refuses to let you choose a better one. Stupid stupid stupid.)
- A popup appears pre-filled with a sensible new file name OR folder name
- If you were on a folder, it prepares to auto-create a new folder
- If you were on a script file, it prepares to auto-create a new script
- The name is pre-selected and editable, exactly as with Unity built-in
- Sometimes that intelligent guess above will be wrong, so … hit Tab, and it switches type, while keeping the text selected and editable
Net result: super-fast workflow for creating new scripts and organizing your project.
(This required an ungodly amount of hacking and trial and error to work around bugs, bad documentation, and obvious missing core features from Unity APIs. But it works, and seems to be pretty seamless now)
A subset of the things I discovered / re-discovered on the journey to this one small fix / improvement:
- AssetDatabase.CreateAsset is basically broken: can’t create C# scripts at all. Don’t try.
- ScriptableWizard is unusable in Unity less than 5.0, because they made a core method private / non-overridable. Don’t bother.
- You can find the Project window and others by doing a reflection on the Assembly to find the magic C# Type of known Unity private classes (that SHOULD BE public!) and comparing at runtime. Hoops? Jumping through? Because an API has something private that should have always been public? Welcome to Unity customization! :)
- You can find the exact position of the selected row by adding yourself as a callback on Unity’s own row-by-row rendering of their built-in windows, and saving the data every frame. Sounds scary; works great (one of the few bits here that is a perfect hack with no downsides)
- Popups need you to create a new class, and that class MUST BE in file of its own or you will break Unity (internal bugs in Unity window management that trigger when you reload/restart Unity)
- …if you trigger that bug (or in any way end up with floating, non-closeable windows), go to the Layout menu and re-select the layout you’re already using. It will kill any unexpected windows. Phew!
- Unity still hasn’t made the Indent width (in pixels) public. The documentation insults you by saying that when you hardcode the number 20 this will break your code in future. YES, WE KNOW. SO MAKE THE DAMN NUMBER PUBLIC, YOU BASTARDS.
- There is a 2 pixel top and bottom padding needed to surround textfields in 1-line popups. I hardcoded this, it may have a number somewhere in the API. Good frickin’ luck trying to find it. Given the taunt about indents above, I very much doubt it is public.
- If you have a button or non-editable textfield with a changeable title, or anything that can be changed by a keypress during rendering, it is critical that in OnGUI you read Event.current.type and switch() on it. As far as I can tell, this has never been documented except in forum threads and blog posts by Unity staff. Once you know about it, you can sort of guess it from reading the undocumented bits of the API, but it’s damn hard to find references to it online. (I found it years ago by trial and error and blind luck). Until you do this you get race conditions when changing GUI based on keypresses. Ugh.
Critically, this (should) work no matter how much I customized Unity elsewhere. It’s peeking into the actual window and render areas to decide what to popup and where on screen.
The only conflict I expect is one that – thanks to some brainfart design at Unity corp – we can’t workaround: I had to hardcode “shift N” as the keyboard shortcut :(.
Want it yourself?
I thought it would take me about 10-20 minutes to do. HAHAHAHAHAHAAHAH! If I’d done this as a client project, I worked out it cost almost $1500 in billable hours. Ugh.
I’m going to use this in production for a while. If it continues not to break or corrupt anything, I’ll put it on the Asset Store.
…I’m going to do some context-sensitive New for the Hierarchy window, I think. Now that I have these hacks working, that’ll be quite a lot easier.
Added a level-select screen:
I say “level-select”, but … that background is a full 3D terrain, and the cities are procedurally generated/unlocked, so … it’ll hopefully become something a lot more, eventually.
Here’s a game:
- Gun 1
- Gun 2
- Gun 1
Some of those are 3D visual objects: Player, Gun 1, Gun 2.
Some of those are abstract concepts, or data: Inventory, AmmoHolder.
(in a Diablo clone, the Inventory might be a visual object, but only when you bring up the popup-window to display it. By contrast, in a simple FPS, your inventory may not be displayed at all – no need for it!)
Unity cannot handle this situation.
What you need
In Unity, you have to make “everything” extend MonoBehaviour. That’s fine for PlayerClass and GunClass: you make a dummy GameObject for each, place it into the scene, and attach the class as a Component.
But that’s impossible for InventoryClass and AmmoHolderClass: if you make them into MonoBehaviours, Unity prevents you from using them as standard classes any more:
- Cannot instantiate them
- Cannot use Garbage Collection
…because they have no GameObject to be attached to – they don’t exist! They are abstractions only.
This is core to programming: we use abstractions all the time. Without them, coding would be horrendously inefficient both for the programmer and (to a lesser extent) for the computer.
What Unity offers
You have three alternatives here:
- Create fake GameObjects anyway. Put them “somewhere”. Work really hard to make sure they never accidentally appear in front of the camera (!), or interact with the scene due to physics (!), etc
- Use plain C# classes. This is an extremely bad idea: Unity has never supported C# classes for anything; Unity has a custom memory-management solution (called, slightly confusingly, “Serialization”) which is incompatible with plain C#. It requires every object to extend Unity.Object. You can workaround this; it requires major work and is very hard to get right.
- Use ScriptableObject, which appears to have been invented for this. According to many Unity developers: “this is what ScriptableObject is for”. However, that’s wrong. Very wrong.
ScriptableObject to the rescue?
So … ScriptableObject is something that extends UnityObject (fixing the problem of “plain C# classes aren’t compatible with Unity”), and you can use in a Scene, and can be referenced by MonoBehaviours, and just work, right?
ScriptableObject is all those things, except: it doesn’t exist in the Scene. It’s an Asset.
This is where Unity docs really screw the pooch. We know for a fact that an SO is an Asset; when we try to use it like a MonoBehaviour, several things break and stop working.
…but it also “kind of” works in-Scene. The docs have no explanation for this. What are the limits? Well, basically: no-one knows, except through trial and error. This is so core to your code that it sometimes instead means:
trial and oh-crap-that-didn’t-work-time-to-rewrite-every-damn-class
Why is Asset-hood so bad?
You already have all that – it’s called the Class – and to have an Asset too simply creates problems:
- An Asset is a special thing in Unity. It interacts with Unity’s core systems in very different ways to a C# object. Building, runtime Loading, editing in the Editor – all are “different”.
- You can’t create them in the Editor. (you can write your own hack/script to fix this. It’s only 10 lines of code. But … yeah. It’s a hint that this isn’t what Assets are intended for)
But .. what’s ScriptableObject for?
Unity’s official docs are rather … incoherent … on the subject. My guess is that they were written by someone who didn’t really understand ScriptableObject, and was looking at the source code thinking:
WTF is this? Um. Err. Well … it kind-of seems to sort-of do … this? Maybe?
…and worked it out from observation.
What the docs are TRYING to say is:
(gross over-simplification here to make things easy to understand): Unity’s memory-management COPIES every instance many times, and doesn’t support pointers/references.
This is a HUGE problem in game-development.
ScriptableObject is a workaround that uses diskspace to make templates out of objects, and then simulates pointers by using one shared-file on disk to hold the data for thousands of in-game objects.
This works very well, because the way we built Unity’s core architecture (3D Meshes, Textures etc) already supports that workflow: File-on-disk generates optimized in-memory-object, which is shared/batched wherever possible.
Going off on a tangent, it waffles about “ShopStore” and “Multiple Scenes” and stuff that the author clearly didn’t really understand. The obvious way of implementing what’s described in the docs is many times simpler, and works much better – you would never do it using ScriptableObject.
What the docs perhaps should have instead said was:
You can also abuse this system to make hardcoded fake in-scene objects that don’t have to be attached to a GameObject.
This will fail if you have any Procedural Content – but Unity was specifically designed never to be used in games that have procedural generation, and no-one should be doing procedural work in Unity, so that’s fine.
Wait … what? What do you mean “we all do procedural generation”? Wh … why? Why would you do such a thing? do you have any idea how slow that will be in Unity? Most of our code assumes everything is done at compile time! We can’t handle dynamic code!!!
(NB: Unity used to be really, really bad at procedural work. Way too slow. There’s really no reason not to be doing tonnes of procedural code in Unity games today – except that Unity itself still has a load of political blocks on it. It doesn’t support procedural properly in places where it could)
ScriptableObject is great, but most game-development works with procedural content. I’m not talking about complex cool stuff like Sir, you are being hunted. I’m talking about stuff like:
The set of objects in your inventory changes from moment to moment while you play the game. Because otherwise it would be a pretty boring game
When you try to use ScriptableOject here, you are abusing it. It’s not intended for that, it doesn’t work correctly with that, and it’ll make your life hard. IT’s not ScriptableObject’s fault; it’s your fault.
What does Unity need?
At a conceptual level, Unity has:
- “Physical Runtime objects”: things that have 3D physical presence in the editro (not Physics as in “Physics Engine”, but rather: everything has a Transform)
- “Runtime OOP Objects, dependent upon GameObject”: generated from OOP Classes (but MUST be attached to a Physical Runtime object)
- “Compile time OOP Objects”: these are Unity Assets, and can be used for some performance and coding tricks. They are they poorly-documented ScriptableObject, and should probably have been named ScriptableAsset in the first place since they are absolutely not Objects!
- “Runtime OOP Objects, independent of GameObject: the classic “Object” from OOP.
I think … not sure, this seems obvious, but if so: why is not already the case? … I think: Unity should be saying “make your classes extend ‘Unity.Object’, and then use them. All will be fine. We’ve made it work under-the-hood; trust us, guys, it’s cool. Everything’s cool.”.
My guess is that’s some internal bug with Unity Serialization that makes this untractable. Maybe something like:
GUESS: Unity Seriailization is internally hardcoded with a fixed number of recognized classes, somewhere, that can only be added to by hardcoding new ones. Because we don’t have access to Unity’s source code, we cannot re-generate those, and the Unity Editor (for same reason) can’t do it for us.
So: our legitimate C# classes can never be fully treated as a Unity Class.
Instead, Unity has to support a fixed number of hardcoded classes (O hai! ScriptableObject, MonoBehaviour), and those have to use reflection tricks at runtime to provide (limited) support for the infinitely many user-authored clases from C#.
OK, so this is slightly more than a “guess”. They have form here: When trying to figure out some obscure Unity Serialization bugs, I found some places where Unity would load extra, hidden, information for particular Unity classes. There was nothing in memory on this, suggesting that they had hardcoded a lookup for their set of “known” Unity classes, and were getting the data that way.
…but that’s the kind of thing that’s going to be a genuine mind-f*ck to try and unravel. This makes me inclined towards it: even with the money and resource Unity has, it would be non-trivial to fix. And I’m pretty sure no-one likes the status quo.
We’ll just keep writing source code like it’s 1999:
- Use C# as if it’s C
- F*ck Garbage Collection (we can’t have it :( Sob.)
- Manually memory-manage the scene and objects; make everything a GameObject, and manually Destroy() everything each time you replace it or it goes out of scope
- As a bonus: the Unity Editor has much better support for Developing and Debugging games which use GameObjects than it does for any alternatives (C# Classes; ScriptableObjects)
I’m crossing my fingers that Unity version 6 will dump Serialization, and this problem will go away. Like magic, Unity will fully support C# (Dictionary’s! Objects! Garbage Collection! YAY!)
…of course, by then, I might have finally switched to Unreal. Because frankly I’ve got better things to do with my life than work in low-level programming languages!
OpenOffice is great. It has flaws. One of the most insidious is that the “new document” settings for Word/Letter documents is vile. It has truly awful formatting – ARGH! MY EYES!
Today I was writing a doc to put down some thoughts for colleagues, and I realised that the formating is so unbearable it was actively blocking me from thinking or expressing myself clearly. Every glance at the words in front of me was corrupted.
So, I’m going to do some experiments in replacing it with something … “not s**t”.
Download a template
Not possible. The OpenOffice.org website has never worked – I’ve been using it for 10 years, and the Template Search is still 100% broken. “Sort by rating, Descending” and the top-rating is often … 0/5 stars. Um. No. Guys – can you please learn how to count to 1?
Screencap from today:
Make a template
Here’s the steps, if you want to do one yourself: How can I change the defaults for a new Writer document?
Attempt 1: Verdana, indents
Arial – especially using Arial Bold for every-other-heading – is painful on the eyes when a document has more than about ten words. Let’s dump that and – sticking with a common font everyone has installed, but is similar in look – go with Verdana.
I do not enjoy using Arial, Verdana, Helvetica etc in docs; but I have no idea how funky you can get today and still get 100% coverage of “this font is installed on everyone else’s computer, no download/import/conversion needed”
Looks like this:
DOWNLOAD LINK: Default Text (Verdana)
There’s a circle of hell set aside for the muppet working at WordPress who decided to block all files that he/she couldn’t be bothered to type into a pointless – BUT NOT UPDATEABLE – whitelist of filetypes.
That’s not what a filename extension is. It’s not what a filetype is for. Great example of “a little knowledge” (or in this case: no knowledge at all, just foolish assumptions) being a dangerous thing…
How do you program a “level”?
This is not usually a problem in a game engine, but Unity requires you to isolate each “level” as a Scene. And Unity’s Scenes have some strange design choices (bugs?) – IMHO they were designed for toy projects, not for production games.
Here’s a stream-of-consciousness on what works, what doesn’t, and how I can workaround / do it better within Unity… it’s not carefully researched, mostly it’s from memory / off the top of my head. So … it might not all be true :).
When I switch to Unreal4, I’ll be using posts like this as a baseline to compare where Unity failed, and how badly – or vice versa.
UPDATE: added some more approaches and ideas/commentary
This one has annoyed me for years: Unity’s OnMouseDown has never really worked. (NB: it works perfectly if you make a scene with a single cube; but that is not a game. It breaks completely as soon as you add multiple objects, colliders, etc to a scene)
The main reason to use a 3rd party engine is to avoid re-inventing the wheel; it’s tragic that Unity can’t even do mouse-input out of the box. Let’s fix it!
(Via http://www.thisiscolossal.com/ )
When you first install Blender, DO THIS!
Menu: File > User Preferences… > System
When you look at objects in edit mode, they’ll look something like this:
Blender makes it very easy to get a face back-to-front.
Or to have two faces overlapping.
Or … any number of other topology bugs. At best, these kill performance in any game that uses them. At worst, they cause nightmares for your programmers and level architects when Weird Stuff Keeps Happening. They can even cause crashes (e.g. a surface that has strange holes, or inside-out faces … and then gets processed by collision detection).
This lighting setup tells you at a glance if your normals are correct. Which in turn tells you if you have pieces out of place, or if you have an angle between faces that’s smaller/bigger than you expected (quite common to spot a pair of faces that have a sharper angle than expected/intended).
Bonus: 3D printing
If you’re 3d printing, the mistakes that slow down or crash a Game engine … will cause 100% failure of prints (Wasted time, wasted plastic – and in some cases I’ve seen: damaged printers!).
So, yeah. Getting this wrong can cost thousands of dollars. Don’t do it; replace Blender’s defaults with something sane that works :).
Blender UX for the lose
This should be the default. But then … Blender’s team seems philosophically opposed to doing anything the easy way :).
You need this ALL THE TIME when developing, and Unity lacks it as a core feature:
- Create a Text label on your GUI
- Drag/drop a variable onto the label, and it will automatically display the value
Completely impossible, due to short-sighted design decisions in the Unity Editor from 10 years ago that never got changed. So, let’s fix it. It’s hugely annoying not being able to do this!
Image preview because WordPress HTML doesn’t embed PDF previews (Ah, I’ve been spoilt by Gmail!):
Every Saturday, thousands of indie / hobbyist game developers publish screenshots of their in-progress games. Unlike most forms of marketing, this is:
- honest / genuinely representative (it’s actual content)
- interesting (show’s the dev’s intentions)
- exciting (pictures of games are usually more fun than words)
i.e. … it’s an amazing marketing tool.
But many game developers are screwing this up. A year ago, I posted a long list of advice, tips, and explanations – worth reading. But some devs are still misunderstanding / screwing this up. So, what should you do?
Slides from my talk earlier this evening:
And if you were there, and haven’t read @lucasmeijer’s blog post yet: http://blogs.unity3d.com/2014/06/24/serialization-in-unity/
The author of Advanced Inspector gave me a free copy over Christmas. I’d considered it many times, and always ended up choosing not to buy, and write my own fixes/workarounds instead. So I was keen to try this out on a hobby project and see how well it works in practice.
What is it?
A replacement for Unity’s built-in Inspector. This (optionally) changes the editing interface for every single Component in your Unity projects.
Why do we need it?
When you run Unity, you get the standard multi-pane IDE that is the Unity Editor. Whether you’re a programmer, a designer, or an artist, this is your main portal into Unity, and the starting point for all your work.
Anything you select in the 3D/2D scene causes an Inspector panel to appear, with all the editable data about that thing. Unity’s built-in Inspector is very basic; by modern standards of GUI/UX, it sucks. Fixing GUI is very expensive, so instead … Unity has gradually been making the Inspectors more and more customisable.
Traditionally this was very hard to do; in the last 12 months it has become much easier, and Unity has unlocked more features. To date, I’ve not been sure if the 3rd party plugins are fully using the new features.
iOS forces you to use pretty animations: if you don’t tell it otherwise, it will use “ease-in/ease-out” curves to make things feel … smoother, less jerky.
Unity is made for programmers; changes you make to position, size, rotation, etc all happen instantaneously. By default, they won’t even animate, will teleport instead.
So … moving from “prototype with no animation” to “prototype that won’t hurt people’s eyes, and I can share”, what are some tips and gotchas?