Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Invisible Bunnies That Power World of Warcraft (2017)

kotaku.com

Post reply on HN
Print view View original

21–30 of 104 posts

Re: Invisible Bunnies That Power World of Warcraft (2017)

#21

Post by Joking_Phantom »

TeMPOraL wrote: post #17
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Ah, ECS. The most ill-defined software pattern since IoC/DI. Everyone seems to have their own understanding of it, usually somewhere on the spectrum between "what if we kept the game state in a relational database"[0] and "what if we put any individual type of information into its own big array, so it's CPU-cache-friendly"[1]. I wrote several such systems for my own toy games, at various points of that spectrum[2], a…

I think the answer is that ECS isn't supposed to solve those problems directly. It's just a framework that makes a certain class of problems very easy to solve. But big picture complexity is still up to the developer's skill and wisdom. Knowing which parts of the game should go into ECS, and which parts go somewhere else. Which systems flow from another system. Which system is allowed to manipulate the data directly and which systems are only able to read data reasonably, but not write. And how your design of the game may need to change to suit the limitations of your computer and your ability to program.

ECS is like any other framework. It is a tool or system, for organizing your efforts. Be very liberal with using it in its intended scope. Be judicious when its at the edge of its scope. Be very skeptical when its outside of its scope.

Re: Invisible Bunnies That Power World of Warcraft (2017)

#22

Post by [deleted] »

TeMPOraL wrote: post #17
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Ah, ECS. The most ill-defined software pattern since IoC/DI. Everyone seems to have their own understanding of it, usually somewhere on the spectrum between "what if we kept the game state in a relational database"[0] and "what if we put any individual type of information into its own big array, so it's CPU-cache-friendly"[1]. I wrote several such systems for my own toy games, at various points of that spectrum[2], a…

[deleted]

Re: Invisible Bunnies That Power World of Warcraft (2017)

#23

Post by actionfromafar »

TeMPOraL wrote: post #19
tetris11 wrote: post #3

the more interesting article is linked in the first paragraph, where spectral kittens power radio stations in Fallout 4

> “The cat acts like a settlement radio receiver, and its role is to keep alive the inactive radio station so it continues to the next track even if you’re listening to another station. Just like if it was a settlement receiver somewhere near the player. In normal circumstances the cat doesn’t make sound. It is silenced, it is invisible, and it is deleted from the game world after three seconds.” What I don't underst…

Probably a cat needs to press next, but then the cat doesn't need to listen to the full track?

Re: Invisible Bunnies That Power World of Warcraft (2017)

#24

Post by katzenversteher »

TeMPOraL wrote: post #17
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Ah, ECS. The most ill-defined software pattern since IoC/DI. Everyone seems to have their own understanding of it, usually somewhere on the spectrum between "what if we kept the game state in a relational database"[0] and "what if we put any individual type of information into its own big array, so it's CPU-cache-friendly"[1]. I wrote several such systems for my own toy games, at various points of that spectrum[2], a…

I believe Space Station 14 is implemented using an ECS engine. It's open source but quite impressive regarding scale and features. It's also a multiplayer game which brings some extra questions to the usual ECS ambiguities.

Re: Invisible Bunnies That Power World of Warcraft (2017)

#25

Post by ajuc »

TeMPOraL wrote: post #17
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Ah, ECS. The most ill-defined software pattern since IoC/DI. Everyone seems to have their own understanding of it, usually somewhere on the spectrum between "what if we kept the game state in a relational database"[0] and "what if we put any individual type of information into its own big array, so it's CPU-cache-friendly"[1]. I wrote several such systems for my own toy games, at various points of that spectrum[2], a…

> Any kind of logic that goes like "IF something(component 1) THEN doSomethingTo(component 2) ELSE doSomethingTo(component 3)"

What's the problem here? You write a system that queries these 3 components and then call regular functions. In bevy (a rust ECS framework) it would look sth like this:

    fn complex_system(
      query: Query,
     ) {
      for (c1, c2, c3) in query.iter() {
         if condition(c1) {
           doSomethingTo(c2);
         } else {
           doSomethingTo(c3);
         }
      }
     }
I think there's no need to deconstruct everything into smallest possible systems, this level of granularity is ok. You could also make the condition into something that can be selected by the query and remove the if.

    fn complex_system2(
      query: Query>,
     ) {
      for c2 in query.iter() {
           doSomethingTo(c2);
      }
     }
     fn complex_system3(
      query: Query>,
     ) {
      for c3 in query.iter() {
           doSomethingTo(c3);
      }
     }
But that's only possible if you can make the condition be simply existence of some component in given entity. Could be improved with systems that query based on values of components and indexing could be added, of course, but I haven't seen that kind of ECS yet).

Re: Invisible Bunnies That Power World of Warcraft (2017)

#27

Post by seanalltogether »

baq wrote: post #7
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

ECS is IMHO a logical consequence of observing that game worlds are not object oriented (as it is taught in schools, so class hierarchies etc.) Add a sprinkle of performance requirements and you get what is understood as ECS frameworks. …but it turns out that the ‘world is not made of class hierarchies’ observation is not limited to games, hence Rust’s and go’s approaches to OOP: ditch inheritance at the language lev…

ECS makes sense in games because OOP enforces lots of rules downstream in your inheritors, which is good for GUIs, but bad for games when producers keep asking for that one npc or boss to do something special that breaks the rules. ECS is just so much more flexible which is good for some design systems and bad for others.

Re: Invisible Bunnies That Power World of Warcraft (2017)

#28

Post by octavius__ »

TeMPOraL wrote: post #17
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Ah, ECS. The most ill-defined software pattern since IoC/DI. Everyone seems to have their own understanding of it, usually somewhere on the spectrum between "what if we kept the game state in a relational database"[0] and "what if we put any individual type of information into its own big array, so it's CPU-cache-friendly"[1]. I wrote several such systems for my own toy games, at various points of that spectrum[2], a…

> Physics, rendering, animation, and game logic all need to access some subset of the same position, orientation, dimensions, velocity, acceleration, mass, tensor of inertia, etc.

I wish I knew the solution to this exact problem. IMO this is the central issue that stops pure ECS from being useful.

Re: Invisible Bunnies That Power World of Warcraft (2017)

#29

Post by octavius__ »

SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Another recent example is from Starfield, where shops inventories are handled by a physical chest hidden underneath the shop. You can use noclip to loot the chest and get shop items for free.

Re: Invisible Bunnies That Power World of Warcraft (2017)

#30

Post by bob1029 »

TeMPOraL wrote: post #17
SeanAnderson wrote: post #4

I think the prevalence of these sorts of issues is why ECS is such an appealing architecture in game design. OOP seems to always devolve. A new feature is needed for the game, the feature breaks some well established design rule, it's challenging/slow to refactor everything to make sense while considering the new feature, and so a kludge is implemented where existing objects are forced to be more flexible than planne…

Ah, ECS. The most ill-defined software pattern since IoC/DI. Everyone seems to have their own understanding of it, usually somewhere on the spectrum between "what if we kept the game state in a relational database"[0] and "what if we put any individual type of information into its own big array, so it's CPU-cache-friendly"[1]. I wrote several such systems for my own toy games, at various points of that spectrum[2], a…

Thank you for this. I've been waffling on just using SQLite to store all the game state. I will give it a shot. I know it will break down for larger scenes, but I don't think I have those yet. Simplicity is probably way more important than anything else for a solo dev custom engine experience.
Post reply on HN