Workflow Improvement Suggestion: combining action lists and conversations

PixelArtist

So I've been doing a lot of thinking about AC's dialogue editor and conversation mapping interfaces.

While I find action lists really easy to use and modular, the conversation editor tools in AC make it a real challenge for me to mentally map an entire conversation in my head. There are too many screens to sift through and get lost in and one must often use the hierarchy window to navigate back to the start of a conversation.

Here are 2 UI design changes that would really improve my workflow. What do you guys think?

hedgefield

Seconded. The dialogue system in AC feels like it hasn't been iterated on as much as the other features. I found it hard to parse for the same reason you mentoined, having branching dialogue is hard to map out as it is, and by fragmenting the workflow it makes it even harder. Having the choices and the responses in the same window would already be hugely helpful, and the other things you point out to simplify the workflow make sense.

For my current project I am very happy with Dialogue System For Unity by Pixelcrushers, and it integrates really well with AC, but having AC as the one-stop-shop for future projects would be greatly preferrable of course.

PixelArtist

FYI, I haven't actually modified AC yet, but I wanted to design a mockup first rather than stumbling through a rough implementation. Hopefully there's a way for me to build this with actions so I don't need to rewrite a significant chunk of AC...

Yeah I've looked into Dialogue System extensively. I like the flowchart interface and the wide variety of UI solutions, but found the integration with AC to be too weak and error-prone. Trying to play cutscenes and Action Lists within dialogue is doable but painful to hook up and navigate in the editor. Most importantly, you can't see what sequences each node has assigned to it, which makes iterating and debugging a nightmare. Unfortunately, Dialogue System is limited by it's integration with ChatMapper, which dictates the fields it may include in the dialogue nodes. This is why Tony can't make Dialogue System into a more unity-specific interface (which I think AC does rather well).

I mean, I've even looked into timeline interfaces for better mapping out Adventure Creators action lists in cutscenes. Ultimately that proved to be a more static and fragile system than AC's Action Lists, but I think animation timelines will play a role in AC's future...somewhere.

In the long run, I just seems a lot more risky to be reliant on two plugins of this size that depend on each other so greatly. I'd rather just use AC.

PixelArtist

After giving this more thought, I came up with a potentially simpler option: tighter Playmaker integration!

Rather than reinventing the wheel, we could use Playmaker's state machine interface with AC's actions lists. To do this, we'd need a custom Playmaker action for each AC action:

https://hutonggames.fogbugz.com/default.asp?W350

We'd also need a custom Playmaker action for dealing with AC conversations.

With this approach, we'd get a high level overview of how action lists interact with conversations in a cleaner, clearer interface. Of course, this abstraction also makes it harder to see specifics, like individual lines of dialogue from the birds eye view, but the tradeoff may be worth it.

What do y'all think?

ChrisIceBox

Some excellent suggestions in here, good work.

Much of the "quirks" of the current system are down to how Unity works (or at least my knowledge of it).  Multiple ActionLists on one object, for example, causes problems - is this what's going on in the Conversation mockup?  I like the idea of a Conversation being editable in the node editor, but the option lists themselves will always have to be in a separate list object.

Vertical nodes do make sense, though, and I'd like to look into some of this.  As for a timeline feature, it's been on my mind but it may well be much wiser to add integration with a dedicated asset instead.  What do you think of Cinema Director support?

PixelArtist

Regarding a timeline feature, my vote definitely goes towards Cinema Director support. I've tried other plugins like Animator, Flux, and uSequence and none of them compare to Cinema Director, IMHO.

In the meantime, I've begun creating custom PlayMaker actions that run AC scripts like ActionSound and ActionCharMove. I'm not sure if this will work in the long run, but I'm having some success using Object Composition to instantiate the AC actions within the Playmaker action scripts. Here's an example of one I hacked together for the ActionSound action: PlaySoundFSM.cs

Chris, do you think this approach would work for most of the AC-specific actions? Which systems could you foresee this being an issue with?

PixelArtist

Also, in response to your question:

Multiple ActionLists on one object, for example, causes problems - is this what's going on in the Conversation mockup?

Perhaps this was naive of me, but I was actually proposing that we could simplify the Cutscene / Interaction / DialogueOption model by making conversations an action that could work in any ActionList. Generic ActionLists could then serve the same functions as cutscene, conversation, and interaction scripts had previously.

From what I can tell, the difference between Cutscene, DialogueOption, and Interaction ActionLists is very minimal. If that level of abstraction was removed and they were all just ActionLists, then the player could create any of the above simply by arranging actions on a generic ActionList.

Does this make sense?

hedgefield

PlayMaker integration would be a pretty good idea actually. It is another plugin to rely on, costlier than Dialogue System, but I think Playmaker is much more widespread and much further along in development in terms of stability and such. We used it for the 2.5D adventure game we made at my old company back before Unity even supported 2D and before I could even dream of AC, so we built our own actions in Playmaker, very similar to what you are suggesting. Managing the conversations that way is very pleasant to work that way, so porting AC actions to FSM actions would be a really great solution I think.

ChrisIceBox

Chris, do you think this approach would work for most of the AC-specific
actions? Which systems could you foresee this being an issue with?

The main issue I was going to raise was that of adding the AssignValues parameter, but I see you've already covered that.  1.41 will likely reduce the number of component variables needed as well - things like the various managers, GameEngine scripts etc are being made into static variables.

From
what I can tell, the difference between Cutscene, DialogueOption, and
Interaction ActionLists is very minimal. If that level of abstraction
was removed and they were all just ActionLists, then the player could
create any of the above simply by arranging actions on a generic
ActionList.

The issue isn't so much the separation of ActionList "types", but the way AC expects them to work: a list is called, it runs it's various Actions, and then stops.  AC uses this simple way or working to it's advantage: for example, it places the game in a "blocked gameplay" state if any ActionLists set to "Pause Gameplay" are currently running.  It can also make decisions about what "skipping" will achieve, whether or not saving is possible, etc.

If an ActionList were to contain your suggested "conversation" Action, AC would no longer be able to do these things - because the same ActionList could mean any of several different things depending on how "far along" it's progressed.  It would also make it difficult (on the user side) to trigger the same conversation (or use a "cutaway" ActionList midway through a response) because the conversation is now tied to the Actionlist itself.

Keeping the various responses (i.e. DialogOption lists) in separate places does at least keep things very straightforward - even if it might not be the most user-friendly.  As a compromise, what if the various Conversation "tools" (such as being able to manage options etc) were to be integrated into the node editor, while the options themselves were still kept separate?