Jump to content

  • Log In with Google      Sign In   
  • Create Account

Incorporating Dialogue In Game?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Czar05   Members   -  Reputation: 1009

Like
0Likes
Like

Posted 16 October 2013 - 03:21 PM

I am writing a Java based RPG using Slick2D with a friend of mine. As of right now, we are in the early stages of development: mapping/design everything so we have a clear vision of what we are trying to do. Our game will have AI( NPC's ) present in the game and the players character will be able to engage with the NPC's through conversation. I was wondering how we would go about doing this. How would we store the dialogue? Would we need a scripting language( If we did, I was thinking Python with Java, is that okay)?

 

Important Note: The user will not control the the conversation. The dialogue will be linear, so we won't need any branching tree techniques (Unless if its needed).

 

Feel free to ask for more clarification, if needed. Thanks in advance.



Sponsor:

#2 AverageJoeSSU   Members   -  Reputation: 516

Like
0Likes
Like

Posted 16 October 2013 - 06:42 PM

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

------------------------------

redwoodpixel.com


#3 warnexus   Prime Members   -  Reputation: 1504

Like
0Likes
Like

Posted 16 October 2013 - 08:26 PM

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, 16 October 2013 - 08:40 PM.


#4 Satharis   Members   -  Reputation: 1281

Like
0Likes
Like

Posted 17 October 2013 - 03:49 AM

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.

#5 irbaboon   Members   -  Reputation: 906

Like
0Likes
Like

Posted 17 October 2013 - 11:14 AM

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.



#6 jotak   Members   -  Reputation: 156

Like
0Likes
Like

Posted 17 October 2013 - 02:15 PM

@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, 17 October 2013 - 02:45 PM.


#7 irbaboon   Members   -  Reputation: 906

Like
0Likes
Like

Posted 17 October 2013 - 02:37 PM

@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.



#8 jotak   Members   -  Reputation: 156

Like
0Likes
Like

Posted 17 October 2013 - 02:52 PM

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)



#9 warnexus   Prime Members   -  Reputation: 1504

Like
0Likes
Like

Posted 17 October 2013 - 03:00 PM

 

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.



#10 Czar05   Members   -  Reputation: 1009

Like
0Likes
Like

Posted 17 October 2013 - 09:20 PM

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, 17 October 2013 - 09:21 PM.


#11 jotak   Members   -  Reputation: 156

Like
0Likes
Like

Posted 18 October 2013 - 12:04 AM

It's just a solution, among many other. Up to you!



#12 haegarr   Crossbones+   -  Reputation: 4603

Like
0Likes
Like

Posted 18 October 2013 - 02:08 AM

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, 18 October 2013 - 02:08 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS