Categories
entity systems Unity3D

Simple #unity3d bugs and flaws fixed by Entity Systems – number 1

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…

Share a trait between AI enemies, and non-AI, unmoving, static objects

I have blobs that move and eat each other.

Now I want to add food, that cannot move, cannot eat anything, but is edible.

This is impossible in Unity without writing deliberately-bad code, for two reasons:

  1. Unity prevents you writing OOP code: Unity corp’s early programmers were inexperienced at programming, didn’t really understand C#, and broke it rather than work within it.
  2. Unity does not allow traits to be selectively shared between objects. This is the core feature of all Entity Systems, and shows beautifully why we do NOT accept any claim that “Unity is an Entity System / Component System / Entity-Component System”

7 replies on “Simple #unity3d bugs and flaws fixed by Entity Systems – number 1”

Wondering about this example? For all of Unity’s bad points (and there are many many of those), how come you don’t have a component called edible? should be able to add that to any gameobject and query in the “eating” check phase of the frame, no?

Short answer: Because the data that makes something edible, and the methods for interacting with it, are stuck in the first class I wrote.

Mostly unsupported by Unity because of their hacks to C# language that make things like interfaces stop working.

Technically, you can compile them. Practically, you can’t use them (they break Unity editor, for instance).

And they only apply for method signatures, not methods, and not data.

I don’t think quality of Unity3d’s code is relevant for its business growth. Quality of programming code in general is not very relevant for games. Maybe you should switch to Unreal? I know the language (C++) is legacy and really sucks, but the architecture seems fine.

yeah, Unity’s implementation of an ECS is so broken it’s not even funny. And to be honest the first time I’ve ever really encountered the concept of ECS was by you and Mick West’s “Evolve your hierarchy” post. :D

I work in simulation where stuff has to be done to a higher degree of accuracy, scenarios tend to be more complex compared to games.

We use the UnityEngine.dll as a “view” layer, and write the logic of the Agent representations below it.

So from the high level UnityEngine.dll perspective, a food game-object is just a game-object with a SpriteRenderer.

Below that, is a binding for an Actor that represents the foods info, what it can give etc.

Similar with the Blobs are also Sprite Rendering GO’s, but below is an API that handles moving Actors that move.

It is OOP, very easy to manage and extend, runs very fast and depends only on the Unity MonoBehaviour to get stuff done.

I don’t see in your blobs scenario, how Unity is holding you back.

Comments are closed.