Hacker News new | past | comments | ask | show | jobs | submit login

I'm a bit confused between there's a hugely popular place between inheritance-based entities and ECS (Entity-Component-System), which is what you could call a "Entity-Component system) (notice spelling) or perhaps a Component-based entity composition system.

Inheritance based: you derive Vechicle, then derive Tank, Car, etc. This was most used from 95 to 2005 as teams moved to C++.

Component based: you create a TreadsMovement component, a Turret component, a Wheels component, a Chassis component, etc. Each contains the data and behaviour for what they represent. You compose them together at runtime inside Entity objects to create tanks, cars, etc at runtime. Popularized by Scott Bilas' engine for Dungeon Siege. This is classic Unity. Most used from 2005 to today.

ECS: data-oriented where components are data-only, and behaviour logic lives in systems that act on a set of instances that contain certain subset of components. Entities are just ids for the set of components that make up the data for a given active object in the game. Entities and Components are best understood as a database which systems query and select from.

I don't know enough Godot to be sure if it's Inheritance or Component, but I know I left "classic" inheritance based behind almost 20 years ago and would never want to go back. Even back in 1997, the Commandos 1 engine was already half Component-based (but it took us a while to refine the Component model and intercommunication).

I know what you mean, and that confusion is 100% Unity's fault, because they call their data-oriented entity system "ECS".

Back in the day, composition was referred to as "component-based entity systems", which makes perfect sense.

But then Unity came in and called their data-oriented one "entity component system" for reasons I will never understand. Why not just call it "data-oriented entity system" or something like that?

So nowadays when you hear "ECS", it's not clear what people are talking about anymore.

The confusion is worsened by people interpreting it as "[an] (entity component) system" or "[an] ((entity) (component)) system", when it's actually "[an] Entity–component–system [architecture]". That is, it's not a system of entities and components, it's an architecture comprising entities, components, and systems.

it's not surprising given that "entity component system" is synonymous with "thing behaviour environment". It's using the most meaningless generic terms possible. It's like when companies use a tagline like "using innovative practices to deliver results for our clients".

I'm not sure Unity is at fault here. Most people in the game dev business knew about what ECS is (Entities + Components + Systems) long before Unite Austin 2017 (when Unity first announced their upcoming entities package).

It would be fair to attribute the ECS naming (specifically, making "Systems" an integral concept to the, ahem, system) to this from 2007: http://t-machine.org/index.php/2007/11/11/entity-systems-are...

I would say it is 100% not Unity's fault. As someone else posted, there's a t-machine blog posted and that entire blog has been filled with ECS with that specific term for years. But aside from that it has been a heavily discussed thing for many years in the gamedev scene. There's a wikipedia page on it, showing a bit of history from well before 2017, but you will find most on it on gamedev.stackexchange and gamedev.net. It probably predates the start of Unity in its entirety.

Also, to be fair, they really do refer to it as DOTS -> Data Oriented Technology Stack (granted, it includes more than just that), but I'm not sure if and when they changed that. Their community just seems to keep calling it ECS regardless.

DOTS is not ECS. "Unity Classic" is ECS. DOTS is a more cache-efficient architecture designed to support larger numbers of entities.

Unity's DOTS is definitely an ECS system. You technically can have an ECS without all the data-oriented and cache efficient stuff, if you just want the architectural benefits, but it's pretty hard to build a data oriented game engine that is not fundamentally ECS

Definitely true, having looked at probably 20-30 ECS frameworks in about 5~ different languages between 2019 and 2020. About half of the ones I looked at, probably a bit less, were DOTS.

Not about ECS, but speaking of components: I’m developing an unreal engine game and component based programming has been a dream. You end up with the opportunity to create so many pieces of code that are able to be dumb and that don’t need to know about the rest of the system. Then you add come control code that is also as dumb and blind (in a good, decoupled sense) as possible and the whole application comes together in 1/10th the effort of a more coupled and fragile inheritance heavy approach. You can actually change things without breaking everything and you can actually understand what something does by reading 1-2 source files instead of 40.

I'm curious about emergent problems that are difficult to diagnose with many systems operating seemingly independently. Systems interacting in odd ways, and ordering of systems (dependency ie one system MUST run before another). Do these come up?

