Thread: RE: [Algorithms] Game Entities - avoiding inheritance / fixedpool allocation [bcc][fake adr]
Brought to you by:
vexxed72
From: <chr...@pl...> - 2003-01-31 21:33:10
|
>I think a bunch of things are getting conflated here in this thread: > >1. Emergent behavior vs. emergent gameplay. Hair-splitting. Emergent gameplay is emergent behavior, and in the context of games, emergent behavior is emergent gameplay (unless there's no gameplay involved, in which case it's not a game). Just to make sure, I checked what Harvey Smith had to say on the topic (as someone who has talked a bit about emergence recently). He says: "Emergent Gameplay: You could define emergence as an event that occurs, but that could not have simply been inferred from a system's rules. Emergent behavior occurs when a system acts in an organized fashion beyond the sum capabilities of its individual parts. [...]" (http://www.planetdeusex.com/witchboy/articles/thefuture.shtml) Notice how he uses "emergent gameplay", "emergence" and "emergent behavior" as synonyms for the same thing (and continues this practice throughout the paragraph from which I lifted it.) What do you mean the difference is? I noticed you didn't try to elaborate on the point. >2. Emergent gameplay vs. data-driven hierarchies. I agree completely with >Christer that you can have emergent gameplay without a data-driven >architecture. I mean, it's a Turing machine. You can also use a >data-driven architecture to make a traditional adventure game and have no >emergence. They're orthogonal in some sense. However, the key is that >emergent systems (really all game designs, but especially ones encouraging >emergence) need iteration during their development. You don't just type up >the big spec and hand it to somebody to implement, because we've all found >that doesn't work if you're trying something new, and it barely works if >you're just trying to do a no-brainer sequel. So, you need to iterate the >design, and the best way to do that for emergent gameplay designs is to >empower your designers and use a data-driven property system, in my opinion. Yes, they concepts of "emergence" and "data-drivenness" are completely orthogonal, you can have one without the other (but Turing machines have nothing to do with it). However, regardless of whether you think emergence requires more iteration that non-emergence (I don't see why that would follow, but it doesn't matter), I still don't see any support for your statement that a data-driven property system (by which I assume you mean something on the right-hand side of the scale I refered to earlier) somehow makes iteration easier than something on the left-hand side of the same scale. In my opinion, it does not. Since we already established that emergence and data-driven are orthogonal, it seems to me that a right-hand side system doesn't provide anything that would make iteration of something completely unrelated easier. Care to explain your thinking of how data-drivenness makes iteration of something you agree is unrelated easier? Christer Ericson Sony Computer Entertainment, Santa Monica |
From: Matt M. <ma...@cy...> - 2003-01-31 22:12:56
|
Hmm...if I replace "data-driven" with "dataflow," the emergent gameplay thing starts to make sense. In a typical dataflow architecture, operations on data are built by assembling "nodes," each of which is composed of one or more inputs, a (reasonably) atomic operation, and one or more outputs. They're pretty awesome for motion blending, and, when taken to extremes like in the = Houdini architecture, can be amazingly general while maintaining great = simplicity at the code (but not necessarily the system) level. This creates a situation analogous to the Lisp "code-as-data" paradigm, where it's easy to write code that writes code, or that modifies code, = etc. If you use polymorphism and interface discovery as have been discussed elsewhere in this endless meandering thread, it's even more malleable, because you can reason about the way the current "program" is put = together and change it using (sometimes even simple) rules.=20 Now, I believe a lot of the "data-driven" systems I've heard discussed = here involve just such pin-compatibile-reconfigurable-architectures. (I = believe the Halo example was "varying position according to color." ...And that = that is in fact the generality and "emergence-friendliness" that has been = implied but not very well articulated in this thread. Of course, how this somehow is an argument against interface = inheritance, polymorphism, multiple inheritance, or C++ is lost on me. All those = things are extremely helpful in building such architecture. Unless you're still really good at typing "void *". > Yes, they concepts of "emergence" and "data-drivenness" are completely > orthogonal, you can have one without the other (but Turing machines = have > nothing to do with it). |
From: Chris H. <ch...@d6...> - 2003-01-31 22:59:59
|
> >1. Emergent behavior vs. emergent gameplay. >What do you mean the difference is? I noticed you didn't try to >elaborate on the point. Yeah, I wasn't trying to be careful with the actual words, I was just trying to get the broad concept across, sorry about that. But I think there is a somewhat subtle difference that can be talked about. That is, I can differentiate between active objects in the game acting in emergent ways (things like NPCs learning) versus the experience the player has during gameplay being emergent (which is independent of any active behavior of any object in the game). That depends on a definition of "behavior" that maybe needs to be too precise, though. My point was that "emergence" doesn't have to mean all kinds of crazy risky things, or that an NPC's behavior has to show emergent complexity (which is where the religion comes in, often, with things like NNs, GAs, and other learning systems), it just means you build systems that can interact in consistent, predictable, but hopefully rich ways. Those kinds of systems give the player tools to act in the world, and the player's actions can be seen as emergent with respect to the gameplay. Contrast this with the player figuring out the single designer-authored puzzle solution, indentically to every other person who played the same non-emergent game. Does that make more sense? I'm not trying to be super-precise with the words, but the concept seems fairly clear to me. >Yes, they concepts of "emergence" and "data-drivenness" are >completely orthogonal, you can have one without the other (but >Turing machines have nothing to do with it). My point with that comment is that data and code are all the same thing at some level anyway, so it's self-evident that a program's behavior is in many ways independent of its architecture. "Emergence" is behavior, and "data-drivenness" is architecture. Sheesh, who's splitting hairs now? ;) >I still don't see any support for your >statement that a data-driven property system (by which I assume >you mean something on the right-hand side of the scale I refered >to earlier) somehow makes iteration easier than something on the >left-hand side of the same scale. To be honest, I was a bit confused by your scale and how it related to the discussion. The extents of the axis we're talking about (or at least, that I thought we were talking about) are in-code-type-hierarchies on one side, and data-based-type-hierarchies on the other side, and hybrids in the middle. Your scale was more about how much data-drivenness your system had, and didn't really talk about where the types lived, although I'm assuming that they live in code on your left-hand-side. I mean, you kind of defined your left-hand side as being the "appropriate and sane amount" of data-drivenness and the right-hand side as "wacko overengineering", so by that definition, sure, the left-hand side is great! :) Once more with feeling: Putting your object system's types (and obviously the instances) in data is better than putting the types in code (and the instances in data, or not) for games that encourage emergent gameplay. It allows designers to do much more than just changing fixed sets of parameters, all without bothering programmers. It allows them to experiment with and iterate the design more easily because it eliminates a dependency in the development process. There are multiple shipping existence proofs that this works well. I really don't know how to make it any more clear than that. I assume that restatement still doesn't resonate with you? Chris |
From: Kyle W. <ky...@ga...> - 2003-01-31 23:38:48
|
Christer Ericson wrote: > Yes, they concepts of "emergence" and "data-drivenness" are > completely orthogonal, you can have one without the other (but > Turing machines have nothing to do with it). I disagree. Sort of. I think we need to distinguish between emergent *gameplay*, which you can have with an entirely hard-coded engine and no data at all, and emergent *game design*. I think that emergent game design is a good term for what you get when you have a system that's flexible enough to -- without code changes -- create new types of gameplay or implement features in ways that programmers wouldn't have anticipated. I saw this at Cyan when one of our taggers implemented a tank combat game using only canned animations and our in-game trigger system. And I guess basing every moving object on code for doors is an example of the same thing. Emergent behavior, wherever it crops up, gives rise to a host of headaches. It's nice to expose simple blocks (familiar primitives like crates and security cameras in a level, or basic components in a data-driven class hierarchy) from which complex gameplay/game logic can be built, but since you can't ever forsee quite what the final product will be it's easy for people to do things that you wouldn't have wanted. The unwise derivation from "class Door" mentioned above would be an example of that in emergent game design. In emergent gameplay, you have people stacking boxes and getting to areas they shouldn't have been able to reach and falling through the world and so forth. Despite the risks, I like empowering players and desigers. Harvey Smith's written very cogently about the benefits of emergent gameplay, so I won't say anything except that I agree with everything he writes. As for game design... I like empowering designers for two reasons: First, pushing game-specific stuff into data keeps your engine pure and reusable. You can do this anyway if you're good about keeping game code and core engine code separate, but most places I've worked haven't been. Second, a data-driven engine lets everyone do what they're best at. Programmers program, artists create art, and designers create gameplay. When important game features are hardcoded instead of being stored in editable data, programmers end up acting as artist/designers, choosing parameters and tweaking effects in the code or they end up acting as mere tools for the real artists and designers, making changes, fetching an artist or designer to observe, getting feedback, and iterating for the desired effect, over and over again. The programmers become middlemen preventing those who are really skilled at art and design from being able to express their true intent. It sounds like you've had some bad experiences going the too-data-driven route, but I *know* I've had bad experiences with the not-data-driven-enough side of things. I suspect that the world contains more programmers tweaking wrongly hardcoded constants than it contains designers making irrationally laid out data inheritance hierarchies, but maybe I'm weighting my own own experiences too heavily. Anyway, I think in the end we're going to add another layer to the development process. Core engine functionality that has to execute efficiently will be implemented in something like C++. But game objects, AI systems, shaders, and other game-specific features will be implemented in domain-specific languages by programmers who specialize in those tasks, and may not even have a foundation in any general-purpose programming language. Regards, Kyle |