I remember seeing games doing actor-like things with message passing on a single thread way back in '02. You could "broadcast" a "damage" message and all the actors that were in the hit region would handle it in however they saw fit. Great way to force decoupling.
Concurrency is somewhat orthogonal(although a nice-to-have), it's more about not doing things that run counter to your hardware.
Over in the games space we don't have the advantage of scaling wide on multiple machines so a couple things that sound heretical are there for good reason.
>You could "broadcast" a "damage" message and all the actors that were in the hit region would handle it in however they saw fit. Great way to force decoupling.
This is great for simple games but it gets hairy really quickly for larger games and it can easily become a mess. There are a few event/callback driven game engines out there and a lot of the most popular AAA game engines provide some kind of event subscription model (I think UE does it, at least, but I never really used it much).
The biggest problem is with figuring out who is in charge of what. Let's say I broadcast the event "player attacks enemy", then the enemy has to receive that event and respond with "enemy plays hurt animation" then "enemy plays dead animation" "enemy broadcast death" and then "player plays acquire XP animation" "player broadcasts level up" etc etc. The order can easily become a mess. And then "player attacks enemy" and "enemy evades attack" and "player plays missed animation" etc etc...
It really becomes very messy for big games, especially if you want to build an game engine entirely based on the broadcasting of events. I think Angel-Engine, now called Angel2D iirc, was mostly based on that and it worked fine for small scale stuff but easily become a mess.
It certainly is easy to understand the logic behind the game that way, it's great for small indie games or game competitions/prototypes, though.
Yeah, I'm trying to remember where I saw it(definitely wasn't UE3, that engine is the definition of tight coupling). It may have been for inter-component communication inside a single entity for a cleaner ECS.
I did read a bit on that, and tried to implement a simple game on it. What I've learned is:
a) it seems to be vapourware; there are some blog posts about it and examples floating around, but that's pretty much it
b) it seems to make sense only for MMO games, which are glorified interfaces to database tables anyway - hence the ECS model, which is about treating your game design as a database problem - fits it well
c) experienced people I talked about think this is a stupid approach, for reasons I'm probably too dumb to understand (except the efficiency ones)
d) in games that are not database-like MMOs, it's getting very hard to figure out what should be a component or a system, how many systems should you have, etc. etd.
e) it seems to seriously complicate implementing game logic - you end up spreading code that belongs together across many different "systems"
Most modern engines, as far as I know, implement a component-driven approach. You can see it in pretty much any kind of public engine like UE or Unity and it works really well. Composition over inheritance any day. I don't really see why you claim that it seems to be vaporware, considering it's one of the most implemented types of game engines currently.
It is true that there are some degrees of limitations and implementations that different game engines go through and none of them is a 100% pure CES engine (something like http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockou... ), where all systems are separated from the components and the entities containing them. Usually you'd have sets of components and systems and whatnot and different hierarchies, but the gist of it is still a Component-driven system.
> It is true that there are some degrees of limitations and implementations that different game engines go through and none of them is a 100% pure CES engine
One thing I vividly remember from learning about ECS is that the main sources on it repeatedly remind you that what UE or Unity do is not ECS, and that the way they understand the concept of "Entity" and "Component" is different. Entity Component System is not what UE or Unity do.
I'm developing NullAwesome[0] with an entity component approach, and so far it seems to be going rather well.
Using an ECS for game design actually has enormous advantages when you are coding a high-performance game in a language like C or C++: you can lay out the components of the entities however you want, so that systems on the hot path have access to as many components as they'll need without blowing the data cache. I'm not actually doing that for this game, but still, it has advantages outside of just MMOs.
Concurrency is somewhat orthogonal(although a nice-to-have), it's more about not doing things that run counter to your hardware.
Over in the games space we don't have the advantage of scaling wide on multiple machines so a couple things that sound heretical are there for good reason.