Advertisement

Possibilities of stat heavy objects/locs?

Started by March 13, 2001 03:41 AM
11 comments, last by Wavinator 23 years, 9 months ago
I''m sure this has come up before, but I haven''t seen it... Consider a game like Fallout or Baldur''s Gate. Imagine you were trying to make a very responsive, alive game world using something like their engines. One way to do this might be to load each object and location with stats and make them (almost?) as detailed as the player''s character. For example, you could apply stats to an object such as whether or not it is stolen, dirty, flammable, wet, poisonous, edible, tasty, etc. It seems that it would be easy to apply other affects based on object use rules or location. Applying water to something that''s burning, for example, would put it out. Effects could be governed by environment and player actions, and might be able to create a deeper sense of roleplay: How interesting it would be if you returned the king''s amulet, but it was muddy because of the fight you had on the way to the castle, and for the insult he therefore sentenced you to death. Rather than scripting something like this, the king would simply require that his amulet be returned in pristine (a stat ir flag) condition, and the player''s own Perception stat, or Charisma, or NPC advisor intervention, would affect how this played out. I could see things like NPCs responding to shabby dress; animals tracking the scent of fresh meat (to a trap or YOU, if you got the scent on you); players having to beat back fire and smoke to escape a burning inn; etc., etc. It all seems feasible if you come up with a boatload of stats that apply to locations or objects. I can see doing this without need of a super-complicated physic engine or graphics technology, if you accept that all you need is a semblance, not a super-complex physics / graphics engine. Thoughts? I''d like to start a stats / properties list, too, if people are interested. The environment, for example, might need air if something is flammable. -------------------- Just waiting for the mothership...
--------------------Just waiting for the mothership...
The problem if you take the nethack approach (basically, tons and tons of characteristics, that can interact with each other), is that you end up with spaghetti code, and more importantly, that it''s a real nightmare to modify anything or maintain it.

I say that ''cause one of my goals for my Masters is to increase the level of *meaning* of the environment.
At present, with an engine like Halflife for instance, you can have portions of space that are full or empty. Then you can have water, or other fluids with different properties. But you dont have meaning like "this is a door", rather you''ll have a collection of polygons that have no meaning whatsoever.

What I am trying to do, is to add more meaning to the environment. At the moment, the way I see it, is that you''d have to add a layer of information to the layer of physical data. You''d have a set of polygons, but then you''d have a set of meanings associated to those polygons.
If you extend the concept (which is what I intend to do, if all goes well), you can assign not only meaning, but rules of behaviour so to speak.
"water destroys fire","fire destroys wood","wood floats on water", would be rules, for instance.
Given enough of those, and a good engine that can make deductions, suppositions, and so on, and you have something pretty interesting.

I realise I am biased towards an AI approach, but please, give me your views as well, as I am still in a design phase, and am trying to freeze my ideas to something that would be feasible.

Do I make any sense at all ?

youpla :-P


Sancte Isidore ora pro nobis !
-----------------------------Sancte Isidore ora pro nobis !
Advertisement
I agree with ahw, a BIG list is going to be a pain to maintain. I do disagree with the "attaching stats to polygons" method, and prefer the "attaching polygons to stats" method (whats different, well with the second method you can replace the polygons with whatever you like, text, a 2D sprite, etc... [Besides I hate polygons, anything other the a FPS should not have an emphasis on 3D in my opinion, 3D is a later enhancement...]) I like the world AI approach! something I briefly suggested in the "lets put these ideas into one game" thread...

For you approach Wav I think you need to split your objects into two (as it were). TYPES OF OBJECTS and INSTANCES OF OBJECTS. TYPES OF OBJECTS would be things like "rocks" "Wood" "Axes", etc. and would contain details on weight, size, flamability, etc. INSTANCES OF OBJECTS would have a pointer back to thier OBJECT TYPE and flags that state if they are on fire, etc.

The next "chunk" is taken out of a design doc for an RPG.. which I wrote (the design, not the RPG that is) and hopefully should demonstarte what I''ve just been "talking about". [Btw I''ve cut a lot of bits out of this b4 posting it]



27.3.1 Object Types
Type objects are special generic objects that are not used in the game, object types are used when multiple, nearly identical objects are required, e.g. power-cells or other ammo.

