Jump to content
  • Advertisement
Sign in to follow this  
Carbon101

.

This topic is 2097 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
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

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

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

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

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

 

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!