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

31–40 of 104 posts

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

#31

Post by TeMPOraL »

ajuc wrote: post #25
TeMPOraL wrote: post #17

Earlier quoted context omitted.

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 { doSo…

You seem to be coming from the "it's more like SQL" end of the spectrum.

Yes, in that design, my questions aren't hard - but then, this design doesn't give you all the touted performance benefits, since in a data-oriented ECS, you're supposed to iterate over arrays of values directly (Rust may be doing some magic here I don't understand, though).

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

I tried to implement exactly that the other day, including with conditions on values; my overall approach to that was that each Query/Condition had its own array of entities, and all the Query/Condition array of entities were updated on operations like adding/removing components, so the checks are done only when their outcome could changed - which is less frequent than "for every entity, every frame".

It is at that point I realized I'm just reinventing database indices and materialized views, and papering them over with Lisp macros to remove boilerplate - which led me to ditch that ECS implementation, and go for "let's just move all game state data to in-memory SQLite database, and see how it works".

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

#32

Post by TeMPOraL »

octavius__ wrote: post #28
TeMPOraL wrote: post #17

Earlier quoted context omitted.

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.

You seem to be coming from the data-oriented end of the spectrum.

I spell that out to highlight the part about ECS being a very ill-defined programming pattern - I already see three parallel replies representing three different points on the spectrum :).

Beyond that, thanks - I'm relieved to know I'm not the only one with this problem.

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

#33

Post by Vuska »

cedilla wrote: post #18
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?

Datamined probably. Thousands of them can be found in the game files: https://www.wowhead.com/search?q=bunny#npcs

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

#34

Post by baq »

seanalltogether wrote: post #27
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…

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.

E.g. react does just fine with functional components; I'd say it does much better than with the old class-based ones.

Inheritance works well enough in exception classes, e.g. I can catch OSError and specifically handle FileNotFoundError differently on a language level, but it's nothing composition couldn't handle, either.

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

#35

Post by TeMPOraL »

Joking_Phantom wrote: post #21
TeMPOraL wrote: post #17

Earlier quoted context omitted.

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…

You seem to be coming from somewhere closer to "like SQL" than the data-oriented end of the spectrum.

On either end of the spectrum, there's much less flexibility. The "SQL side" is optimizing things for bulk operations[0] and flexibility coming from composition[1]. The "data-oriented side" is optimizing for performance, and it so happens that stuffing data that's processed together into arrays you can just scan in a cache-friendly way, also yields a component-like division of data.

Both those approaches are quite inflexible. They do kind of meet in the middle, as they yield similar data organization, but I'm increasingly convinced this is a surface-level, entirely incidental similarity. Philosophically, the two extremes of "ECS" are entirely unlike.

--

[0] - Again, AFAIR, ECS originally came from MMO world, where they do use relational databases for storing game state.

[1] - Also reason to use databases if you're making an MMO, as relational tables are known quantity, while serializing polymorphic object graphs is plain annoying.

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

#36

Post by eqvinox »

The only thing that bugs me about this is that they used bunnies rather than making a specific "spell effect/scripting" NPC. (I mean just one type to be used everywhere rather than bunnies, not a new one for each use.)

It's common enough of a pattern in other games, and the #1 bug is that someone forgets to click the "invincible" checkbox somewhere, your scripting 'bunny' dies, and then the game just breaks. If you create a NPC type just for scripting, you can have it default to invincible & invisible (or no model to begin with.)

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

#37

Post by jvanderbot »

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…

For what it's worth, I'm not aware of anyone who believes inheritance "ontologies" was a good idea, nowadays. Interfaces sure, but composition is just better for this reason. ECS is a formalization of that, and probably even perpetuated the idea, but it's everywhere I look now.

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

#38

Post by TeMPOraL »

octavius__ wrote: post #29
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.

That kind of makes logical sense, though. Physical hidden chests are, after all, how almost all real life shops implement inventories. Those are typically inaccessible to players, too.

(There is a part of shopping experience where the player grabs items and puts them in their own chest/basket prior to purchase. This works thanks to the security scheme of law enforcement NPCs dragging your ass to jail you can't save-scum your way off, should you steal something. But this is too complex to implement in a game, unless you're making the next GTA.)

Hell, even the bunnies and spectral radio cats make sense, to a degree. This reminds me of the ol' Flash games or Klik&Play/The Games Factory-made games. In all of them, you'd find yourself placing support objects on the scene but outside the screen boundary. I used to laugh at it, but eventually realized it kind of makes sense, if you think of the game as a theatre play - there's lots going on at the edges of the stage, just beyond what the audience can see.

Or think back to RAD tools from Borland (Delphi, C++ Builder) - they had a notion of abstract objects like "Timer" as invisible UI controls that could be placed in the window you're designing. On the one hand, this makes no sense - an abstract timer doesn't have "position" or "size", not at runtime. On the other hand, it was intuitive and convenient at design time.

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

#39

Post by xjay »

The battleground, Strand of the Ancients, was originally started using two invisible NPCs that were hostile to each other; one on each faction's boat and dock. The first boat/NPC to reach the dock would trigger a spell/script when in proximity, starting the first round. [1]

[1] BlizzCon 2016 - WoW Engineering Panel https://www.youtube.com/watch?v=W1y2fdDeSbU&t=227s

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

#40

Post by noirscape »

TeMPOraL wrote: post #38
octavius__ wrote: post #29

Earlier quoted context omitted.

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.

That kind of makes logical sense, though. Physical hidden chests are, after all, how almost all real life shops implement inventories. Those are typically inaccessible to players, too. (There is a part of shopping experience where the player grabs items and puts them in their own chest/basket prior to purchase. This works thanks to the security scheme of law enforcement NPCs dragging your ass to jail you can't save-s…

The recent Pokemon games also had a bug where the various support objects placed on the map for cutscenes were made visible during battles.

Since they lacked a model, they'd default to the first model in the games object list, which was a PokeBall, but then also loaded up every single texture onto it, resulting in various maps getting random multicolored PokeBalls in the floor (usually at their 0,0 point).

The approach to me also makes sense if you think of these support objects as "directors" for the gameplay. They usually track a specific bit of state to then act on once it's met. It's a pretty clever technique for rapid development (you can usually do what support objects do without them but it'd take a lot more effort in the game engine to do it that way) that can sometimes backfire in entertaining ways.

Post reply on HN