Attribute Description Type
Weight Players can only hold a fixed weight of objects (strength). This is the weight of the object
Size How big the object is
Light Flags whether the object is a light source or not
Clothing Flags whether this object can be worn (e.g. armour)
Container Flags if this object can have other objects placed inside of it
Capacity Size of the largest object than can fit inside the container
Door Flags if this object has an opening.
Lockable Flags if this object can be locked or unlocked
Food Flags if this object is edible


27.3.2 Game Objects
Game objects are items in the world that the player (and NPC’s) can pick up, drop, steal, interact with, etc. (But not necessarily all of those…e.g. Doors, guns, levers, bombs, etc.) Objects are derived from Type Objects and have the following additional attributes:

Attribute Description Type
Active Flags if this object is switched on or off
Door Status Flags if the object is open or closed
Ammo How much ammunition this object contains
Loaded Object number this object is ‘loaded’ with
Contains List of objects this object contains
Locked Flags if the object is locked or unlocked



The problem of fire can create several attributes by itself, you have things like:

Flamability: How easy it is to set something on fire (a value of say 0 indicates the object will not burn), petrol is much easier to light than wood for example
Burn Rate: How fast the object burns up. A candle burns slowly, gunpower quickly.
How to put it out: You cant put a petrol fire out with water.
etc.

Note: Anything on fire also needs to be taged as a light source, and would need a brightness value.

NightWraith
NightWraith
classes and inheritancy are good for that:
Wooden Door is a Door and a Wooden Object
A Door is a moveable object with actions Open, Close, Lockpick
A Wooden object is flameable, axeable (does this word exist ?) and whatever.

I think this would lessen the memory use as common parts will be defined once...
Moreover for a spell wich affects only metalic objects, it avoids to list all objects made of metal (sword, dagger, shield, plate this and plate that...)

Ahw, this is good for AI as it allows generalization, for example "give me the fruit", an apple is a fruit so the NPC gives the apple...






------------------"Between the time when the oceans drank Atlantis and the rise of the sons of Arius there was an age undreamed of..."
(Without thinking about about this idea in depth...)

Could each item have like a linked list of attributes? An attributes class having maybe the name of the attribute, one or two numeric data values, and a pointer to the next or last attribute? Then just stack attributes onto an item as appropriate.

If you drop an item into some mud, tack on a DIRTY-10 attribute.
If an item falls into a fire check against the COMBUST attribute to see if it ignites.

If it was me, I''d probably try for something like this.
This sounds like a fairly decent system to make a more interactive world. (On the programming side I can''t advise you:Sounds like quite a lot of work). From a game design side it might be easier to work out the scope of the game first, ie. do you really want variables for how dirty something is?

(BTW, I think it would be "interesting" but not "fun" if the king sentenced you to death for allowing his amulet to get muddy, especially if you had just valiantly fought to retrieve it).

For a turn based game I think that this would work quite well .


quote: Original post by DungeonMaster


Ahw, this is good for AI as it allows generalization, for example "give me the fruit", an apple is a fruit so the NPC gives the apple...


This is probably the topic for a new post? . Makes me think of Ultima Underworld & it''s barter system.
Advertisement
quote: Original post by Ketchaval
(BTW, I think it would be "interesting" but not "fun" if the king sentenced you to death for allowing his amulet to get muddy, especially if you had just valiantly fought to retrieve it).


I agree unless the player had a few ways to escape the death sentence. Then it would be fun because it would be a whole adventure generated by that one detail. Although, I think it may be only fair to somehow inform the player that the king may not appreciate a muddy amulet (by some NPC''s dialogue of something). Although that''s a compeltely different topic.




Need help? Well, go FAQ yourself.
What a plight we who try to make a story-based game have...writers of conventional media have words, we have but binary numbers
Need help? Well, go FAQ yourself. "Just don't look at the hole." -- Unspoken_Magi
quote: Original post by Nazrix

I agree unless the player had a few ways to escape the death sentence. Then it would be fun because it would be a whole adventure generated by that one detail. Although, I think it may be only fair to somehow inform the player that the king may not appreciate a muddy amulet (by some NPC''s dialogue of something). Although that''s a compeltely different topic.



Actually, you''re still right on topic ("Possibilities of stat heavy objects & locations")

And you (of course ) got what I was saying: The whole point of a stat as insignificant as "is object dirty" was to generate more world detail and adventure, and make you feel like you''re in a more responsive world.

The main value of something like this would be gameplay that''s emergent from the interaction of properties of objects and locations (and NPC responses to this) versus scripted sequences.

