great to be back on topic =)

some quickie-like replies:

Quote:

Original post by superpig Quote: thus being a turnoff for the audience stated in the prologue. Those audiences aren't mutually exclusive...

And they're not the same either. So by forcing genre you will appeal to the intersection of both groups of people, not the union. You should do well to check out the latest Total War demo (Rome), they got this point right. It's a turn-based strategy with real time combat, and you can turn either off if you don't like them. Also about morale, i meant that a single value *like* morale in TW does it. In this case it would be trust. However if more than just obey-or-not is to be modeled, then yeah, it would be nice.

Quote:

Original post by superpig OK. I was just a little concerned that the discussion seems to be headed towards developing a game which is purely based around drama and dynamic narrative, which I think would compromise the real goal; we don't want to develop a new genre of 'dramatic' games, we want to make all existing genres more dramatic.

I do, for my own reasons =) anyways the action bit is already tried and true. I'll keep an open perspective for this thread.

Quote:

Original post by Oluseyi I honestly think it's a little early to talk implementation. I like to really turn an idea around in my mind, ...

I wrote things down but not code. Just tried to put the ideas in order so i could find holes in the scheme, and bits that were undefined. Tis just the way i do things =)

Quote:

Original post by OluseyiThe available fundamental interactions would have to be specified by the designer/writer (Mary kisses Jay relies on the fundamental action "to kiss" [romantic]), and each one would have an associated intrinsic morality or response value. If two people who are not otherwise attached kiss_romantic, then the evaluation shifts to an investigation of who the involved parties are and the "morality" of the observer/respondent. This way, some characters could be offended at homosexual kisses while others would be happy that "Steve finally found someone." Similarly, Elaine might be scandalized that Mary kissed Jay, but Carol might be all for it.

mmh yes, it's along the lines of what i thought... but the question was about this investigation, and how it would go. BTW reading this post i came up with an idea to make concepts more generic and let the NPCs have different opinions on them: a new basic data, categories.

Each NPC would suscribe to a category, and i guess there should be a default category that all NPC's and manipulable objects should suscribe to. Then, concepts could link to categories instead of (or in addition to?) NPC's.

So you could have Jane and Elaine in the category 'female' and Jay in the category 'male', and have Carol feel that <pass_kiss,female,male> is ok, but <pass_kiss,female,female> is not (or hot!). Also, these could be counted and NPCs could have a feeling about the count too, so if they see another NPC linked to pass_kiss more than one time, they'd feel bad about it. I havent thought about the count much tho.

Quote:

Original post by superpigmore abstract things, like God, or violence, or betrayal. Joe has an opinion on all of these things, a set of feelings

here, for example, we'd create the concept <violence,default,default> and make some NPC feel bad about it. Categories should probably be hierarchical though.... ugh headache.

Quote:

Original post by superpigand infers that my opinion of Jane NPC is highly positive; so is his, so we'd get on great (Hilarity, polygamy, and threesomes ensue)

thas is pure genius =D however it is solvable. the NPCs would have their opinions on poligamy (counters!) and cheating, so they would moderate themselves. Unless they were designed liberal... or you would talk em up, which im sure many many players will attempt.

Quote:

Original post by superpigThere are other similar problems that result from only having a single number representing an opinion.

Yes, im having three. They're quite neat and orthogonal IMHO.

Quote:

Original post by superpigAlso central is the idea of the 'incident.' When I'm french-kissing Jane NPC, a new, temporary concept is created in the graph, representing that action. Joe can thus form an opinion on that action, can remember it, can change his feelings on it later

i called this knowledge, or info. A concept linked to NPCs, and your opinion is formed based on the categories these NPCs suscribe to. This is what gossip consists of. I am somewhat aganist the idea of creating a new concept. mainly because NPCs wouldn't know how to deal with it. I propose that every possible action in the game has to be already added to the list of concepts in the game, so that NPCs can pick it up and hold an instance of it, linking the incident's details.
On the other hand, it could be good for horror games. If an NPC sees something that its not listed anywhere, he reacts by waving his arms around and running in circles screaming! which would be rather fun. heh. really, there's the issue of how to react to it.

For a recap, so far in my view:
-NPCs, anchor and free. Their personality is defined by mood and feelings about generic concepts and about specific events they know about.
-objects: stuff. pocket lint, definitely.
-Categories: NPCs and objects suscribe to these. They don't need an intrinsical meaning.
-Concepts: represent things that NPCs can think about. (NPCs are concepts too!) They should have category slots. Every possible action in the game should have an associated concept.
-Event: instance of a concept, with category slots filled by NPCs / objects.


how does the concept count fit in there (or if its needed at all) im not sure of yet. Also i realised that allegiances/trust is already included in the 3-number scale i plan to use, so i didn't write it up there.
Note: all feelings should be constantly updated. Hopefully the calculation will be simple, but then again this doesnt mean 60 times per second, could be once each 5 seconds or so.

