Sign in to follow this  
Carbon101

x

Recommended Posts

AverageJoeSSU    564
Whatever you do, I have heard from quite a few people that a human readable format is a must.

Maybe spreadsheets or xml or something. Just store the dialogue using an npc's id/name
As the key. If it is straight linear, that's really all it should take.

Also, you could store flags for testing conditions

Share this post


Link to post
Share on other sites
Nicholas Kong    1535

As a simplistic approach. you can store the text of dialogue in a Notepad text document.  

 

If you want to extend the feature further like having those text of dialogue being able to be parsed corresponding its text sprite counterpart, it would be easier to read through the file from the text document and have a java class you would write perform the task of parsing the text accordingly and then drawn the text sprite counterparts onto a text bubble of the npc.

 

If you decide to the text bubble approach, bear in mind about long text of dialogue. Consider how much text should appear in that bubble, upon pressing x erase the dialogue you have seen and drawn the next dialogue text until it has exhausted all the text dialogue. 

Edited by warnexus

Share this post


Link to post
Share on other sites
Satharis    2444
Entirely depends on how you want to implement it, the only real rule here is that you're trying to connect strings of dialogue to some kind of game object or event, how you manage that is totally up to you.

For a worst case scenario, games like say.. Terraria, actually store -all- of their game dialogue in giant switch statements. Probably the dumbest possible way of doing it, but the game demonstrates that it works, so, there you go. You're not really asking anything that can be easily given a silver bullet answer to, it depends a lot on your game.

Share this post


Link to post
Share on other sites
Diventurer    1631

Whatever you do, I have heard from quite a few people that a human readable format is a must.

Oh? Why is that? Personally I've just made a custom dialogue scripting language, but I have also thought about making a dialogue editor program. If I did that, I would most likely make a format that is almost impossible for a human to read. Why is it necessary for the format to be humanly readable when you can just use your format? If you need a text document for the dialogue, you could just make the program output a readable document.

Share this post


Link to post
Share on other sites
kremvax    212

@diventurer , I guess the idea is to make it easier to translate the texts if ever the game went to be localized. Simple CSV files are fine for that. I mean they are fine for storing keys / values kind of data, but the dialogs structure should be defined elsewhere.

 

 

Czar05: Since you have linear dialogs, the structure is not so complicated. For instance you could have :

 

- 1 structured data file (like json data) which stores the dialog sequence

{ KEY_SEQUENCE: [{ character: X1, KEY_TEXT: Y1}, { character: X2, KEY_TEXT: Y2}] }

 

- localization CSV file

KEYS, EN, FR, DE ...

Y1, ..., ..., ...

Y2, ..., ..., ...

Edited by jotak

Share this post


Link to post
Share on other sites
Diventurer    1631

@diventurer , I guess the idea is to make it easier to translate the texts if ever the game went to be localized. Simple CSV files are fine for that. I mean they are fine for storing keys / values kind of data, but the dialogs structure should be defined elsewhere.

 

Since you have linear dialogs, the structure is not so complicated. For instance you could have :

 

- 1 structured data file (like json data) which stores the dialog sequence

{ KEY_SEQUENCE: [{ character: X1, KEY_TEXT: Y1}, { character: X2, KEY_TEXT: Y2}] }

 

- localization CSV file

KEYS, EN, FR, DE ...

Y1, ..., ..., ...

Y2, ..., ..., ...

I guess you could have both a human readable format and a non-readable format then. The developers work with a program to make it easier to make more complex dialogues, but translators can work with an output file where you only need to edit text. Maybe a bit more work, but it could be quite nice.

 

Also, I am not the OP. It seemed like you replied to me as if I was the OP. My scripting language was for tree dialogues, and it was pretty flexible.

Share this post


Link to post
Share on other sites
kremvax    212

I guess you could have both a human readable format and a non-readable format then. The developers work with a program to make it easier to make more complex dialogues, but translators can work with an output file where you only need to edit text. Maybe a bit more work, but it could be quite nice.

 

I agree with that but if there's no need for complex dialog here, then simpler is better. The idea of a simple sequential data file is ok when there is no multiple choice questions for the player, no "behavioral" AIs who would have to choose between various responses, etc.

 

Also, I am not the OP. It seemed like you replied to me as if I was the OP. My scripting language was for tree dialogues, and it was pretty flexible.

 

(my post wasn't clear about that ... just edited it)

Share this post


Link to post
Share on other sites
Nicholas Kong    1535

 

Whatever you do, I have heard from quite a few people that a human readable format is a must.

Oh? Why is that? Personally I've just made a custom dialogue scripting language, but I have also thought about making a dialogue editor program. If I did that, I would most likely make a format that is almost impossible for a human to read. Why is it necessary for the format to be humanly readable when you can just use your format? If you need a text document for the dialogue, you could just make the program output a readable document.

 

It is easier for other people to read your work not just your teammates but if you wind up working for someone else, you better write it clean. Horrible looking code is just bad style and costs time and money.

Share this post


Link to post
Share on other sites
Carbon101    1292

Wow! thanks for the input everybody.

 

So just to clarify, all that is needed is notepad and XML to write the dialog in a separate file. Each piece of dialog will have an ID that corresponds to a particular NPC in the game. correct?

Edited by Czar05

Share this post


Link to post
Share on other sites
haegarr    7372

I have to disagree in part. Although not being mentioned explicitly in the OP, I assume we're speaking about a format for the game and not one for the development stage. Here are my 2 Cents:

 

File formats like XML in general, Collada, OpenEXR, ... are good for development, file exchange, and (in the case of XML) for my part also for configuration. They are application file formats, so to say. They are less suited as file format for games, although they can be used there, of course. The reason is that they tend to be bloated, are needlessly complicated to be parsed, and hence have a negative impact on memory footprint and execution duration.

 

But we want to get rid of e.g. load screen, don't we? Well, to overcome this issue, games usually have their own file formats. These are binary, compact, with as less need for interpretation as possible, perhaps even packed to enable better streaming performance. A good example is BitSquid. There is also an article at Gamasutra; unfortunately I don't find it ATM. There are also a dozen or so threads here on GDnet that discuss this topic. I mean, would someone use NetPBM P3 format because it is human readable? A big No. Instead, we want textures even to be compressed already on disk, and complain that Khronos had let passed so much time until compressed textures could finally be loaded directly.

 

Back to dialogs! Dialog is a topic I'm currently concerned with in depth, because I'm just now developing an interactive, non-linear graphics novel system with, of course, locale support. Text itself is just one side of the problem. Embedding it is another.

 

The OP mentioned that the dialog is pre-defined and linear for now, so we don't need to speak about dynamic text substitution, article and pronoun and proper name handling, and similar things. Although, IMHO, features like an inventory would profit from such mechanism, too. If interested in, there is an article at Gamasutra that sheds some light on this problem and proposes a possible solution (don't get scare off by the term "MMOG" in its caption). It is a kind of scripting but with an emphasis on the textual character rather than programming.

 

Coming now to the embedding of text. Text needs to be fragmented to allow its handling, and the fragments need to be identified. Fragmentation is to be expected due to a change of the speaker, a dramatic pause, to avoid text overflow on screen, waiting for the player finished reading, whatever. Text needs to be put on screen somewhere, at some point in time, in a defined sequence. This introduces three layers: The text fragments itself, each one with a unique identifier (preferably numeric) and an identifier of the speaker (if pre-defined), the transitions from one fragment to another (here comes pausing, waiting on user action, sequencing, branching, parallelism, and the like), and finally the decision where to render. The first two layers have an impact on the file format.

Edited by haegarr

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