Poll: Object systems

[bump]
Sorry, had to do it. Won''t do it too much.

I might be misunderstanding but you seem to be more contrasting "good" object oriented programming with "not so hot" object oriented programming.

Logically, you would wish to on some base level for at least your data classes have a heirarchical grouping for the purpose of saving you effort. For instance, it would be silly to have CZombie and CRat and CSkeleton be totally independent classes, because as creatures they have a lot in common. It would be much more efficient to have a CCreature class from which they derive, so that the CCreature can have common attributes such as position, hitpoints, stats, etc. In fact, the question often raised is whether or not the different types of CCreature are different to an extent that would imply the use of separate classes, rather than a simple definition of differences such as AI type used and sprite set to show. If you use identical boxes to represent a zombie and a rat, I think you would be hard-pressed to tell which was which in most games other than attribute numbers regarding speed, hitpoints, etc, that can be contained in a simple CCreature class. The real question I''ve found when doing object oriented programming of this type is whether or not to restrict myself to pure data classes and manipulate them (display, etc) on a higher level. In my work, I tend toward pure data classes simply because I am required to allow for cross-platform programming. Given the luxury of a single platform I would probably attempt to internalize functionality into what are currently pure-data classes.

I fail to see how an irrelevant property placed in an object would cause slowing. I can put thousands of lines of code into a file, but if they are irrelevant I will most likely never actually call them, which would imply a waste of disk space but functions that are never called will never be executed and therefore will never eat CPU cycles after the game loads. Then again most people don''t sit around thinking up functions to arbitrarily put into their classes, I for one at least put in functions as I require them. I also would hope that your first example wouldn''t be implemented by a seasoned coder, for in the majority of games I''ve played, truly all a "table" is is an immobile object which would really be no different from a "lamp". It seems much simpler to switch on and off attributes (Can I walk over it? determined by, say, m_bIsSolid) unless you wish a more immersive experience, in which case you can derive CLightObject (lamp) from the base CImmobileObject (table) and give CLightObject the necessary properties to allow the light emitted to be interpreted.

-fel

Well, the new games should be even more abstract in terms of objects. After all, how would *you* make a good mod for a game if you can''t chnge a weapon''s or monster''s property with a new one in order to create a new weapon/monster. I believe that interpreting the whole thing(monster/weapon) from a file, or haveing a veeeery abstract class for it would be perf.

quote:

---

Original post by felisandria

I might be misunderstanding but you seem to be more contrasting "good" object oriented programming with "not so hot" object oriented programming.

---

Not really. In the Dark Engine, there was no such thing as a class like CCreature, at all. An object was defined by its properties.

quote:

---

Logically, you would wish to on some base level for at least your data classes have a heirarchical grouping for the purpose of saving you effort. For instance, it would be silly to have CZombie and CRat and CSkeleton be totally independent classes, because as creatures they have a lot in common. It would be much more efficient to have a CCreature class from which they derive, so that the CCreature can have common attributes such as position, hitpoints, stats, etc.

---

Yes, of course. But that's still a code-based object hierarchy. In other words, you have to recompile if you wish to change any of the four classes, whether it be the children or the parent.

quote:

---

In fact, the question often raised is whether or not the different types of CCreature are different to an extent that would imply the use of separate classes, rather than a simple definition of differences such as AI type used and sprite set to show. If you use identical boxes to represent a zombie and a rat, I think you would be hard-pressed to tell which was which in most games other than attribute numbers regarding speed, hitpoints, etc, that can be contained in a simple CCreature class.

---