Quote:

Original post by Madster great to be back on topic =)

[grin]

Quote:

And they're not the same either. So by forcing genre you will appeal to the intersection of both groups of people, not the union.

True enough.

Quote:

Also about morale, i meant that a single value *like* morale in TW does it. In this case it would be trust. However if more than just obey-or-not is to be modeled, then yeah, it would be nice.

Yeah, I never meant for it to control actions so cleanly - that's never how things work in real life. Rather, it would affect how your orders are interpreted.

Quote:

So you could have Jane and Elaine in the category 'female' and Jay in the category 'male', and have Carol feel that <pass_kiss,female,male> is ok, but <pass_kiss,female,female> is not (or hot!). Also, these could be counted and NPCs could have a feeling about the count too, so if they see another NPC linked to pass_kiss more than one time, they'd feel bad about it. I havent thought about the count much tho.

I like that idea, but I think it should be renamed a little - what we're really talking about here is 'properties.' You do end up with a very nice rule-based system - each NPC attempts to match an event against their existing rules (and the rules could get a lot more interesting if you work some boolean logic in there), allowing a component of the rule to either match an object directly, or one of the properties of that object.

Quote:

here, for example, we'd create the concept <violence,default,default> and make some NPC feel bad about it. Categories should probably be hierarchical though.... ugh headache.

Well, I don't think hierarchical categories are necessary... though you might have fixed property-property relationships (istypeof being the main one that springs to mind). If you specify a rule to match 'fruit,' and the object that is passed in doesn't have the fruit property, but *does* have the apple property, and apple has an istypeof relationship with fruit, then it passes.

Quote:

Quote: Original post by superpigand infers that my opinion of Jane NPC is highly positive; so is his, so we'd get on great (Hilarity, polygamy, and threesomes ensue) thas is pure genius =D however it is solvable. the NPCs would have their opinions on poligamy (counters!) and cheating, so they would moderate themselves. Unless they were designed liberal... or you would talk em up, which im sure many many players will attempt.

Yeah, but the problem is: how does John NPC know that it's polygamy? That it's cheating? I agree that 'polygamy' and 'cheating' would *definitely* be concepts in the concept network - if an NPC's going to have an opinion on it, it needs to be there - but without anything to differentiate sexual relationships from respect and reverence, John NPC won't know if my relationship with Jane is, um, platonic or not [smile] As far as a single-float system is concerned, there's no such thing as a platonic relationship.

Quote:

Quote: Original post by superpigThere are other similar problems that result from only having a single number representing an opinion. Yes, im having three. They're quite neat and orthogonal IMHO.

What do your three represent, if I may ask? Interestingly it means you can represent an opinion as a vector in 3D-space; you can see how 'different' two opinions are by calculating the angle between them.

Quote:

i called this knowledge, or info. A concept linked to NPCs, and your opinion is formed based on the categories these NPCs suscribe to. This is what gossip consists of. I am somewhat aganist the idea of creating a new concept. mainly because NPCs wouldn't know how to deal with it. I propose that every possible action in the game has to be already added to the list of concepts in the game, so that NPCs can pick it up and hold an instance of it, linking the incident's details. On the other hand, it could be good for horror games. If an NPC sees something that its not listed anywhere, he reacts by waving his arms around and running in circles screaming! which would be rather fun. heh. really, there's the issue of how to react to it.

Heh. I don't think the list needs to be predetermined and fixed at all - indeed, I think we should avoid that at all costs, because that means that NPCs can't improvise, and we want them to be able to improvise as much as possible to keep up the illusion and provide emergent gameplay. That's why I think we need a new concept - because our NPCs are going to need to figure out what they feel about an event, and they're going to need a concept to point those opinions at. If we start attaching properties (or categories, if you wish) to events, then the rules can stop looking for specific events, and only consider events by category. I get the feeling you'd already thought of that from your naming convention - pass_kiss suggests the presence of other actions like pass_hug and pass_cop_a_feel. If those were events - kiss, hug, cop_a_feel - with the 'pass' property, then you can catch all types of pass in a single rule, instead of duplicating the same rule for similar actions.

Quote:

Note: all feelings should be constantly updated. Hopefully the calculation will be simple, but then again this doesnt mean 60 times per second, could be once each 5 seconds or so.

I agree - or at least, I think that NPCs should only update their feelings in response to events that they have witnessed (or possibly due to events that have occured 'inside' of them, like mental decisions - a 'thought process'); I would expect the number of events being kicked around to be sufficiently high that your high update rate would be achieved. (A sensible implementation probably wouldn't try and update everyone, every frame - it'd do a bunch this frame, then a bunch the next frame, etc).

Quote:

Original post by superpig I never said direct consequences. The problem I have with the word 'penalty' is that it's exclusively negative. You talked about penalties as being "how the system responds to a user's choices in terms of how to solve a certain problem" - that response could equally be positive (e.g. the player is rewarded for successfully resolving the problem without spending any money, or without killing any people). But we're getting into semantics and away from the point.

While the last part is true, you're absolutely right. Scratch "penalties" and replace with "consequences."

Quote:

An idea I've thrown around before is a very simple graph of concepts and opinions.

I like this "concept graph" idea. My previous knowledge representation ideas used a graph for inter-character relationships, but placed all "knowledge/concepts" into a flat repository. By placing everything in a single graph, we gain robustness and a single consistent method for both modeling and appraising the binary, asymmetric relationship between any two entities.

You correctly point out one complexity, though: "positive" is relative. Joe may things Jane is sexy, but Richard kissing Jane might incite jealousy in Joe. (On the other hand, Jane might find Richard kissing Joe a strange turn on!) Clearly we need a model where the links/edges (relationships) between the nodes/vertices (entities, characters, concepts) in our concept graph are not simple floating-point values of inclination, but rather aggregations of several fundamental impulses. Arriving at a detailed yet compact enough definition will be a worthy challenge.


I'm still thinking about "incidents," though.

Quote:

Original post by superpig I like that idea, but I think it should be renamed a little - what we're really talking about here is 'properties.' You do end up with a very nice rule-based system - each NPC attempts to match an event against their existing rules (and the rules could get a lot more interesting if you work some boolean logic in there), allowing a component of the rule to either match an object directly, or one of the properties of that object.

Agreed, they should be called properties. I didn't quite understand that boolean logic idea, nor the idea behind matching properties to another property... (unless its for the hierarchy thing talked ahead in this post)

Quote:

Well, I don't think hierarchical categories are necessary... though you might have fixed property-property relationships (istypeof being the main one that springs to mind).

istypeof is another form of defining hierarchy =) so i guess it has to be there in one way or another. Single parent hierarchy, of course. The istypeof rule is a neat way of making it though, we'd have em on a separate list for speed and if a match is not found directly, traverse the list from the beginning and try with the parent until no more parents are found.

Quote:

Yeah, but the problem is: how does John NPC know that it's polygamy? That it's cheating? I agree that 'polygamy' and 'cheating' would *definitely* be concepts in the concept network - if an NPC's going to have an opinion on it, it needs to be there - but without anything to differentiate sexual relationships from respect and reverence, John NPC won't know if my relationship with Jane is, um, platonic or not [smile] As far as a single-float system is concerned, there's no such thing as a platonic relationship.

for polygamy i considered counting. John would see that ...um.. whoever is already linked to the kissing event, and he feels that being linked more than once to such event is bad. does that make sense? as for single-float, keep reading.

Quote:

What do your three represent, if I may ask? Interestingly it means you can represent an opinion as a vector in 3D-space; you can see how 'different' two opinions are by calculating the angle between them.

I'm not so sure about the angle, but here's the reference
http://www.kaaj.com/psych/scales/emotion.html
I found this linked from gamasutra i believe, some years ago. Saved the html in case it poofed, but it didn't.
discard 'hungry' from the text.... hunger is not a feeling.

Quote:

That's why I think we need a new concept - because our NPCs are going to need to figure out what they feel about an event, and they're going to need a concept to point those opinions at. If we start attaching properties (or categories, if you wish) to events, then the rules can stop looking for specific events, and only consider events by category. I get the feeling you'd already thought of that from your naming convention - pass_kiss suggests the presence of other actions like pass_hug and pass_cop_a_feel. If those were events - kiss, hug, cop_a_feel - with the 'pass' property, then you can catch all types of pass in a single rule, instead of duplicating the same rule for similar actions.

Actually pass_kiss was short for passionate_kiss! =D i don't like parsing token strings too much... could slow things down.
As for events, they're the first argument of rules, and not fit for categories since you could do strange things like create an event <man,child,man> which doesn't make any sense. An event must be there in some sort, even if it is categories of events (or properties of events, a different list than properties of game objects/NPCs). Also, if you were to use event properties, you'd have to figure out what properties a newly created event has, which is kind of like knowing all possible events beforehand. the only plus you'd get is an unique identifier, which wouldn't be used.

Quote:

(or possibly due to events that have occured 'inside' of them, like mental decisions - a 'thought process')

*haves nightmares of pattern-matching algorithms* this would be nice but i can't think of any way to make it happen at this time.

Quote:

Original post by Madster Agreed, they should be called properties. I didn't quite understand that boolean logic idea, nor the idea behind matching properties to another property... (unless its for the hierarchy thing talked ahead in this post)

The basic idea goes like this.

You're defining each entry in your rule table as <predicate, subject, object>. That's probably going to need some expanding, because some actions involve more than two other entities, but no matter - what that represents is some definitive event within the world, that you attach a reaction to.

As such, when something happens in the game world, you can package it up just like a rule. If I were to kiss Jane NPC again (what can I say? we're good together), you could wrap that up as <kiss, superpig, jane_npc>.

Then you'd match that against each of your rules, one-by-one - matching performed by comparing the first elements, then the second elements, then the third elements. If they're the same, you execute the reaction. So, if you've got a <kiss, superpig, jane_npc> action in your table with the "Punch superpig" reaction, you'd find that match, execute the reaction, and I'd fall over.

If you're supposed to be going steady with Jane NPC, you probably want to employ the same reaction for all kiss events involving her and not you; that would require you to create a rule for each person who could possibly kiss her, which is senseless. Instead, you define a couple of keywords - 'any' and 'except', and 'me' as shorthand to refer to the entity the rule belongs to - and decree that all guys will have the 'man' property attached. This lets you rewrite your rule as <kiss, any man except me, jane_npc>. The expression 'any man except me' will match any object that (a) has the 'man' property, and (b) is not you. And lo, Jane's honour is protected, while still allowing her to be bi-curious.

Boolean logic is a simple extension of that - you don't want to punch Jane's aging father when he kisses her in greeting. So you might expand your rule to <kiss, any man except (me or father_of_jane_npc), jane_npc>. Similarly, you might want to punch Gina - a psycho ex-girlfriend of yours, who thus doesn't have the 'man' property - if she tries anything with Jane, so your rule could be <kiss, Gina or (any man except me), jane_npc>.

It's a bit programmatical, but it lets you build fairly complex rules using only a few keywords - and, or, not, any, except - to begin with, at least. It's worth looking into some of the interactive fiction development languages for this kind of thing - I picked up large chunks of this idea from a language called INFORM.

Quote:

istypeof is another form of defining hierarchy =)

True [smile] though I'm fairly sure there are other relationships between properties - hot could be isoppositeof cold, for example. istypeof is the only one I could come up with on the spot. isoppositeof - or perhaps, more neatly, 'excludes' (two properties with an 'excludes' relationship cannot be applied to the same object at the same time) would be another. I can't think of any more right now.

Quote:

for polygamy i considered counting. John would see that ...um.. whoever is already linked to the kissing event, and he feels that being linked more than once to such event is bad. does that make sense?

Yeah, but you appreciate that it's not extensible, right? It's something you'd have to special-case. It's so much nicer if we can get a general model that requires no special-casing...

Quote:

I'm not so sure about the angle, but here's the reference http://www.kaaj.com/psych/scales/emotion.html I found this linked from gamasutra i believe, some years ago. Saved the html in case it poofed, but it didn't. discard 'hungry' from the text.... hunger is not a feeling.

Innnnnteresting. It reminds me a bit of the model for personality, with the two-dimensional introvert-extrovert and something else I don't quite remember.

Quote:

Actually pass_kiss was short for passionate_kiss! =D i don't like parsing token strings too much... could slow things down.

Haha! Oh well, that's what I get for making assumptions [grin]

Quote:

As for events, they're the first argument of rules, and not fit for categories since you could do strange things like create an event <man,child,man> which doesn't make any sense.

I agree, it wouldn't make any sense - but just because you *could* create something nonsensical doesn't mean you *would* do. I think your rule system isn't a long-term solution anyway because, as I said, the NPC can only deal with what you've given it rules for. A better solution would be anything that the designer can shape roughly, but will fill in its own gaps when the player does something unexpected.

I propose a test of any such system, actually: I want to walk up to your NPC and slap him across the face with a large trout. He must be able to respond, without you hardcoding a "in the event that you are slapped across the face by a large trout..." rule into him. I should be able to do that to any NPC in your game, anywhere, at any time.

I think that represents the unexpected quite nicely, don't you? [grin]

Quote:

Also, if you were to use event properties, you'd have to figure out what properties a newly created event has, which is kind of like knowing all possible events beforehand.

Well, I agree in that you could generate every possible event in the game by combining every legal permutation of properties - but that's a bit pointless. Working out the properties to be applied to an event is something that the system would have to do, certainly; more interestingly, the properties that are applied to it may depend on who observes it. Different observers of an event come away with different stories of what happened. So then we're dealing with one concept per event per witness... but then the properties may change as the concept is passed from person to person... hmm. Difficult.

Quote:

The only plus you'd get is an unique identifier, which wouldn't be used.

Sure it would! People will form opinions of that event. If nobody's formed any opinions of the event - and nobody's going to - then it can be discarded. But one of the things we get for free is NPC memory. Every NPC can have an opinion on events they have participated in (and therefore witnessed) in the past. If an NPC does one action because their opinions lie a particular way (eg: they kill goblins because they hate goblins), and then those opinions change later on (eg: they're shown that goblins aren't bad, and stop hating them), then they may develop a bad opinion of their own past actions - allowing them to exhibit remorse.

Quote:

Quote: (or possibly due to events that have occured 'inside' of them, like mental decisions - a 'thought process') *haves nightmares of pattern-matching algorithms* this would be nice but i can't think of any way to make it happen at this time.