Scripted sequences would guarantee behavior, but this seems to doom us to limited gameplay. Rather than the fun of figuring out solutions for ourselves, we have to think like the designer and figure out what he wanted us to do. We have to, for example, find the Holy Fire Extinguisher of Quay to put out the fire, rather than use our flask on the stream, fill it, and put out the fire.

Maybe I''m out of step with this. Is it not fun to figure out how to solve problems in a game yourself? (As opposed to: Talke to this NPC to get problem-solving-key, go use problem-solving-key on problem, etc)



--------------------
Just waiting for the mothership...
--------------------Just waiting for the mothership...
quote: Original post by Ketchaval

(BTW, I think it would be "interesting" but not "fun" if the king sentenced you to death for allowing his amulet to get muddy, especially if you had just valiantly fought to retrieve it).


Hey, but wait a minute.

If you''re playing an RPG, what does this say about the king? He''s a frivolous twit! You work your butt off to get his damn amulet, and he''s mad because it''s dirty!!! If this were communicated with drama and dialog, wouldn''t it reinforce character, the game universe and role-playing in general?

Now, is it only "interesting" but not "fun" because it''s a loss situation, or because it''s too detail specific? What if I said that the amulet was bloody? Or that your clothes were dirty and bloody?

Some of this may be too detailed, but the thought is that if the world is more natural, it will be more responsive and involving.

(Oh, and I didn''t say above that you wouldn''t have defenses against these situations, only that they could exist without inflexible scripting)

--------------------
Just waiting for the mothership...
--------------------Just waiting for the mothership...
What if we had a production system that could create what are called *elaborations* based on inter-relationships between concepts? What if this production system maintained itself, all dependencies and automatically removed all inductions that were no longer valid once they have lost support? What if this system could efficiently operate even after the production system has had as many as one million seperate rules encoded into it?

What if we encoded rules that included but were not limited to facts that included three elements comprised of an Identifier, an Attribute, and a Value. So we have facts that essentially say that a thing identified by an Identifier has a Value associated with it via an Attribute. Something like this:
Identifier: Molly's Horse
Attribute: InstanceOf
Value: HorseTypeAnimal
What we're really saying above is Molly's Horse is an InstanceOf the Category HorseTypeAnimal.

What if we went on to say things like this:
Identifier: InstanceOf
Attribute: Inverse
Value: Instances
What we're really saying is InstanceOf has an Inverse which is Instances. Notice that where InstanceOf was used as an Attribute in the horse example, it is now being used as an Identifier.

What if we said:
Identifier: Inverse
Attribute: Inverse
Value: Inverse
What we're saying is the Inverse of Inverse is Inverse.

Now, what if we said: If X is an Inverse of Y and Z has an Attribute X with Value W, then W has an Attribute Y with value Z.

So, in effect, by saying that Molly's Horse is an InstanceOf HorseTypeAnimal, the system induces that HorseTypeAnimal has an Instance known as Molly's Horse.

This is only the beginning.

We identify to the system what Molly's Horse is. Later, the system is making inferences about Mammals. These inferences are passed to Instances of Mammals. Incidentally, because HorseTypeAnimal is a SubClass of Mammal, then Mammal automatically gets HorseTypeAnimal as one of its SubClasses.

The Inverse of Father is FatherOf.
The Inverse of Parent is Children.
The Inverse of Mother is MotherOf.
The Generalization of Father is Parent.
The Generalization of Parent is Ancestor.
The Inverse of Inside is Contains.
The Inverse of MadeOf is MadeFrom.
The Generalization of MadeOf is ComposedOf.

This is still just the beginning.

A system built with rules like this can reason about the world that the player is playing in.

Building a system like this enables you to carry all of these rules into the reasoning knowledgebase of the characters in the game. NPC's can use the rules to solve problems and reason about the world they are in.

A system like this can be used to build hypothesis about the world and the beliefs of others. Handling the attributes of objects is actually trivial and only the beginning.



Edited by - bishop_pass on March 13, 2001 12:13:20 AM
_______________________________
"To understand the horse you'll find that you're going to be working on yourself. The horse will give you the answers and he will question you to see if you are sure or not."
- Ray Hunt, in Think Harmony With Horses
ALU - SHRDLU - WORDNET - CYC - SWALE - AM - CD - J.M. - K.S. | CAA - BCHA - AQHA - APHA - R.H. - T.D. | 395 - SPS - GORDIE - SCMA - R.M. - G.R. - V.C. - C.F.

This topic is closed to new replies.

Advertisement