I periodically write massive long documents detailing all the bugs in Unity that I know, have memorized, and have to workaround on a day-to-day / hour-to-hour basis. But it makes me so angry and frustrated – so much terrible coding, so little technology-leadership at the company – that I end up deleting it. Life is too short to be daily reminded how crappy (and yet easy to fix) our tools are.

Then, every 6 months or so, when people ask me for simple examples of how ECS’s fix Unity, I have to wrack my brains for something simple.

So I’m going to start blogging simple examples as I run into them, with only enough context for me to understand them. Here’s the first…
Continue reading “Simple #unity3d bugs and flaws fixed by Entity Systems – number 1”

(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.

Continue reading “Data Structures for Entity Systems: Multi-threading and Networking”

(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):

1. Guarantees everything has the GetInstanceID() method
   1. 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)
   2. 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)
   3. …probably loads of other things. It’s so commonly used I hardly notice it
2. When doing in-Editor things, Unity can often “ignore” classes that are “not part of the game, because they don’t extend GameObject”
   1. Reading between the lines of official docs, and simplifying vastly, this is what happens behind the scenes. Especially with Serialization, I suspect.
   2. 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
3. Since every GO has a Transform … you can do automatic, general-purpose, high-quality, Occlusion Culling
   1. 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

1. Start writing your own version of the Unity Serialization system that only uses structs
2. Finish it the same day
3. Discover it runs 10 times faster than Unity’s built-in one
4. …with fewer bugs
5. PROFIT!

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()

Yeah, this sucks – and it’s nothing to do with Unity, it’s core C#.

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.

Further Reading

…some things I might want to pick up on in future posts:

• Worked example of converting struct to immutable struct, and why/how to do it
• Guidelines for implementing immutable structs

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:

1. You can give me direct feedback on the proposed contents/scope
2. 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:

1. Newbie devs, and non-programmers (artists, designers), who find the “coding” parts of Unity overwhelmingly difficult today
2. 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).
3. 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
4. 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

Tier costs

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.

Funding targets

This is what it’s going to cost to build:

1. Minimal version that’s usable in most game-dev: approx. $15,000
2. My preferred v1.0: approx. $75,000
3. 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:

1. Minimal funding: $5,000
2. Preferred funding: $30,000
3. High-quality funding: $75,000

My situation

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.

Why Kickstarter?

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?

Support me on Patreon, writing about Entity Systems and sharing tech demos and code examples