3 ms·

That's a neat post, the talk about Wyvern gets me really excited because game programming is my primary domain of interest. Someone please enlighten me; is the

That's a neat post, the talk about Wyvern gets me really excited because game programming is my primary domain of interest. Someone please enlighten me; is the property model pretty much just reverse or non-hierarchical OO? Instead of saying "J.T. inherits from football player" you say "football player doesn't really exist, J.T. just inherits from a bunch of objects which are instances that have the properties of a football player"? The difference here is that inheritance is more like a node graph and a not top-down hierarchy, where the only real root object is the super-generic "object" object. If this is true, what about the "Chieftain" example Yegge said he left out? Is there a prototype called "Chieftain" which objects can inherit, but which alone doesn't fully implement a game object? Is it the case that you can't have "Chieftain" objects running around, as they only have all the properties needed when they are, for example, an "Orc Chieftain"?

silentbicycle 18y ago
> The difference here is that inheritance is more like a node graph and a not top-down hierarchy, where the only real root object is the super-generic "object" object. Right, although there isn't necessarily an Object that everything inherits from. You have an object, whose properties (both value fields and methods) are contained in a string-keyed table. If you want to inherit from it, you create another (probably via a method called "new") which defers to it when anything tries to find keys the new object hasn't overridden. If you think of the initial object as a Class object that instantiates instances, that's the idea, but you don't need to have an explicit class for something you'll only ever have one instance of - you can just build it in place. (Want a singleton? Don't give it a method that spawns new instances. Done.) It's more generalized than OO systems in which Classes and instances are two fundamentally different things. It may be helpful to read the chapter on OO in _Programming in Lua_ (linked above): It has a very concise intro to prototype-based OO. Lua may also be worth a look since you're interested in game development -- it is quite popular as an embedded scripting language in the game industry (and a pretty cool language in general, I think :) ). Also, see: http://c2.com/cgi/wiki?ClassesPrototypesComparison http://c2.com/cgi/wiki?ClassesPrototypesComparison
groby 18y ago
If game programming is your interest, you might want to also look at Scott Bilas presentation for a "data-driven object system": http://www.drizzle.com/~scottb/gdc/game-objects.ppt http://www.drizzle.com/~scottb/gdc/game-objects.ppt They implemented pretty much what Steve is describing for Dungeon Siege. (Presentation was in 2002, so they started on it probably around 2000. Take that for "no earlier references", Steve ;) I vaguely recall that Thief used a similar system, too. There's also at least on "NextGen" game that uses that system that I'm aware of. It's pretty powerful (and makes it incredibly easy to shoot yourself in the foot) As for the "Chieftain" example - it's usually solved by providing multiple prototypes for an object. With all the ensuing uglyness.
- nihilocrat 18y ago
  Thanks for the link! I actually saw something almost exactly like this by someone who was working for Looking Glass, but it didn't go in depth about the scripting layer, it just mentioned that you could either go with "static" classes, "data-driven" classes, or a hybrid. In my own development, I've generally gone with hybrid just because the value of flexibility surpasses any sort of performance hit, but I still keep some of the very simple stuff (object position, velocity, etc.) in the static layer.

silentbicycle 18y ago

> The difference here is that inheritance is more like a node graph and a not top-down hierarchy, where the only real root object is the super-generic "object" object. Right, although there isn't necessarily an Object that everything inherits from. You have an object, whose properties (both value fields and methods) are contained in a string-keyed table. If you want to inherit from it, you create another (probably via a method called "new") which defers to it when anything tries to find keys the new object hasn't overridden. If you think of the initial object as a Class object that instantiates instances, that's the idea, but you don't need to have an explicit class for something you'll only ever have one instance of - you can just build it in place. (Want a singleton? Don't give it a method that spawns new instances. Done.) It's more generalized than OO systems in which Classes and instances are two fundamentally different things. It may be helpful to read the chapter on OO in _Programming in Lua_ (linked above): It has a very concise intro to prototype-based OO. Lua may also be worth a look since you're interested in game development -- it is quite popular as an embedded scripting language in the game industry (and a pretty cool language in general, I think :) ). Also, see: http://c2.com/cgi/wiki?ClassesPrototypesComparison http://c2.com/cgi/wiki?ClassesPrototypesComparison

groby 18y ago

If game programming is your interest, you might want to also look at Scott Bilas presentation for a "data-driven object system": http://www.drizzle.com/~scottb/gdc/game-objects.ppt http://www.drizzle.com/~scottb/gdc/game-objects.ppt They implemented pretty much what Steve is describing for Dungeon Siege. (Presentation was in 2002, so they started on it probably around 2000. Take that for "no earlier references", Steve ;) I vaguely recall that Thief used a similar system, too. There's also at least on "NextGen" game that uses that system that I'm aware of. It's pretty powerful (and makes it incredibly easy to shoot yourself in the foot) As for the "Chieftain" example - it's usually solved by providing multiple prototypes for an object. With all the ensuing uglyness.

nihilocrat 18y ago
Thanks for the link! I actually saw something almost exactly like this by someone who was working for Looking Glass, but it didn't go in depth about the scripting layer, it just mentioned that you could either go with "static" classes, "data-driven" classes, or a hybrid. In my own development, I've generally gone with hybrid just because the value of flexibility surpasses any sort of performance hit, but I still keep some of the very simple stuff (object position, velocity, etc.) in the static layer.