4 ms·

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 ac

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.

Morgawr 10y ago
>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.
- nwm 10y ago
  I'm curious, as I'm not in the games industry: what type of model does one typically see? I actually expected it to be something along those lines.
  - chii 10y ago
    I suspect for bigger, AAA studios, they'd have a Entity Component System.
    - TeMPOraL 10y ago
      Would they? 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"
      - Morgawr 10y ago
        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-knockout/ 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.
        TeMPOraL 10y ago
        > 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.
- foota 10y ago
  It sounds like the way that Redux works would be great for this kind of logic.
- vvanders 10y ago
  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.

Morgawr 10y ago

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

nwm 10y ago
I'm curious, as I'm not in the games industry: what type of model does one typically see? I actually expected it to be something along those lines.
- chii 10y ago
  I suspect for bigger, AAA studios, they'd have a Entity Component System.
  - TeMPOraL 10y ago
    Would they? 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"
    - Morgawr 10y ago
      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-knockout/ 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.
      - TeMPOraL 10y ago
        > 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.
foota 10y ago
It sounds like the way that Redux works would be great for this kind of logic.
vvanders 10y ago
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.