You’re right, they do. You add a layer on top that is in charge of worrying about those interactions, and it works pretty smoothly in my experience, but even then there can be some challenges from multiple pieces of code trying to use that controller code to do contradictory things. But I think you end up in the same situation with all big apps, and in this setup at least some of your code is still easy to reason about. It’s still several layers of abstractions. Command pattern with a good entry-in-progress-exit lifecycle is another system to add on top that helps things stay flexible and easy to work with later on

Not to sound rude but IMO I find components really hard to organize and structure data. Components are probably really nice for storytelling games and games with simple logic: they really shine when you can just take some effect like a particle system and attach it to some object like a Sci-Fi weapon. But it's really hard to separate model, view, and controller from your game when they're all separate components on the same object.

MVC is good for user interfaces, but there is some inherent coupling between model and view in most games. Eg, animations. I didn’t have much luck using mvc outside of the ui. IMHO, single responsibility is the more fundamental principle and components are helpful for that

You worked on Commandos? Holy crap. I'm mid way in to my game development career and played that to death before I even started. Plus 70 hours on Steam as an adult...

If you wanna make me feel old, just consider that Commandos was released 10 years after my first commercial game, so I'm even older. :D Fun bit: I never ever finished a single mission in a Commandos game.

Yeah I did code architecture work on Commandos 1, then led the tech & tools for the expansion and Commandos 2. A lot of the C1 work was related to this topic, actually: when I arrived at the project, it was hard inheritance-based with a fixed set of subcomponents, and I shifted it to a common base for gameobjects (the class "Bicho", really odd name) which contained a collection of arbitrary components that communicated via messages. It was more extensible that inheritance, but very messy - too many assumptions and typecasts. First steps... The Commandos 1 codebase was thrown away and restarted from scratch for Commandos 2.

It's never too late to start playing!

If you ever get around to writing up a technical post mortem I'm sure it would be super interesting. The simulation seemed quite advanced for the low end hardware the game ran on, with view cones, pseudo height, physical objects, footprints, and pretty good AI.

The Commandos series dying out is a great shame, although of course Kalypso is staffing up to attempt a sequel.

What are you up to these days?

Heh I was officially the last Pyro employee before it was folded, and my last task was to prepare and package up all backups when the IPs (rights, licenses, whatever it actually was) were sold to Kalypso. I not-so-secretly wished there would be a way for the Shadow Tactics team to make the next Commandos, but it wasn't to be (and Desperados 3 is awesome!).

For the past 2.5 years I've been at Lingokids, a mobile service filled with fun and educational content for kids in English. The tech challenge here is balancing constant forward movement with new games, while keeping all the previous ones working. But using my kids as testers beats anything else I've ever done in the fun-at-work department.

There's also this, which seems like a pretty good spiritual successor out of Russia. I've only played for twenty minutes or so but so far so good.


I can definitely see that being more fulfilling. There are only so many virtual Nazis you can kill before it wears thin!

I think Godot is both. A lot of built-in nodes are meant to be extended (like KinematicBody) and a lot of them provide features via adding components (like RayCast or Area or Timer or AudioStreamPlayer).

Yup, this is spot on(with a mix for some systems that did a bit of data only components for the real perf critical stuff together with the more business logic components).

Your dates are right too, at least from my experience during '04~'12. Being on the tail end of that inheritance based approach was brutal and was so happy to leave it behind.

Cosigned. I did level design on a game in the Unreal 1 era. The cosmic inheritance hierarchy was a regular annoyance.

> [ECS was] Popularized by Scott Bilas' engine for Dungeon Siege.

Make that nothings' and MAHK's http://enwp.org/Dark_Engine for (initially) Thief.

I think it is more inheritance than ECS, but not religiously OOP.

Having used Unity and Godot, I really like the architecture of Godot. But Godot is not nearly as fully functioned (yet).

> I'm a bit confused between there's a hugely popular place between...

Godot is a Unity clone. Unity has copied a lot of things, including Flash (and therefore Shockwave), where this "attach scripts to stuff" architecture actually came from.

Godot is node based so you compose an Entity out of nodes. It’s a slightly more flexible version of an Entity Component model.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact