.
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
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
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.
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.
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.
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.
@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, ..., ..., ...
@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.
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)
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
