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

11–20 of 104 posts

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

#11

Post by dale_glass »

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…

The world isn't, but some things are. Doesn't Rust have a problem with GUI frameworks because they heavily use inheritance?

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

#13

Post by DeathArrow »

adr1an wrote: post #10
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…

I had to look that up. From Wikipedia: Entity component system (ECS) is a software architectural pattern mostly used in video game development for the representation of game world objects. An ECS comprises entities composed from components of data, with systems which operate on entities' components. ECS follows the principle of composition over inheritance, meaning that every entity is defined not by a type hierarchy…

ECS is a kind of Data Oriented Programming / Data Oriented Design. In Data Oriented Programming data and code are separated (no encapsulation). This makes changes much easier to do and helps a lot with managing state.

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

#15

Post by s-lambert »

dale_glass wrote: post #11
baq wrote: post #7

Earlier quoted context omitted.

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…

The world isn't, but some things are. Doesn't Rust have a problem with GUI frameworks because they heavily use inheritance?

I don't think it does, I think Rust GUI frameworks have the same problem as Rust game engines, there's more people making frameworks than people actually making applications. They mostly seem to be going in the same direction as web UI frameworks though, which don't use much inheritance either.

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

#17

Post by TeMPOraL »

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], and I still have a bunch of open questions I can't seem to get my head around.

The biggest such question is: how the hell do you handle "cross-cutting concerns" in an ECS architecture, especially in the data-oriented programming version, where "cross-cutting concerns" are basically any kind of logic ("system") that needs to access more than one component of an entity at the time, especially if it does so conditionally? Like e.g.:

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

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

How are you supposed to preserve data locality in such cases? Is it even theoretically possible?

I may have some fundamental misunderstanding about the definitions here[3], but I haven't found any clear answer to the questions above, whether theoretical or practical. Back when I last looked, couple years ago, I couldn't find any non-toy game written ECS-first and with source available to study. Maybe this has changed now.

--

[0] - Which, as far I recall, was the original idea behind the pattern. It's also a very interesting one in general - if you squint, a lot of code all of us write for our projects is just half-baked attempts at setting up specific indexes and hand-rolling queries to a bunch of vectors, hashmaps, or (gasp) object graphs.

[1] - AKA "data-oriented programming", in this case mostly preferring "Structs of Arrays" over "Arrays of Structs".

[2] - One of them was literally just "let's store all game state in an in-memory SQLite database, because guess what, it's actually fast enough to be queried at 60 FPS!".

[3] - In my defense, most of the guides, tutorials and articles I read back in the day were themselves confused between "SQL approach" and "SoA approach" (see [0]), or worse, mixed in "whatever abomination Unity passed as ECS back then" and even something semi-related from .NET world. It took me a lot of time to understand that everyone's using their own blend of all those ideas, and this left me unsure about what one's really supposed to do.

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

#18

Post by cedilla »

wolfendin wrote: post #6

This always became really interesting to see when you had a private server and could view invisible NPCs. The “bunnies” usually used the default infernal NPC graphic

Are those bunnies leaked or datamined "official" Blizzard bunnies, or where they reimplemented by private server providers?

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

#19

Post by TeMPOraL »

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 understand there is, why are those cats deleted after 3 seconds? Does it mean the inactive radio station only continues playing the next track for 3 seconds, and then freezes? If so, that sounds like an unfortunate limitation.

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

#20

Post by sparrowInHand »

The problem in my opinion is that many game-engines are to focused on the "PerFrame view of the world" statically imagined by the designer and do not architecture for persitent but changing effects or long causal chains that constantly change and are capable of reusing behaviour. Good news though is that most by now, outsource that to scripting languages capable of providing better ways to implement this, but then you end up with parallel implementation of basic behaviour & services like pathfinding or targetting.

Imagine a late-game added lightspell, that is expected to behave like a ball lightning walking ahead of the player. The temptation to reuse the pathfinding, collission and other systems that controll figures will be enormous. But this behaviour needs a sort of CBipedal class to inherit all the behaviours. Voila - enter the hack.

Of course the clean solution would be something like a thrown stone on a lake, it exists as running code only when it changes (certain frames or events). It holds a composition of behaviours without the other ballast (datastructuress for aiming, inventory) etc. and also does not need a pool allocation to the monster/npc pool. (Basically you either have many peasants or many lightballs in the hypothetical as tradeoff).

Cause it aint a object, its a entity with a collection of behaviours, with a minimal data container bound to each behaviour seperatly, that may evaporate at a moments notice, should the player look away or its time run out.

Post reply on HN