Sign in to follow this  
thebigbossman

NPC interaction and dialogue codes in an RPG/adventure game

Recommended Posts

I'm trying to solve the problem of how to store the character dialogue and NPC interactions within my game. I already have a basic idea, but I would like to know what file format is best suited for storing a tree of dialgoues.

XML is powerful, but too clunky and cluttered with tags. Is there any other file format that I can conveniently use within Python to store dialogues data?

Any other format for data storage will be appreciated. If XML is the only choice, then what would be the ideal schema?

Share this post


Link to post
Share on other sites
XML isn't your only choice. Plus, often what you want (at least to start with) is a file that's easy to update and maintain. The code to read your data into the game is only going to be written once, but you (most probably) are going to spend a lot of time adding new content to your file. So pick something manageable - you can always write a translator to your 'distributable' format.

As a random example, you might have an SQL database, complete with some forms for creating new NPCs, new NPC dialogue, character dialogue, quests, items. Your DB application might allow you to visually see that Quest #1453 becomes available when [i]either[/i] event X or event Y occurs. You want this side of things to be easy to work with, both for yourself and in case you farm it off to a level designer.

And then, when you distribute your game, you'll export from your content creation tool to the final distributable. You might:
- want that data in a format you can load and display fast, or
- want it in a format you can patch easily, or
- want enthusiasts to be able to tweak the game
which might, in turn, give you 3 different file format choices. You might choose to distribute a binary file, a standalone SQLLite file, XML or something else entirely.

Part of the trick in whatever solution you choose is that your character dialogue (etc) is going to be context dependent. So what character N says now will be different to what he says when his state has been modified by game events. Having a solution that allows you to look that data up quickly and easily will make life easier later. Perhaps in XML you'd have a series of <state>s under your <character>, and beneath each <state> you'd have the list of dialogue choices at that point in time - together with whatever metadata the game needs to process that information. But since it's entirely dependent on how your game is structured I think it's really a structural question only you can answer :)

Share this post


Link to post
Share on other sites
SQLite seems a great solution actually.

Thanks for the hints.

Right now, since I've not thought so far ahead, I think I'll use XML for every single actual dialogue and use the game code to choose the dialogue file to load at runtime depending on the context (game state variables etc.).

this means, I probably create a set of dialogues for each character as:
[code]
NPC 1:
\
\ ---------dialogue1.dlg
\----------dialogue2.dlg
\----------dialogue3.dlg
NPC 2
\---------- dialogue1.dlg
\---------- dialogue2.dlg
[/code]

and so on. And use in-game code to load the appropriate dialogue file.

Later on I think I could use the SQL database approach to store the whole thing in a single DB and change the code to initialize the conversations from the database, rather than files.

Share this post


Link to post
Share on other sites
If XML is too clunky for you, you could try JSON, it has a lot less overhead and achieves the same (plus I think python more or less supports it out of the box). Personally I find it horrible, but it does have its merits and a lot of people swear by it.

Also, you can consider using [b]two [/b]formats, no matter what you settle on (that's what I do). Write your stuff in a human-readable form, and run it through a parser at build time which translates it to whatever binary format you want (could even just insert values into SQLite, or just dump the binary contents of an array or a container to disk, whatever).

Thing is, game data [i]does not need [/i]to be human-readable (and often in fact [i]should not be[/i]), and with a non-human-readable format you save the trouble of parsing at runtime. Insofar, it does not make much sense to ship data in a human-readable format. On the other hand, it is a million times easier for you to produce the content in a human readable format such as XML.

Share this post


Link to post
Share on other sites
Thanks. As far as Python is concerned, there is no "build" stage, since the whole code is interpreted.

However, as far as human readable is concerned, I am not sure many people will agree with that XML is "human-readable" but that's another story. :wink:

JSON sounds like a great idea. Thanks again. I feel it looks better than XML, but of course, that is a subjective issue.

Share this post


Link to post
Share on other sites
There is normally still a "build stage" even though Python is of course an interpreted language. You don't normally edit all the content in the final directory that you ship, and you don't normally ship a folder with a thousand files.

Normally you have your sources in some checkout directory (under version control... subversion, git, mercurial, whatever, take your pick), and you have your artwork in some location (as in e.g. Photoshop files with layers and everything, plus a composited version of each final version in a commonly used lossless format, such as for example TIFF).

The "build process" would be copying the python files plus any needed runtime distributables (whatever it takes to run your code) into the destination folder (without any metafiles added by version control), running all the artwork through the DXT compressor, building mipmaps, maybe reading in some Collada files for models and outputting them in a format, whatever. Then copying all data files to where your scripts will expect them, etc.

And finally, make an installer package (like NSIS or whatever).

Share this post


Link to post
Share on other sites
Thanks for the explanation. I actually haven't got so far, yet. Still in the development phase and not sure how I'll be packaging up the game, so the whole thing is still at the source level. When I actually start getting a working game with some playable game data I'll think of how to implement it.

Share this post


Link to post
Share on other sites
i used a simple text file which i parse out at runtime

it looks like this


[
[ Hey how are you ] ,_ this will get displayed

inputDialog 2 // this will display a dialog choicer, 2 3 4 options

input1
go on from here

input2
go on from here

i also included IF statements etc to check for conditions..

runs pretty good right now, so a full scripted char event looks like this:
[code]

IF Switch 1 1
Piss off ]
... ]
... ]
... ]
inputDialog 2
...do you feel sorry?#
1. Yes#
2. No ]

input1
Ok, we are good again ]
changeSwitch 1 0
END_OF_DIALOG

input2
inputDialog 2
Why not?#
1. I dont think i feel you#
2. Come on piss of ]

input1
Well, than i cant change it. ]
END_OF_DIALOG

input2
I hate you ]
playAni 3
END_OF_DIALOG

ENDIF

IF Switch 1 0
Thomas:#This life is a pain..... ]
Why cant we just die? ]
Sometimes... #
sometimes... #
I..... ]
inputDialog 3
...Are you happy?#
1. Most of the time#
2. Never#
3. What a stupid question ]

input1
Thomas:#
Lucky bastard..#
We are rotten here ]
END_OF_DIALOG

input2
Thomas:#
I feel you, here .. #
take this... ]
END_OF_DIALOG

input3
Thomas: #
Fuck you ]
playAni 3
changeSwitch 1 1
END_OF_DIALOG
ENDIF
END_OF_DIALOG

[/code]

my goal is to write an editor later which makes it pretty use to use it...

Share this post


Link to post
Share on other sites
Just one advice... try always to code with look in the future.. most of the time you will want to add features etc and than u are caught in some inefficient system. Better think now how high the possibility is that u will use logic and leave this door open for you.

just a hint :0)

Share this post


Link to post
Share on other sites
FWIW, the Python community generally considers JSON to be reasonable (and there is support built right into the standard library) and fairly Pythonic (it looks quite similar to the code you would use to create an equivalent expression in Python) and XML to be an ungodly mess. :)

Old but a good read: http://dirtsimple.org/2004/12/python-is-not-java.html

Share this post


Link to post
Share on other sites
I am using the Python module, xml.etree.ElementTree right now and I have completed the basic conversation interface. It's ridiculously easy to parse an XML file using the ElementTree. JSON also seems a good idea. I suspect that changing over would not be TOO difficult since what I'm doing is reading the XML and then creating an internal representation of the dialogue as a python dictionary during the dialogue playback. This is working well for me so far. To change the format, all I need to do is to add additional code for conversion of other formats into my internal representation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this