In developing mods for Warcraft 3 using its World Editor, we'd often have to create invisible dummy units for the same reasons, like to cast a spell as part of a more complex custom hero ability. Always felt like a hack, but it's funny, surprising, and validating to learn that Blizzard essentially does the same thing in WoW.
Invisible Bunnies That Power World of Warcraft (2017)
41–50 of 104 posts
Re: Invisible Bunnies That Power World of Warcraft (2017)
#42I 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's been the case with Creation Engine games for decades, it's also present in Oblivion, Skyrim, and Fallouts 3/4 (and maybe others, that's just all I have experience with). It's amusing that it still works the same even through the iteration of the engine they made for Starfield.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#43Can anyone point to a better source for this so I can't share it with people? Kotaku is the TMZ of gaming and I never share it, but underlying content is good on this article.
This is the original source, reporting on a conversation between the writer and someone involved in the design being described. There can't really be a better source than that. Kotaku's uniquely bad reputation among gaming websites is only a result of people pushing a false agenda.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#44I really need to sort out adblocking on my phone, there are so many half the time it doesn't even show all the content, it's probably ran out of resources.
Seriously. This was the most abusive reading experience I’ve come across in a while. I also only got to read a couple of paragraphs before endless ads.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#45I 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…
As for your DB remarks, I've recently read an interesting blog post [1] about using SQLite as a cache in the context of web frontend. Apparently it works Well Enough™.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#46I 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'm not really sure this is an OO vs. ECS vs. any other design architecture thing, as evidenced by a lot of your other replies. I think it's just a general programming pattern that it's very tempting to take a large dependency on in order to get some small bit of functionality. Then, Hyrum's Law takes over [1], and you end up with a few more bits of dependency on the massive bit of code you pulled in. And you pull in a few more massive dependencies for just little bits of functionality, and organically grow a few more attachments to the huge code base. And before you know it, you've got 10 massive dependencies, and you only use vanishing fractions of their functionality, but extracting any of them is a huge pain.
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.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#47I 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…
You seem to have deep fundamental misunderstandings about ECS systems.
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.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#48I 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…
Since ~2007: https://blog.berniesumption.com/software/inheritance-is-evil...
Jedi "has dark powers", not Jedi "is dark jedi".
That way R2D2 can "has dark powers", as well as can "has light powers".
Re: Invisible Bunnies That Power World of Warcraft (2017)
#49Can anyone point to a better source for this so I can't share it with people? Kotaku is the TMZ of gaming and I never share it, but underlying content is good on this article.
This is the original source, reporting on a conversation between the writer and someone involved in the design being described. There can't really be a better source than that. Kotaku's uniquely bad reputation among gaming websites is only a result of people pushing a false agenda.
Specifically Kotaku's bad reputation primarily stems from GamerGate.
Re: Invisible Bunnies That Power World of Warcraft (2017)
#50I 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…
Sounds like it would have the same problems during refactoring if many different entities relied on the same data. You would have to make sure none of the entities’ behavior changes when you’re modifying your data. It also sounds very verbose where you have to compose each entity all over again instead of inheriting and adding an additional property. But that being said, I would take being verbose over weird hidden layers of abstraction any day.