(the smilies are in here to put emphasis on the fact that I'm not trying to be pointy)
Think about Thief and System Shock for a moment. If you can't think of them, I'll tell you that there are about 400 different properties that define Dark's objects, and all of them interact in complex ways. Also, all of them are set by the designer - not the coder. There is no such thing as an "object class". Properties are classes that define the functionality of whatever object they describe.

quote:

---

The real question I've found when doing object oriented programming of this type is whether or not to restrict myself to pure data classes and manipulate them (display, etc) on a higher level. In my work, I tend toward pure data classes simply because I am required to allow for cross-platform programming. Given the luxury of a single platform I would probably attempt to internalize functionality into what are currently pure-data classes.

---

Data classes? You mean classes that have no operations except on their data? Perhaps. But that is not what I was referring to. The idea of a property-centric system is to ensure that the designer, not the programmer, sets the behavior of objects. Even if the programmer were to die or leave and never come back.

quote:

---

I fail to see how an irrelevant property placed in an object would cause slowing. I can put thousands of lines of code into a file, but if they are irrelevant I will most likely never actually call them

---

You wouldn't. Suppose, as it is in Dark, you have a callback manager that notifies these "properties" of events. Currently, every property is notified of an object's creation, regardless of its relevance to that particular object. So, if you have 400 properties, every one gets called on object creation, even if they don't do anything. Hardwiring relevance would break the whole abstraction idea. There are a couple of solutions to this, of course.

quote:

---

, which would imply a waste of disk space but functions that are never called will never be executed and therefore will never eat CPU cycles after the game loads. Then again most people don't sit around thinking up functions to arbitrarily put into their classes, I for one at least put in functions as I require them. I also would hope that your first example wouldn't be implemented by a seasoned coder, for in the majority of games I've played, truly all a "table" is is an immobile object which would really be no different from a "lamp". It seems much simpler to switch on and off attributes (Can I walk over it? determined by, say, m_bIsSolid) unless you wish a more immersive experience, in which case you can derive CLightObject (lamp) from the base CImmobileObject (table) and give CLightObject the necessary properties to allow the light emitted to be interpreted.

---

I think ya missed the point of my message. The point was to emphasize the second approach versus the first. The second approach, as written, does not involve any code-based object hierarchy. I better clarify it.


Edited by - GayleSaver on January 2, 2001 6:25:05 PM

Could you clearify what exactly you mean by method two?
Typically, object is the name given to the abstract idea, and class is the name given to the code implementation. A tree of inheritance & objects defined by thier properties seems contradictory. Is there a base method to query what properties a derived class has?
You wouldn''t want to make a function call, much less a virtual call for each object that needs rendering. You might assemble a scene using objects like that, but they would alter a VB or DL. And if they don''t move (or change like the light may), they would only do it once.

I''d also like to point out that method 1 is not OO.
No virtual, no OO.
Method 2 might not be OO either. An iheritance tree doesn''t make it OO (though it could be unlike #1).

Let me explain myself.

In #1, you write code for objects. You might write code to make creatures behave like creatures (even if you don''t specify which creature), or make tables act like furniture (again, even if you don''t specify that it''s a table).

In #2, you don''t write code for objects. You write code for properties. "Shape", "Texture", "ReactToPlayer", "AI", and so on. Properties have, therefore, control over the object''s appearance and behavior. Entirely. If the programmer that wrote the properties left, designers would be able to work with them without his help or knowing how they are implemented, as I can in DromEd. Essentially, there is no such thing as an "object class". All objects are defined by their properties. Abstraction. In DromEd, I can create a "Blue Hammer" simply by deriving a node from the "hammer guard" node. All properties that apply to "hammer guard" will be transferred. I can override any property I choose. In this case, "Shape".

#2 can be a little messy if you put, for instance, "AI" on an inert object or "Shape" on an un-rendered object. But that only happens if you have no idea what a property applies to. Which many of us didn''t when LG first released DromEd.

Clearer?

Are you saying that Thief (the only Dark Engine game I''ve played) holds tables, lights, objects, weapons and animated characters (etc) as the same data-type?

I''d say there''s definitely a case for splitting the world into categories, but they could well be broad ones. There''s no point in using the same class for a table and a zombie; the code will act (very) differently, so its quicker to have the table as ''scenery'' (or an ''object'' if you can move it) and the zombie as some sort of ''being'' (thing that moves around and does stuff). You''d never want to even attempt to have a table pick up an axe and come for you, so why allow designers to try?

This old/new terminology was bound to wind people up, but its a valid question

Dave

As far as I know, the argument they used was flexibility. It''s really handy for the designer to be able to create new objects, ones the programmers hadn''t arranged for, using existing properties. It''s kind of like a mix-and-match game. Hell, you COULD have a table come at you with a hammer. But that''s not the point. The point is to allow recombination of different properties to create ANY object. Thief stores objects as nodes of trees, i.e. collectiosn of property data. The designer sets these properties.

Why allow the designer to try? Heh, all I can say is, they WERE Looking Glass, most of them smart enough to understand how to use the system properly.

Yes, wouldn''t it be nice if designers could just talk to their computers and have it all come out beautifully... You might not like the fact that I''m talking implementation but somebody''s got to code the thing.

You totally missed my point. I''ll make it simpler.

Making separate classes for each type of creature or object in a game, as your first example suggests, is dumb.

Making objects generalized enough to allow for scripting is smart.

Aggregates become more obvious as you consider what the thing you are making is capable of.

Scripting is cake if you can break everything in your world down into a few basic types. I spent 6 months working on an Ultima Online server emulator. We had I believe 6 major classes that described every object in the world, and a full script engine. Some of the NPC''s people scripted for us were simply incredible.

As for your "properties" model, I don''t think you''re explaining it very clearly. Please retry. Properties such as rendering are usually handled on a .dll level, because the physical implementation of your object most makes sense as a property of that object, but rendering a table is truly no different than rendering one animation frame of your character, code-wise. The difference is that a character-object has the ability to move, whereas a table does not. So, put your rendering off in a drawing .dll somewhere and forget about it.

-fel

That''s actually kinda neat, I''m beginning to understand it

Is there a finite fixed number of properties, or can designers add new ones? How do they define the interaction of the objects and how the property manifest itself in the game?

fel,

Guess I came across insulting. Well, I''m sorry about that.

I don''t have time to reply. Give me an hour and a half.

I think I get it, or if I didn't get it it at least gave me a cool idea. What I think you mean is, you have a basic game object (let's say CGameObject) which can contain properties (in a simple linked list for example) these properties are in themselves classes which contain a specific interface, this interface can respond to events. Properties are defined by a string (or number ID) they are either hard-coded or loaded from a dynamic library (DLL or SO). The designer can say (in either a scripting language or using a nice GUI):
myObject = CreateNewGameObject()
myObject.AddProperty("RENDERABLE");
myObject.GetProperty("RENDERABLE").SetValue("Model", "myShip.3ds");
myObject.AddProperty("CLOAKABLE");
myObject.GetProperty("CLOAKABLE").SetValue("MaxAlpha", 50);

It would of course be nicer with a GUI with property sheets (like activeX) but what happens in the graphics engine is: The Engine sends a 'prepare to render'-message to all objects with the property "RENDERABLE", which in turn sends a similar message to all other properties in the object that contains this property but NOT to the object itself since it's only a base class for ALL objects. Continueing the previous example, "CLOAKABLE" would recieve the message from "RENDERABLE" and set the alpha value of the model to 50% [edit]by calling certain functions on the "RENDERABLE" property[/edit] and once it's finished the engine sends 'render thyself'-message to all "RENDERABLE" objects and the "RENDERABLE" property creates all the necesarry things to render itself (indexbuffer, vertexbeffer, etc.) and renders itself.

It's sort of like 'run-time dynamic interfaces'.

Gyzmo
=======================
Meddle not in the affairs of dragons for you are crunchy and go well with toast.

Edited by - Gyzmo on January 3, 2001 8:25:56 AM

quote:

---

Original post by Magmai Kai Holmlor

That''s actually kinda neat, I''m beginning to understand it

Is there a finite fixed number of properties, or can designers add new ones? How do they define the interaction of the objects and how the property manifest itself in the game?

---

It is usually fasted to use an array of pointers- so there would be a fixed number of poperties possible for a single object. As
far as available properties, no limit. But the more flexable you make a property, the more code it needs (trust me). I wrote such a system for my engine (called them properties -> behaviors) and
found several challenges along the way. Mostly to do with passing data among the behaviors, since they need to interact.





ill-lusion.com

ziggy@ill-lusion.com

quote:

---

Original post by felisandria

Yes, wouldn''t it be nice if designers could just talk to their computers and have it all come out beautifully... You might not like the fact that I''m talking implementation but somebody''s got to code the thing.

---

Well, I''m talking implementation too - of properties instead of root classes.

quote:

---

You totally missed my point. I''ll make it simpler.

Making separate classes for each type of creature or object in a game, as your first example suggests, is dumb.

---

I was pointing out an example, not asserting that this is the way it should be done.

quote:

---

Making objects generalized enough to allow for scripting is smart.

---

Smart enough, but not superbly flexible. According to LG, taking Thief and making it into System Shock 2, given the art and the source code of the properties, took them relatively little time. That''s right: most of the properties that applied to Thief applied to System Shock, as well. Were the objects similar? I don''t think so. A similar system was used in the ill-fated JAS. Now, if you recall Starcraft, to create a new unit was impossible even with the many tools that were released by third parties. To create a new unit, scripted or otherwise (if scripting was involved), you''d have recompile a lot of the source code and a new EXE.

To be honest, I think that the most efficient type of scripting is the kind that Dark has, where you attach scripts to archetypes in the tree, so that they can add any functionality that properties do not.

quote:

---

Aggregates become more obvious as you consider what the thing you are making is capable of.

Scripting is cake if you can break everything in your world down into a few basic types. I spent 6 months working on an Ultima Online server emulator. We had I believe 6 major classes that described every object in the world, and a full script engine. Some of the NPC''s people scripted for us were simply incredible.

---

As for your "properties" model, I don''t think you''re explaining it very clearly. Please retry. Properties such as rendering are usually handled on a .dll level, because the physical implementation of your object most makes sense as a property of that object, but rendering a table is truly no different than rendering one animation frame of your character, code-wise. The difference is that a character-object has the ability to move, whereas a table does not. So, put your rendering off in a drawing .dll somewhere and forget about it.

-fel
Ah. Indeed. Well, now let me explain it more clearly. the properties are classes in code. The objects are not. They are data driven. The advantage is that the designer gets a lot of power.

Your assumption that System Shock 2 and Thief are extremely different in an object sense is incorrect. You''re thinking in terms of the intrusion of an object into the world, whereas I''m looking at it from a basic functionality viewpoint. Trying again:

There will be, in a game, "things that interact". This can be the player or any NPC, enemy, etc. These things have a single set of sub-behaviors that can be aggregated into a class. Yes, you can plug in properties. The ability to use range weapons, for instance. The AI involved, usually a set of state probabilities (chance to attack, chance to retreat, chance to leave you alone, this can be as complex as you would like). There will also be "Things that sit there". You can add behaviors to these based on your system of input, though if the behaviors are complex to enough of an extent you would merely make it an immobile "Thing that interacts". An object model based on data meant from the beginning to use scripts to define abilities and properties is really extremely powerful and versatile. Remember, the actual drawing code is in a .dll, so any drawing is dropped into a module. Consider one of the NPC scripts made for the emulator I worked with, called the "elven cavalry archer". Based on a simple "things that interact" object, the archer would scout to you to "determine your intent", and if he decided you were a threat would perform a sort of guerilla warfare on you, done using simple probability calculations within the AI state machine framework.

In order to use this model, you must make a few basic assumptions, yes, but in general they are generic to a sufficient extent, in my mind at least. For instance, a weapon object must have a damage range, a delay, possibly an "allowed users" property, a distance range, a weapon set of animations, a weapon-use set of animations, a name, and possibly a set of "further effects" (such as right clicking on it producing a bottle of water or something), and you might wish to include things such as position and ownership depending on how you are setting up data relationships. I challenge you to find a weapon that cannot be covered by these properties, regardless of the game type.

I think the biggest problem I''m having with your argument is your assertion that there is literally no object implementation of the interactive "things" in the game. Is this so?

-fel

Flexibility is not an issue here. The flexibility is dependant on the actual engine, and not on these two ideas. These are just two design decisions. An engine can be created which allows creation of regular objects (like in the first case) without recompilation. It all lies on the scriting language, the editor, and the engine.

Let me clarify more with a quote from Anonymous:
"Basically, the Property System is actually just a client of the Object
System. The Object system is basically just a callback manager, plus
it
manages the ID list. An object is nothing more or less than it''s ID.
Really, that''s it. Then what happens is that systems that care about
IDs
hook their callbacks into the Object System. One of those systems was
the
Property System. Another one was the Link System. "

FYI, Anonymous worked at Looking Glass.

Now, my own responses.

quote:

---

By clonemaker:
Flexibility is not an issue here. The flexibility is dependant on the actual engine, and not on these two ideas. These are just two design decisions. An engine can be created which allows creation of regular objects (like in the first case) without recompilation. It all lies on the scriting language, the editor, and the engine.

---

In my opinion, it is. You see, in the long run, it''s easier to click my mouse and write in little dialog boxes than write scripts. And if I''m a designer, it''ll mean the difference between working independently and calling over a programmer.

quote:

---

By felisandria:
Your assumption that System Shock 2 and Thief are extremely different in an object sense is incorrect. You''re thinking in terms of the intrusion of an object into the world, whereas I''m looking at it from a basic functionality viewpoint.

---

Oh, I''m as basic as I can get. You see, as Anon''s email indicates, you have a callback manager that informs properties of object creation. The Property and Link systems were very basic concepts. If you''ve ever seen DromEd, you can choose properties from a long list and edit each one''s value. That''s right: you choose them, from a list. You don''t fill out ONE form.

quote:

---

There will be, in a game, "things that interact". This can be the player or any NPC, enemy, etc. These things have a single set of sub-behaviors that can be aggregated into a class. Yes, you can plug in properties. The ability to use range weapons, for instance. The AI involved, usually a set of state probabilities (chance to attack, chance to retreat, chance to leave you alone, this can be as complex as you would like). There will also be "Things that sit there". You can add behaviors to these based on your system of input, though if the behaviors are complex to enough of an extent you would merely make it an immobile "Thing that interacts". An object model based on data meant from the beginning to use scripts to define abilities and properties is really extremely powerful and versatile. Remember, the actual drawing code is in a .dll, so any drawing is dropped into a module. Consider one of the NPC scripts made for the emulator I worked with, called the "elven cavalry archer". Based on a simple "things that interact" object, the archer would scout to you to "determine your intent", and if he decided you were a threat would perform a sort of guerilla warfare on you, done using simple probability calculations within the AI state machine framework.

---

Who wrote the script? Was he/she proficient in programming?

quote:

---

In order to use this model, you must make a few basic assumptions, yes, but in general they are generic to a sufficient extent, in my mind at least. For instance, a weapon object must have a damage range, a delay, possibly an "allowed users" property, a distance range, a weapon set of animations, a weapon-use set of animations, a name, and possibly a set of "further effects" (such as right clicking on it producing a bottle of water or something), and you might wish to include things such as position and ownership depending on how you are setting up data relationships. I challenge you to find a weapon that cannot be covered by these properties, regardless of the game type.

---

I meet your challenge. In Thief, there is no such thing as a weapon with set statistics. There is a) a player arm that looks like one b) an arrow object (projectile) c) an actual archetype FOR the weapon. Is the damage determined inside the weapon? In part, but mostly by a system called Act/React, wherein you can set how objects behave when other objects interact with them. Please remember that in a believable game, inanimate objects want to react to weapons. If a designer wanted to make a table fall apart when hit with a sword, he could just add a receptron for "Sword (-111111)" and set the action to, let''s say, "Break" with a "Debris" parameter. Just as an example. What about #1? Could the designer set these relationships? How many properties would you have stacked for each object to allow him to? As many as Starcraft (per unit)?

