Quote: NPC: Hi You: kthxbai or You: Hello *NPC: K... or *NPC: blah blah blah *Depending on your first choiceMuch like KOTOR. This can get very complex, especially with big conversations, with everything ive tried. So i need a simple format for storing this. Any ideas?
NPC Interaction
Author
Hi,
I need to store player to npc conversations (with multiple possibilities) in a text file. So a conversation like this:
You could probably do something like an assembly-style format:
In this instance, the parser would just scan 'choice' tokens to produce a list of choices at each stage in the conversation, and jump to a particular label as needed.
This might be too complicated for your needs, or you may want something more complicated, in which case you might want to just go for a "full" scripting language like Lua or Python.
start: player.write "Hi there, Steve" npc.write "Hello world" choice "You are a horrible bigot, Steve. I hate you." bigot_conversation choice "I find pie extremely delicious, don't you?" pie_conversation choice "Sorry, I thought I wanted to talk to you." byebigot_conversation: npc.write "I am not a bigot :(" npc.opinionOfYou.decrease choice "<continue>" byepie_conversation: npc.write "Sorry, I'm allergic to pie." choice "<continue>" byebye: npc.write "Bye bye"This might be too complicated for your needs, or you may want something more complicated, in which case you might want to just go for a "full" scripting language like Lua or Python.
Quote:Original post by Butterman
Hi,
I need to store player to npc conversations (with multiple possibilities) in a text file. So a conversation like this:Quote:
NPC: Hi
You: kthxbai
or
You: Hello
*NPC: K...
or
*NPC: blah blah blah
*Depending on your first choice
Much like KOTOR.
This can get very complex, especially with big conversations, with everything ive tried. So i need a simple format for storing this.
Any ideas?
Finite state machine (http://en.wikipedia.org/wiki/Finite_state_machine)
The player NPC interaction is a FSM (there is a fixed number of interaction paths and fixed number of states).
States are possible fixtures at which you arrive. Connections between states are where you take actions.
All transitions can be easily expressed in a table, including invalid transitions, and as such can be easily persisted.
Clear design also allows you to always have good grasp of which transitions are possible and which not ("Hello" cannot bring you into end of conversation, unless you choose "not interested...").
In addition, if you give the player fixed choices, ("Yes", "No", "Bye") then you can hard-code the table.
If not (player can type anything in), then you parse the input, and choose next FSM state and action based on the string they entered. Once again, you have a guarantee that you won't steer off course in conversation - you have always good control over how the conversation proceeds.
Quote:
Wow. The finite state machine is looking abit complicated methinks.
Actually, what ravuya suggested basically is a finite state machine, just expressed a bit differently. Just think of each "conversation" section as being a state.
FSMs can range from extremely simple to extremely complex.
The simplest ones are something like this: (pseudocode)
say "What's the magic word?"
get response
if(response equals "please")
say "Thank you"
else
say "Bad manners alert!"
On the other hand, some FSMs (e.g. America's Army AI players) have somewhere around fifty states with hundreds of paths between them. You need to decide how many possibilities you need.
The simplest ones are something like this: (pseudocode)
say "What's the magic word?"
get response
if(response equals "please")
say "Thank you"
else
say "Bad manners alert!"
On the other hand, some FSMs (e.g. America's Army AI players) have somewhere around fifty states with hundreds of paths between them. You need to decide how many possibilities you need.
Author
Alrite ive worked up a format. Its a simpler version of what Ravuya had.
Its complex to look at. The first label is the identifier.
r Is an npc reply
c Is a choice
l Is a label
Im going to parse it by breaking up each line into 2 parts. The part up to the first " and then everything after. So
cbut "I dont belive you!"
Is identified as a choice. And then when its time to move on it goes to the 'but' label.
So is that alrite? Or am i getting the wrong end of this?
Quote:
lstart:
r "I am cornholio!"
cbut "I dont belive you!"
cok "ZOMG WTF BBQ"
lbut:
r "But i realy am!"
c "KTHXBAI"
e
lok:
r "Ok then..."
c "Bye bye now"
e
Its complex to look at. The first label is the identifier.
r Is an npc reply
c Is a choice
l Is a label
Im going to parse it by breaking up each line into 2 parts. The part up to the first " and then everything after. So
cbut "I dont belive you!"
Is identified as a choice. And then when its time to move on it goes to the 'but' label.
So is that alrite? Or am i getting the wrong end of this?
You might want to use XML. For one, it's clearer, and also, while it may be a bit of work in the start, you'll end up having a much more flexible system than if you wrote a parser yourself.
It might look like overkill at the start, but once you get it up and running, it would be very easy to add things like the setting of triggers and such if you've chosen a particular path of conversation. Also, it is very human readable.
For triggers and such, you can simply add another attribute to every PlayerChoice element like 'set_trigger="global_trigger_npc_01" ' or something like that. It also makes it easier if you're going for the type of game where a player can lose stats by talking to the npc in a certain way: 'reduce_player_attribute="niceness 100" '. Or you could even add it in as another element inside the PlayerChoice element.
XML is very good to work with once you've got it up and running.
For a game demo that I made, I was using XML as the format for the levels and the ship definitions. I was able to create an editor in C# (I was using C++ for the demo), in 2 days that completely edited and saved in the XML format. It was very easy and made the rest of my work much, much easier.
<NPC_Conversation> <ConversationSection name="start"> <NPCTalk text="I am cornholio!"> <PlayerChoice choice="but">I don't believe you"</PlayerChoice> <PlayerChoice choice="ok">ZOMG WTF BBQ</PlayerChoice> </NPCTalk> </ConversationSection> <ConversationSection name="but"> <NPCTalk text="But i realy am!"> <PlayerChoice choice="end">KTHXBAI</PlayerChoice> </NPCTalk> </ConversationSection> <ConversationSection name="ok"> <NPCTalk text="Ok then..."> <PlayerChoice choice="end">Bye bye now</PlayerChoice> </NPCTalk> </ConversationSection></NPC_Conversation>It might look like overkill at the start, but once you get it up and running, it would be very easy to add things like the setting of triggers and such if you've chosen a particular path of conversation. Also, it is very human readable.
For triggers and such, you can simply add another attribute to every PlayerChoice element like 'set_trigger="global_trigger_npc_01" ' or something like that. It also makes it easier if you're going for the type of game where a player can lose stats by talking to the npc in a certain way: 'reduce_player_attribute="niceness 100" '. Or you could even add it in as another element inside the PlayerChoice element.
XML is very good to work with once you've got it up and running.
For a game demo that I made, I was using XML as the format for the levels and the ship definitions. I was able to create an editor in C# (I was using C++ for the demo), in 2 days that completely edited and saved in the XML format. It was very easy and made the rest of my work much, much easier.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
