0 Favourites

Dialogue best practices - and where to store text

  • Hi dudes, I've been trying to find as much as I can about the different way people use Construct 2 to show dialogue between characters & NPCs, and have searched this forum many times to get many different ways of doing it - from loading via text file, or long and cumbersome amounts of events within Construct itself.

    An example like this one scirra.com/forum/topic61701.html by Miu3 seems common, especially with those few people I've seen who want to create interactive story books. The dialogue is stored in instance variables on the character objects, and events track which scene you're in. Which is absolutely fine, but the amount of dialogue that needs to go within Construct 2 could end up becoming immense, and get completely out of control. And what if you want to change something? The idea of going through potentially hundreds of events, actions and instance variables and changing them makes me worry that I have to get this right first time!

    Then of course there's Aluriak/Yann's example here scirra.com/forum/npc-dialog_topic48355_post303797.html, where the dialogue is stored in one big splat at the top of the event sheet. Which is also fine, but imagine if the text was a 100 times bigger, and there's many more characters to talk to. Again it'd become a nightmare.

    Would it be better if the text was stored externally in another file> This is how I've always imagined it should be, although splitting it away from the logic might make it even more confusing.

    There's so many options and I want to know which way is best practice, and most advised. How do you all handle this in your games?

  • Never did a dialogue system myself ... but I recommend arrays , it's easy to split each line with them

    Edit :

    Here , I made you an example to show how epic I am <img src="smileys/smiley2.gif" border="0" align="middle">

    The main code is in 5 events , you can easily change all the rest of the events to fit you

  • Thanks for taking the time to create that example Whiteclaws, I really appreciate it!

    I agree it's probably better to use arrays than instance variables. However it doesn't seem a very elegant solution, especially as it requires an action for every piece of spoken dialogue. Also you have to keep track of each NPC's number (which corresponds to the index in the array), which can get a bit tricky when you have many.

    The biggest problem with your solution however is that it won't work if an NPC needs to say more than 1 thing ever. Where would the second piece of dialogue go in the array?

    I think Aluriak/Yann's example here scirra.com/forum/npc-dialog_topic48355_post303797.html might be a more flexible solution than this, although I'm still interested in seeing more examples.

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • The best solution to what you want to do is JSON/Array

    Here you would write out the JSON file manually or use some kind of tool. Here you write in a format(please forgive me for my JSON parsing is in error, just use as theory)

    Mayor{

    image: mayorspresheet,

    speeches{

        hello{

          emotion: "smile",

          dialog: "Good day, your new around here; Our litte town...bleah"

        }

        abouttown{

          emotion: "excited"

          dialog: "oh my yes, our town has been prosperous for years..."

        }

    }

    }

    somevillain{

    image: "crucifix"

    speach{

        firstmeeting{

          emotion: "curiousgrin"

          dialog: "And who are you to intrude upon my work?"

        }

        mwahaha{

           emotion: "evillaugh"

           dialog: "mwa ha ha ha "

        }

    }

    }

    Now of course this is not accurate to how you will use it.

    emotion refers to animation set in the sprite sheet.

    names refer to the manual sprite name

    dialog names you have to figure a way to trigger them.

    When you import the JSON into the array. you will end up with 3 dimensional layer that you will need to create an in game event engine to handle

    DimensionX, this is the NPC's name.

    Function.Call("Dialog.Talk", NPC.name, NPC.dialog)

    ----

    Function Talk

    setimagesideright(NPCArray[Function.Param(0), Function.Param(1), 0) setdialog(NPCArray[Function.Param(0), Function.Param(1), 1) ----- Of course this is all simple design. You can also create JSON scripts to handle long conversations going back and forth. This would also be written to a different JSON and array. ConvoFile.json wakeupchrono{ 1{"mom", "wakeup1", "right"} 2{"chrono, "grumble", "left"} 3{"mom", "lazyson", "right"} 4{"chrono, "grumble", "left"}    ............... } chronolucafirst{ similar as above :P } anyways. this is probably the best way to handle it in my opinion. It's probably the most long term solution for LARGE games with more complex dialog and even include tree options into the speech.     firstmeeting{       emotion: "curiousgrin"       dialog: "And who are you to intrude upon my work?"       options{         1{ reply: "i'm askign the question", "shepard", "pissedoff", "Shut up before I shoot."}         2{ reply: "I'm shepard, and you are"....         3{ reply: "[Shoot]", ....}

          }

        }

    anyways. i've written enough and probably made it a large incoherent mess :P good luck.

  • jayderyu you're awesome! Thanks for the brilliant example. I'm going to have to take some time to absorb this and work it into my game! I'll keep you posted with progress :-)

  • As a follow up after playing around with some C2 JSON creation strings and array importer. I would mandatorally suggest making the conversation tools with C2.

    C2 has it's requirements as to what the JSON looked like. I tried implementing the above dialog structure for quick test and it didn't work so easily. Unfortunatly it seems C2 can't just do a raw JSON import :(

    Here is what you need to consider if you do it by hand.

    The over structure must be encapsulated by

    {""C2Array": true, ""size"" : [x,y,z], ""data"": { your stuff } }

    All objects names must be in "" "" two set's of qoutes each

    You can't alternate with " ' ', ' ' "   C2 doesn't interpret ' :(

    the C2 wrapper of the object require the above

    it's actually a massive pain.

    So you really are better writing some kind of tool that will fill the array in the tool. Then you can export the array as a JSON string. Then that should work :

    unfortunally for all the webstandards that C2 dos use. the JSON seems to not be one of them.

  • Hello all, I am also slowly moving forward to the point I need something similar.

    How do people feel about using XML? That should also be a fairly customizable solution.

  • I don't think anyone is particullaly fond of one format over the other. Whom ever get's a working spritesheet and toolset I think would be the key :P

  • I don't have a practical suggestion to dialogue implementation because I'm looking for one too. However if you somehow want to sort it out with spreadsheet format, rexrainbow's csv plugin will get anything spreadsheet related sorted for you.

    I'm thinking about some form of tree structure myself, but cocoonjs can't export xml which I eventually want to use.

  • You could also use the dictionary object and store everything as keys.

    Set key npcname & conversationname & paragraph to "Hello."

    I haven't tried it though, so it might actually be cumbersome in practice, but in theory it seems like a good idea, as that way you could store it all and not have to worry about the grid of an array, and could retrieve whatever you wanted with a few variables (it would probably make branching dialogue easier as well).

  • If we could i think a way to store the text in a sprite and then create multiple frame for a text and then just use code and variable for easy. An example is the feature in Liveswif i think 2.0 had a way to create sprite text along with different frames to use. Thus is lots easier to deal with then just multiple text box raw json and or too many set text events. I still have the liveswif program if anyone want to take a look at what i am talking about.

  • dragoonblade I don't think your idea is a very good one. Storing text as an image isn't going to be very helpful. What if you want to change it later on?

    Thanks jayderyu for your insight, I'm hoping to use JSON, but I'll be careful now after what you've said!

    Arima I haven't used the dictionary object yet, bth I didn't know what it's for! Was it originally intended for storing dialogue? (hence the name 'dictionary')

  • Not sure why the namesake "dictionary", but it's like the idea of a hash table, where you refer to data instantly by its key instead of trying to find the data by looping through the entire table. (Dictionary is still different than a hash though, hash cannot be looped and dictionary can.)

    The difference between array and dictionary only start to show when you're handling thousands of data. I don't know if Mass Effect even has that many dialogues. So it's a personal preference on how you want to search the dialogue.

    XML is made to be a tree structure. I didn't mention XML because I thought it's still having problems with CocoonJS for mobile conversion. Not sure if there's any update about that now.

  • onion - think of the dictionary object as a dynamic variable object that can create or destroy named variables (keys) at runtime.

    I tested it with 100,000 keys and retrieving info from it didn't affect the framerate, so it seems plenty fast.

  • Besides my own

    XML is a good format. I tend to lean towards JSON as I find it has less tag over head. However, either structure JSON/XML will do the same job. Also if your creating your own tool. Then there is no difference to the end user.

    Arima model I think is also easy to work with. using a coded key based on the parameters.

    Also with C2 current beta release. There is an ajax fix for CJS. So for mobile devices this makes XML/JSON files now possible :)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)