Invisible Bunnies That Power World of Warcraft (2017)
kotaku.com
kotaku.com
You can even install an addon that'll show you the quests getting completed in the background, which can occasionally be handy as it basically notifies you "what you just did will be remembered". https://www.curseforge.com/wow/addons/questschanged
Amusingly, these quests still count as completed-quests for the in-game achievement system, so new characters will confusingly get achievements like "10 daily quests completed" despite never having actually completed a visible daily quest.
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.)
I've created a custom map turning the system a round, where you played the invisible critters instead of the hero :D
Wonderful
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.
[1] BlizzCon 2016 - WoW Engineering Panel https://www.youtube.com/watch?v=W1y2fdDeSbU&t=227s
I am sorry, but it still is just bad design, if you have to missuse a different class. So strictly economically speaking yes, after the system was already running, it might have been cheaper to go with it than redesign - but the initial design flaw is still a flaw. But they still made lots of money this flawed system, though, which is a good reminder, that the most important thing for any product is usually, does it work?
Still:
> But they still made lots of money this flawed system, though, which is a good reminder, that the most important thing for any product is usually, does it work?
That is a very good point, especially in videogames/entertainment. Reminds me of the "first law of 3D game graphics" I read somewhere - "if it looks good, it's good - no matter the amount of cheating going on".
ECS is kind of like lisp. Every sufficiently complex game will implement its own bug ridden ECS framework (unless it uses one already)
Also, reminds me of the Princess Donut book series.
The “bunnies” usually used the default infernal NPC graphic
Kotaku ended up being singled out over the allegations regarding Depression Quest where it pretty much became ground zero for GG. The allegations themselves were mostly fueled by a cultural backlash of "true gamers" against "walking sims", the derogatory label for projects using games as medium for interactive narratives and experiences, which they saw as a threat to traditional gaming and gamer culture (which makes more sense if you compare it with the Great Replacement conspiracy theory and see it as a precursor to the Cultural Marxism conspiracy theory especially popularised by Jordan Peterson).
Heck, even the affiliation was shaky at best: a person claiming to be the ex of the person who created Depression Quest accused a journalist writing for Kotaku to have given Depression Quest positive coverage while they were in a relationship. So at worst the argument was that the developer used a friend to create attention for the game by writing about it without disclosing their (at the time non-romantic) relationship. Compared to what every major gaming journalist was doing with triple-A publishers at the time this was a nothing burger - except GGers disliked what the game represented (i.e. progressives using games as a medium for interactive art pieces) and who was behind it (women and queer folk, i.e. people with "political" genders/ethnicities/orientations rather than straight-passing white-passing cis-passing men).
As a leftist Black progressive from Brazil, I don't need to pretend I like a shitty website just to appease to crazy American prejudices.
It's just a shallow website that is largely made of reposts, low effort sensationalism, poor journalism, and articles that could have been a Tweet. I do not repost it because it is extremely low quality even when it is the original source. But that subject was interesting so I wanted to find another source to share.
And of course I'm being truthful why would you just assume otherwise? Do I need to send you my Brazilian RG and CPF? The internet is so tiresome. Just open the website, read it. It's really bad. This is not a fucking narrative.
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.
Of course, this can happen with ECS, too, but it feels easier to avoid. Systems which are coupled to individual components of entities, rather than whole objects, provide an extreme degree of flexibility as long as the components stay small.
(bonus: another example of this occurring in Fallout 3 - https://www.pcgamer.com/heres-whats-happening-inside-fallout...)
…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 level.
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.
To me, class-based has one advantage over functional. A component is an object and therefore perhaps ought to be represented by a class.
That being said, functional maybe is a bit simpler.
That's what those who ditch inheritance altogether when designing languages challenge and it turns out not much of value is lost :) 'Component is an object' is something you'd hear from an OOP practitioner which isn't exactly convincing to people thinking functionally.
What I don't understand, I suppose, is if a Component isn't an object that acts, then what is it?
ECS follows the principle of composition over inheritance, meaning that every entity is defined not by a type hierarchy, but by the components that are associated with it. Systems act globally over all entities which have the required components.
like, all of anything you could program, ever? for any purpose?
As long as you don't kingdom of nouns everything any repeat the mantra: "classes are just interfaces with code reuse" you'll be fine.
What I mean is: For library developers, inheriting an interface makes some sense. But throwing in an ontology that is meant to mimic human-like classification (esp just for the sake of it) is a disaster in all the code I've seen. There really isn't any reason for a Shape: Circle hierarchy. The better abstraction is around what can be done: a PrintableList<Point>, or whatever.
std:: takes the second approach (Type trait-like interface_-level decisions. There was (for a time) a huge push for the first approach of "is-a" relationships which makes zero sense almost any time.
IMHO ECS is a sane "has-a" relationship which is effectively a redo of "is-a" interface-level interactions, b/c each entity "has-a" list of objects that form it's interface with the system.
--
[0] - Is tomato a fruit or a veggie? Is a whale a fish or a mammal? Etc. The answer to that is just "either, none, whatever - it's you who are confusing culinary, economic and genetic taxonomies".
[1] - Which is some combination of code thinking and domain thinking. It's never just purely one of them.
Jedi "has dark powers", not Jedi "is dark jedi".
That way R2D2 can "has dark powers", as well as can "has light powers".
Imagine all in-game characters have their data in a database. The database might have one or more tables representing an objects ID or another reference, its position, its health points, and image data representing how to draw the object. These three things are "components" and the IDs and references are "entities."
A system is anything that manipulates one of these components. Thus, a function that manipulates a component is a system.
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.
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.
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.
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<(&Component1, &Component2, &Component3)>,
) {
for (c1, c2, c3) in query.iter() {
if condition(c1) {
doSomethingTo(c2);
} else {
doSomethingTo(c3);
}
}
}
fn complex_system2(
query: Query<&Component2, With<ConditionFullfiled>>,
) {
for c2 in query.iter() {
doSomethingTo(c2);
}
}
fn complex_system3(
query: Query<&Component3, Without<ConditionFullfiled>>,
) {
for c3 in query.iter() {
doSomethingTo(c3);
}
}
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".
Like "If player seen this kind of a monster already and there's at least 4 people in the room and someone there has this kind of weapon equipped - enter this branch in dialog and progress the quest".
Traditional solution seems to be hardcoded special cases for all conditions which probably has better performance but sucks so much when you're implementing quests and dialogs. You tend to avoid writing quests that require new kinds of data so you end up with fedex quests and murder quests and that's it :/.
How well did this SQLite idea worked out for you?
I wish I knew the solution to this exact problem. IMO this is the central issue that stops pure ECS from being useful.
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.
You can absolutely access multiple components in a system, for some reason you think a component and a system must have a one to one relationship, when really it’s many to many.
The only caveat is that you have to think carefully about the order that some of your systems are executing in the game loop, since you want to make sure component data has been updated appropriately for later systems to act on.
ECS is really the best way to make games. It lends itself well to rapid iteration and experimentation of new game concepts.
A little bit of nuance would go a long way.
Even in games where ECS is a good match, having to implement a boss with ECS is wasteful in terms of dev time and performance: You have to create components and matching systems unique to the boss, where with a traditional approach you just have to create a single Boss class.
You could create a database table called "Boss," that contains all the Boss components. Then for each system, you create a function that operates on a Boss.
Having a one off actor is really limiting. You can create several boss components and build entire permutations of bosses just by mixing and matching them up, without writing specialized code. Designers can put together the entities without developer input.
(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.
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.
> Dwarf Fortress
Ah yes, the two most complex videogames ever created :).
I do appreciate the remark, though. The mechanics may not be impossibly complex, it's just prohibitively complex for vast majority of the games.
(Which is a sad thing to me; I love games with lots of internal complexity.)
It's true that OO design pushed game engines in this direction; if you need something that only the last "full on NPC" node in the inheritance tree provides, which is very believable, then your designers are going to use it, even if they don't need most of the rest of what it provides. But I think this is something your designers are generally going to do anyhow. They aren't professional programmers and they aren't sitting there worried about long term code quality (especially not in the games industry), they are worried about getting their job done, and under any design it's going to be easier for them to reach for a large stick and pare it down than to reach for the small stick and then laboriously figure out how to attach the extra bit it needs. It doesn't matter how easy it is to attach the extra bit, it's going to be easier for them to grab the big, all-in-one provider. They're going to figure they may need the other stuff later anyhow, and they're reasonably likely to be right so it's hard to even call that irrational.
You can see this pattern all over in programming. I know of multiple codebases where I work that suffer from this pattern without any games being involved. Developers could implement new subsystems either as independent subsystems that they minimally connected into the main product, but have relatively few services provided by default to those subsystems, or they could start from day one fully integrated into the rather massive monolith with all the services it provided, even if it wasn't great with those services. And generally they would choose the latter, making the monolith even larger and the crossing mishmash of dependencies on the large services even bigger and more complicated. Maybe they were even right at the time, but now we've got some fairly large and complicated balls that can't be replaced in a big bang, but also can't hardly be replaced incrementally, because everything depends on everything. Upgrading any portion is a nightmare. They reached for the super complicated, relatively powerful objects that provided all the services even if they just needed a couple things, and now they're all in a spaghetti pile. And there's hardly any OO in sight, this is all really just procedural despite the occasional OO island.
You can see this in the still-growing general understanding in the programming community that dependencies are not free. The benefits you can obtain from a dependency are enormous, immediate, and easy to see. The costs are subtle, to the point that you can be mocked by developers for thinking they even exist (though I see this particular attitude fading, fortunately), but it's easy for them to grow into at least the order-of-magnitude of the benefits, and sometimes exceed them.