Best practices
Posted: Thu Aug 04, 2016 3:12 pm
I am cleaning up my 1000 node dialogue today and just reflecting on the early design decisions that made thing easy/hard to work with. I think it would be useful for people starting out to sea your suggestions on best practices/lessons learned while using the Dialogue System. This has been a great product to work with but some design decisions I made early on affected how easy my dialogue was to maintain.
My two cents...
EASIER:
* Asking for help. The support has been consistently outstanding.
* Use nodes with the "group" flag to identify entry and exit points into a conversation.
* Using the Title field to describe entry and exit conditions. This is really useful when checking things in excel.
* Using the Description field to describe the scene. So when you come back, you can remember what the key decisions were.
* Use a big monitor. With a 40" monitor I was finally able to read the Unity default fonts. Thank you Toni for the scaling the node editor!
* Use the watch window (~L).
* Use the folder structure style naming scheme... root\child\grandchild it cleans things up a lot.
TRADEOFFS:
*Big conversations are easier to create and follow but if you re-import the database they become a rats nest.
*Big conversations (multi-screen) are harder to document and screen capture. Had to use photo stitching software to make the images. Still this might be easier then jumping from one conversation to the next. I tried both and ended up favoring smaller dialogues.
HARDER:
* Consider where your dialog will exit to. Can your players restart the conversations if the dialogue system exits unexpectedly? In my case exiting the dialogue left the players at a blank screen. That was a bad choice. Particularly because typo's in my function calls caused the dialog system to close the conversation. (Note the game did not become corrupt or crash so kudos to Toni).
* Deciding to support up to 5 decisions per dialog choice. My graphs grew insanely complex very quickly.
* Adding/revising conversations non-sequentially. It would have been nice if my Conversation ID order matched up to my conversation order. Doing this again, I would leave an extra conversation node for expansion when I was finished working on a conversation. From experience, changing the conversation ID value before you write any nodes than the database will not be corrupt. Changing the conversation ID after the nodes are written will probably cause your dialog to fail.
* Spell checking in excel. I wrote a lot of dialogue late at night. The embedded field codes made things really hard to spell check. Turned out Notepad++ was much easier to use then excel. The Dialog system supports normal returns, so avoid putting in the \n and | symbols that are expected in Chat Mapper.
* Not reading about "episodic writing" techniques before starting. Utilizing check points and circular soap opera type stories would have made things easier. At the end of my project I found a good book on this.
* Using Lua functions with mixed case name "Acode()" a typo on the function call kills your dialogue. I ended up creating a second function acode() just to catch the typo's. Calling undefined Lua functions causes the conversation to end.
* The Game Manager changed where I had to put my work. I traded one set of problems for another.
* Asking for the ability to backwards in the conversation. This creates a lot of problems and revisionist play.
My two cents...
EASIER:
* Asking for help. The support has been consistently outstanding.
* Use nodes with the "group" flag to identify entry and exit points into a conversation.
* Using the Title field to describe entry and exit conditions. This is really useful when checking things in excel.
* Using the Description field to describe the scene. So when you come back, you can remember what the key decisions were.
* Use a big monitor. With a 40" monitor I was finally able to read the Unity default fonts. Thank you Toni for the scaling the node editor!
* Use the watch window (~L).
* Use the folder structure style naming scheme... root\child\grandchild it cleans things up a lot.
TRADEOFFS:
*Big conversations are easier to create and follow but if you re-import the database they become a rats nest.
*Big conversations (multi-screen) are harder to document and screen capture. Had to use photo stitching software to make the images. Still this might be easier then jumping from one conversation to the next. I tried both and ended up favoring smaller dialogues.
HARDER:
* Consider where your dialog will exit to. Can your players restart the conversations if the dialogue system exits unexpectedly? In my case exiting the dialogue left the players at a blank screen. That was a bad choice. Particularly because typo's in my function calls caused the dialog system to close the conversation. (Note the game did not become corrupt or crash so kudos to Toni).
* Deciding to support up to 5 decisions per dialog choice. My graphs grew insanely complex very quickly.
* Adding/revising conversations non-sequentially. It would have been nice if my Conversation ID order matched up to my conversation order. Doing this again, I would leave an extra conversation node for expansion when I was finished working on a conversation. From experience, changing the conversation ID value before you write any nodes than the database will not be corrupt. Changing the conversation ID after the nodes are written will probably cause your dialog to fail.
* Spell checking in excel. I wrote a lot of dialogue late at night. The embedded field codes made things really hard to spell check. Turned out Notepad++ was much easier to use then excel. The Dialog system supports normal returns, so avoid putting in the \n and | symbols that are expected in Chat Mapper.
* Not reading about "episodic writing" techniques before starting. Utilizing check points and circular soap opera type stories would have made things easier. At the end of my project I found a good book on this.
* Using Lua functions with mixed case name "Acode()" a typo on the function call kills your dialogue. I ended up creating a second function acode() just to catch the typo's. Calling undefined Lua functions causes the conversation to end.
* The Game Manager changed where I had to put my work. I traded one set of problems for another.
* Asking for the ability to backwards in the conversation. This creates a lot of problems and revisionist play.