I worked on a couple of larger projects for the past years now and I’ve only made their dialog boxes quite haphazardly. They’ve only done one thing, which is to read a text file and display it. Some additional string splitting too. After those action games, I want to try my hand at a compelling, dialog heavy game. The gameplay can have the back seat for now. There have been a lot of games like these lately, especially chat-based stories. I’m not going for those, actually. What I’m thinking of is more on the style of the old Japanese RPG games where a lot of characters talk to the player and the responses are limited to a few choices.
Here’s some of the criteria I think I would need:
- Natively both human and machine readable. Like JSON files. I wouldn’t like to have it rewritten just to become input for the program. Write once and parse immediately, no duplicate files to manage.
- Easily visualizable. The same file formats could be used as input for a parser that can visually present the branches. Either it would also contain some text or just nodes with IDs. I think the Final Fantasy Tactics’ Quest Reports look nice.
- Can be split into multiple files. Not another file with 1000 lines of text. That’s hard to go through. At least, all related stories are on each of their files. The random ones can have one shared file.
- Dialogs can contain multiple choices. Buttons to be clicked after reading.
- Dialogs can chain together or branch out. Other dialogs should meet certain conditions before being available to present to the player. Those conditions can be varied: Based on past events, stat checks, past responses. I would also like to avoid having to process the entire database every time just to look for available dialogs.
- At the end of each conversation, it would lead to a specific Job to do. Earlier conversations can lead or branch to other ones before ending in a Job.
- Some dialogs are initiated as a result of other miscellaneous events such as buying upgrades, a specific time or date, and other game actions.
- Some dialogs can have expiration dates and have consequences when they expire.
One massive looming problem I am thinking of is localization. I probably won’t need it if it’s a solo project but… things can happen. What I’ve done before is a massive spreadsheet that’s easily presentable. But that just limits the complexity of the dialogs’ data structure because it has to be shrunk to just a few columns.
A draft of the Dialog data structure:
- Tags 
- Conditions 
- Consequences ???
- Conversation 
- Choices 
- Dialog ID
- Job ID
Evaluating the entire database just to find one available dialog should be avoided. There should be a smaller main array or list that’s processed. Only branches of current dialogs or dialogs waiting for their conditions to be fulfilled should be on this list. That’s the solution I can see for now, but I don’t think it covers the random conversation/job system requirement yet.