quote:

---

I think the biggest problem I''m having with your argument is your assertion that there is literally no object implementation of the interactive "things" in the game. Is this so?

---

As Anon said.

quote:

---

By Gyzmo:
It would of course be nicer with a GUI with property sheets (like activeX) but what happens in the graphics engine is: The Engine sends a ''prepare to render''-message to all objects with the property "RENDERABLE", which in turn sends a similar message to all other properties in the object that contains this property but NOT to the object itself since it''s only a base class for ALL objects. Continueing the previous example, "CLOAKABLE" would recieve the message from "RENDERABLE" and set the alpha value of the model to 50% [edit]by calling certain functions on the "RENDERABLE" property[/edit] and once it''s finished the engine sends ''render thyself''-message to all "RENDERABLE" objects and the "RENDERABLE" property creates all the necesarry things to render itself (indexbuffer, vertexbeffer, etc.) and renders itself.

---

You''ve almost got it. The Engine sends the message to properties, not objects. The properties installed themselves into the engine itself, a queue of sorts (a list, probably). The reason it can''t send a message to objects is because objects don''t *exist*.

quote:

---

By Magmai Kai Holmlor:
Is there a finite fixed number of properties, or can designers add new ones? How do they define the interaction of the objects and how the property manifest itself in the game?

---

Designers can''t add new ones. But, as in any system, the properties can be as specific or as abstract (hopefully) as the programmers define them. Additionally, the properties are defined not on a when-needed but on a "what should the engine be able to do?" basis.

--VK

Ah well then we haven''t done anything revolutionary...
Effectively you have a massive web of possible interactions. There is some null behavior defined, and the designers so crazy trying to fill in all the interactions.

It''s the creation tool thats different, and lacking in other games.