Well hey, it's like I said in Mephs' thread - it's not the job of the game designer to know what is and is not possible. I'm fairly sure that most of what we're talking about here isn't doable with current technology, but we can't begin working on new technology for it until we know exactly what that technology needs to be able to do. For me, this sort of thing is mostly just a thought exercise.

Compact narrative has a big impact on replayability. If you are too much in a tight constraints, you don't get too much new from playing again.

Other problem is try to force player into a behavior he would really like to avoid. I listened about girl that was really against playing dwarf with a beard. If you'd like to add a drama, you are more likely creating situations that player dislikes and can't avoid.

re wavinator.

Quote:

While we're waiting for the natural language processor and speech recognition barriers to be broken down

A natural language processor is no help. It doesn't add too much into playability of game, it "might" add some pleasure into playing of some very specific types of player, but thats all.
Speech recognition might be funny, but not something that would be too much neccessary. I can read much faster than I can listen to a speech. Also I'm against yelling on member of platoon to do a work. You know my neighbourds would call psychiatric clinic.

Chomsky said a language is actually learnable. It was a nice feat from linguistic to get some at least partial proof about that. So something like speech recognition/nlp might be reasonably effective, but I'm against it if it would add the same barrier to making games as was added by reasonably complex 3D models.

I seen a words "soap opera". I hope that crap will not come into game industry too soon. Soap operas, and reality shows are just a replacement for medieval public punishments. You know a big crowd on placa, looking on another funny decapitation, or commenting a hanging. Hardly fun, hardly something interesting. You seen one, you seen all.

(Days of ... are very important if you'd like to write screenplays for movies, when you will be out of inspiration, you know how to fill it until you get inspiration again.)

check it out, this thread has legs! (im rooting for page 3 already)

i'll tackle the first bits carefully because we seem to have a different idea of what the rules are for:

Quote:

Original post by superpigYou're defining each entry in your rule table as <predicate, subject, object>. That's probably going to need some expanding, because some actions involve more than two other entities, but no matter - what that represents is some definitive event within the world, that you attach a reaction to.

Yes. i forgot to mention it, the amount of object/NPC slots could be 1 to whatever the writer wants.

Quote:

As such, when something happens in the game world, you can package it up just like a rule. If I were to kiss Jane NPC again (what can I say? we're good together), you could wrap that up as <kiss, superpig, jane_npc>.

And i call that an Event.

Quote:

Then you'd match that against each of your rules, one-by-one - matching performed by comparing the first elements, then the second elements, then the third elements. If they're the same, you execute the reaction. So, if you've got a <kiss, superpig, jane_npc> action in your table with the "Punch superpig" reaction, you'd find that match, execute the reaction, and I'd fall over.

Ok here's the big difference. In my case, our NPC Jay would have PAD values attached to <kiss, male, female> and to <kiss, male, jane_npc> (i guess i should say that specific rules supercede generic ones...more later) and so he'd receive the effect of the attached PAD (a feeling). This would change his current mood depending on what it was before. Action should be decided on his new mood and his knowlegde. A way that of course, i havent outlined either.

Quote:

If you're supposed to be going steady with Jane NPC, you probably want to employ the same reaction for all kiss events involving her and not you; that would require you to create a rule for each person who could possibly kiss her, which is senseless.

Not really. you would match rule <kiss, jane_npc, superpig> and rule <kiss, jane_npc, male> but since the former is more specific, it should be applied. Important thing that, picked it up from CSS rules.

Quote:

Boolean logic is a simple extension of that - you don't want to punch Jane's aging father when he kisses her in greeting.

Ok thats rather challenging. Gimme a second. (smoke comes out of head)
Ok got it. simply, make it two kinds of kisses. =D (reason for pass_kiss!)
Or if you want mouth kissing within the family, you'd have a special Quick_mouth_kiss, then you tag jane and her family with family_doe and classify the latter as family. Then you go <Quick_mouth_kiss, dad, jane> matches <Quick_mouth_kiss, family, family>, but superpig is also member of family_sp so <Quick_mouth_kiss, family, family> matches too.... humm yeah it needs some relational logic. i'll start thinking about a way to make it simple. Again, i don't wanna be parsing token strings.

Quote:

though I'm fairly sure there are other relationships between properties - hot could be isoppositeof cold, for example. istypeof is the only one I could come up with on the spot. isoppositeof - or perhaps, more neatly, 'excludes' (two properties with an 'excludes' relationship cannot be applied to the same object at the same time) would be another. I can't think of any more right now.

Im almost sure that this duplicates the functionality of relational logic in the rules. hey what about SQL-query style rules? i'll read up on that.

Quote:

Yeah, but you appreciate that it's not extensible, right? It's something you'd have to special-case. It's so much nicer if we can get a general model that requires no special-casing...

Yes... i want to be able to count matches in any place of the hierarchy, maybe adding to the relational logic. And attach PAD to points and interpolate between them? hmmm... how much is too much for a given NPC? that'd be interesting. It's probably overkill, too. I'll let this one wait until we figure out proper relational logic for object/NPC slots in the rules.

Quote:

I think your rule system isn't a long-term solution anyway because, as I said, the NPC can only deal with what you've given it rules for. A better solution would be anything that the designer can shape roughly, but will fill in its own gaps when the player does something unexpected.

And recalling the difference, they're only told what to feel by the rules, thus behavior emerges anyway. So i believe it would work.

Quote:

I propose a test of any such system, actually: I want to walk up to your NPC and slap him across the face with a large trout. He must be able to respond, without you hardcoding a "in the event that you are slapped across the face by a large trout..." rule into him. I should be able to do that to any NPC in your game, anywhere, at any time. I think that represents the unexpected quite nicely, don't you? [grin]

I love counterexamples! however this one is misconstructed. It precludes me from using the system i'm supposed to test. Thus, i will ignore the bit of not hardcoding the event type. Also, that is not a representation, so no =/ that is just the objective.

My assumption is that the game is not controlled in an extreme free form way, and it's more the traditional way where you know what things can be done beforehand. Even in GTA.. can you kick people in the shin? nope. People can get fired upon or hit by a car, etc. It's all predefined. Free form would be... um.. i dunno, i havent seen anything like that.
So back on topic, you know beforehand all the possible actions. They can be a lot. so you have the action trout_slap, and you categorize it as mild_violence. Then you define the rule for all mild_violence. <mild_violence, people> = sad. <mild_violence, furniture> = mad?

and in GTA fashion, shooting, running over, burninating and generally maiming people would be categorised as extreme_violence and there would be <extreme_violence, NPC> = panic, <extreme_violence, NPC_joe>= anger, <extreme_violence> = fear. Being the joe rule more specific, it should supercede all others.

Quote:

Well, I agree in that you could generate every possible event in the game by combining every legal permutation of properties

there's only one concept in each event... so this couldn't be done, and i don't understand why would one want to.

Quote:

the properties that are applied to it may depend on who observes it.

you're right. Very interesting. Joe didn't know Jay was Carol's brother, so he passed around the story that she was seen hanging out with some guy at a club... people might react negatively to this knowledge, but they're being misinformed. In turn, if the information contains Jay, the other NPC might know Jay is her brother and don't think too much into it. So events should be able to be filled up with categories further down the hierarchy.

Quote:

Sure it would! People will form opinions of that event.

they already can.... each NPC has a list of the events in their knowledge and how they feel about them.

Quote:

it's not the job of the game designer to know what is and is not possible. I'm fairly sure that most of what we're talking about here isn't doable with current technology, but we can't begin working on new technology for it until we know exactly what that technology needs to be able to do. For me, this sort of thing is mostly just a thought exercise.

Well, i'm a coder too so i know mostly. Also i don't like pie-in-the-sky threads too much since i can do that by myself or with friends over here...and i believe it's doable with current technology, if you mean hardware. Thinks the Sims 2... i mean it's almost unbelievable but it's there today and works perfectly. Just gotta design minding implementation (otherwise it's pretty easy, NPCs should have knowledge, needs and desires which should change.. and there's an icon interface to conversations and actions that invoke said knowledges, needs and desires.)

SO, pending:
-relational logic for filling out NPC/object slots when instancing rules/ creating events
-rules with instance count as a parameter
-how to decide actions based on feelings (PAD state) and knowledge (NPCs, events and associated states).

i'll keep kicking the second and third one until i (or we) find something i like fir the first.
Tired
-Madster

Quote:

Original post by Madster check it out, this thread has legs! (im rooting for page 3 already)

Sorry, I'll try and split my huge posts up into smaller ones, Oluseyi-style, that should get us there faster.. [wink]

Quote:

i'll tackle the first bits carefully because we seem to have a different idea of what the rules are for: Quote: Original post by superpigYou're defining each entry in your rule table as <predicate, subject, object>. That's probably going to need some expanding, because some actions involve more than two other entities, but no matter - what that represents is some definitive event within the world, that you attach a reaction to. Yes. i forgot to mention it, the amount of object/NPC slots could be 1 to whatever the writer wants.

Yeah, that makes sense - presumably each action has a 'signature' as part of its definition, a legal number of object/NPC slots (I guess 'arguments').

Quote:

Quote: As such, when something happens in the game world, you can package it up just like a rule. If I were to kiss Jane NPC again (what can I say? we're good together), you could wrap that up as <kiss, superpig, jane_npc>. And i call that an Event.

Right, I'd call that an Incident - except I'd attach a bit more data to it (such as the time and place that it happened) and store it in the concept graph.

Quote:

Ok here's the big difference. In my case, our NPC Jay would have PAD values attached to <kiss, male, female> and to <kiss, male, jane_npc> (i guess i should say that specific rules supercede generic ones...more later) and so he'd receive the effect of the attached PAD (a feeling). This would change his current mood depending on what it was before. Action should be decided on his new mood and his knowlegde. A way that of course, i havent outlined either.

I'd consider that to be part of the 'reaction' associated with the rule (simply put, "feel angry"). All I was getting at was the system for matching rules (and specific rules superceding generic ones is nice and simple, but which rule would take precedence out of <kiss, joe_npc, female> and <kiss, male, jane_npc>?) - I fully agree that in a rule-based system, you will want to include adjustments to the NPC's PAD values as part of the response to an event.

Quote:

Quote: If you're supposed to be going steady with Jane NPC, you probably want to employ the same reaction for all kiss events involving her and not you; that would require you to create a rule for each person who could possibly kiss her, which is senseless. Not really. you would match rule <kiss, jane_npc, superpig> and rule <kiss, jane_npc, male> but since the former is more specific, it should be applied. Important thing that, picked it up from CSS rules.

If you've got the second rule then the former isn't necessary at all (cos I'm a guy). The thing I think I hadn't realised was that your system had any concept of 'specific' at all - I got the impression that that all your rules referred to specific objects, but that's clearly not the case. We're pushing for the same thing, I think - in your system, you'd need some way of knowing whether or not 'male' is a suitable match for me - all I'm proposing that you could discover that by checking a list of properties attached to me to see if 'male' is in the list.

Quote:

Quote: though I'm fairly sure there are other relationships between properties - hot could be isoppositeof cold, for example. istypeof is the only one I could come up with on the spot. isoppositeof - or perhaps, more neatly, 'excludes' (two properties with an 'excludes' relationship cannot be applied to the same object at the same time) would be another. I can't think of any more right now. Im almost sure that this duplicates the functionality of relational logic in the rules. hey what about SQL-query style rules? i'll read up on that.

I still reckon that reading up on Inform would be a better use of your time because it's a language designed to deal with objects and relationships. I guess you might use an SQL type language to query a list of rules to find matching ones, but actual event/rule comparisons... not convinced.

Quote:

Quote: I think your rule system isn't a long-term solution anyway because, as I said, the NPC can only deal with what you've given it rules for. A better solution would be anything that the designer can shape roughly, but will fill in its own gaps when the player does something unexpected. And recalling the difference, they're only told what to feel by the rules, thus behavior emerges anyway. So i believe it would work.

Surely it must be possible that an event could arise that matches no rules on an NPC's list? Unless you put a catch-all rule in there - which reminds me of the kludgy 'I don't know how to do that' responses in text adventures - the NPC could be left in a situation that his rulebook does not tell him how to deal with?

Quote:

I love counterexamples! however this one is misconstructed. It precludes me from using the system i'm supposed to test. Thus, i will ignore the bit of not hardcoding the event type.

Well, OK, so maybe that was a bit unfair of me [smile]

Quote:

Also, that is not a representation, so no =/ that is just the objective. My assumption is that the game is not controlled in an extreme free form way, and it's more the traditional way where you know what things can be done beforehand. Even in GTA.. can you kick people in the shin? nope. People can get fired upon or hit by a car, etc. It's all predefined. Free form would be... um.. i dunno, i havent seen anything like that.

Ahhh.

I think that's the real point that you and I differ on. I'm not prepared to make that assumption. If we're talking about cutting down restrictions on the interface - speech recognition, motion sensing and machine vision, virtual reality gloves, and so on - the player's freedom to interact with the world increases greatly. Even a simple control interface - something like The Sims - allows the player to execute a vast number of actions with ease. The total set of possible player actions remains finite, and always will do, but as the size of the set increases it becomes harder and harder to provide rules for every situation. That's why I'm so keen to find a solution that doesn't care about the full set of possibilities - you just give it some control points and it fills in the rest. (I keep thinking that neural networks should have something to do with this...)

Quote:

you're right. Very interesting. Joe didn't know Jay was Carol's brother, so he passed around the story that she was seen hanging out with some guy at a club... people might react negatively to this knowledge, but they're being misinformed. In turn, if the information contains Jay, the other NPC might know Jay is her brother and don't think too much into it. So events should be able to be filled up with categories further down the hierarchy.

Yes, right - except that those categories wouldn't necessarily be shared by all other witnesses of the event (Joe would view the event one way, while Jay would view it another way). As such I think we'd either have to deal with copies of the event, or with 'filters' - specific properties/categories that are added to an event when it is considered from the point of view of a particular person.

Quote:

Quote: People will form opinions of that event. they already can.... each NPC has a list of the events in their knowledge and how they feel about them.

Which is the same as concepts! Each NPC would have a list of concepts that it has an opinion on, and an opinion for each. Why not unify the two lists?

Quote:

Well, i'm a coder too so i know mostly.

So am I, but I try to ignore that when I'm wearing my designer hat for any major length of time. (The time it has taken me to type out this post qualifies for that).

Quote:

Also i don't like pie-in-the-sky threads too much since i can do that by myself or with friends over here...

Well, as far as I'm concerned, you guys are my 'friends over here.' [smile] I don't think any of this is pie-in-the-sky, though, because we're talking about a logical model - and I'm fairly convinced than any logical model can be represented programmatically.

HAPPY NEW YEAR!!! may GameDev spawn a billion homebrew and commercial games!

Quote:

Right, I'd call that an Incident - except I'd attach a bit more data to it (such as the time and place that it happened) and store it in the concept graph.

yeah, location is a good idea. All relevant circumstances should be attached. Any more we've missed? (I'd store em in each NPC's knowledge lists)

Quote:

I fully agree that in a rule-based system, you will want to include adjustments to the NPC's PAD values as part of the response to an event.

Also, not attaching response actions to the rules will give you emergent behavior. For example, you can talk up NPCs to, say, prevent them from snapping when you drop the bomb on them. If the action is attached to the rule, then there's no helping that.

Quote:

all I'm proposing that you could discover that by checking a list of properties attached to me to see if 'male' is in the list.

yeah, thats what properties/categories are for. Of course, every NPC should know you belong to category male as soon as they meet you.... so maybe some categories should be tagged as obvious for this effect?

Quote:

I still reckon that reading up on Inform would be a better use of your time because it's a language designed to deal with objects and relationships. I guess you might use an SQL type language to query a list of rules to find matching ones, but actual event/rule comparisons... not convinced.

I'll check out Inform. I doubt a query language would be a good idea, but I meant to read on SQL mainly for inspiration, maybe pick up one concept or two from there.

Quote:

Surely it must be possible that an event could arise that matches no rules on an NPC's list? Unless you put a catch-all rule in there - which reminds me of the kludgy 'I don't know how to do that' responses in text adventures - the NPC could be left in a situation that his rulebook does not tell him how to deal with?

you're right, i was thinking it wasn't so hard to make at least one rule per concept, but that isn't enough. So a default rule could be 'don't care' PAD=0,0,0 [grin]

Quote:

If we're talking about cutting down restrictions on the interface - speech recognition, motion sensing and machine vision, virtual reality gloves, and so on - the player's freedom to interact with the world increases greatly.

AAaah... well i wasn't the one who brought that up... I'd like to do something like this one day, so i was considering a mouse driven interfase. With context icons. Or something.

Quote:

(I keep thinking that neural networks should have something to do with this...)

The problem would have to be laid out and analysed.

Quote:

As such I think we'd either have to deal with copies of the event, or with 'filters'

I was thinking each NPC should create its own copy of the event as they perceived them, and then this is the info they pass along when they gossip.

Quote:

Quote: they already can.... each NPC has a list of the events in their knowledge and how they feel about them. Which is the same as concepts! Each NPC would have a list of concepts that it has an opinion on, and an opinion for each. Why not unify the two lists?

Hm let me see:

Global:
-concept lists: to pick concepts when something happens, and stuff em in event knowledge.

per NPC:
-rule list: says how to file the event.
-event list: represents NPC knowledge and its feelings towards them.
-NPCs list: known NPCs and their known properties and feelings towards them.
-state: current mood

so, the difference between the concept list and the event lists is that the event list has NPC and location links. Also, concepts themselves have no attached opinion, but rules do. This is because the way one feels for a concept depends on the circumstances.

Quote:

Well, as far as I'm concerned, you guys are my 'friends over here.' [smile] I don't think any of this is pie-in-the-sky, though, because we're talking about a logical model - and I'm fairly convinced than any logical model can be represented programmatically.

heh oops.. i meant over here as in the people that come for tea and such. =)
and yea so far it isnt pie-in-the-sky, and i'd love if it stays that way.
The interfase to this doesn't matter right now, but i'm confident it can be done without the need for extra hardware. hell, an icon could be attached per concept and per NPC and we're halfways there [smile]
if someone shows me a kiss icon and portraits of two people, i don't need it spelled out, and thats just reading the event out loud with icons.

Which reminds me of something i forgot to bring up before: rules and their matching should be order-independent, so that <kiss,male,female> is matched the same times that <kiss,female,male> is. besides being more hard to miss rule matches that way, it also gives way to complex multi-rule matches. I know i said before the most specific match should supercede, but what if there is more than one match, and they are all just as specific? I believe now they should be added (or averaged or blended with some other rule like maximum). Does this sound good?

On post length... yea [smile] i'll try too

edit - untouched topics for later (so i don't forget [grin]:
-deceits: how do they find out? what do they do about it?
-knowledge barter: requesting knowledge in excange for other, modeling what other NPCs know (this is the meat of most soapie plots)

bumpeth thy threadeth.
Sorry, will add something useful soon. Meanwhile, don't die little thread!