BA/MA: Dialog Situation Generation

Focus of this thesis is to analyze and extend an existing model for dialog situation generation. Instead of a verbal dialog where two parties exchange messages, we do not regard which words are used, but rather which situations they create. For example, in a scenario where a manager gives feedback to an employee, the manager has addressed that she deems the documentation of low quality to which the employee has multiple options for replying, e.g., by blaming the tight schedule, by blaming someone else who was responsible, by simply disagreeing with the assessment of the quality by the manager etc.

In the context of a serious game targeted at managers where they train giving feedback to their employees in a virtual reality environment where intonation, gestures and facial expressions of the player are taken into account, we want to generate many different dialogs, such that the player can explore many situations.

Often, story engineers create a dialog tree for a game. However, when considering multiple options to continue a dialog, the size of dialog trees grows rapidly. Due to this being a tedious task, dialog trees are either usually kept small and the set of possible situations is small or developing and maintaining large trees costs a lot of effort.
We have created an initial model based on actions with preconditions and postconditions. Instead of manually creating a tree, the tree can be constructed automatically from the actions. A dialog situation is modeled as a set of binary states and an action can be applied to transform this state if the preconditions of the action match the situation.

Here are examples of some actions:
        # E replies to negative feedback about documentation: she disagrees and questions M's assessment
        {
            preconditions => {
                M_has_initiated_the_feedback_session => 1,
                E_is_known_for_writing_good_documentation => 0,
                M_has_given_negative_feedback_on_documentation => 1,   
                M_has_asked_about_reason_for_bad_documentation => 1,
                E_has_responded_to_negative_feedback_on_documentation => 0,
            },
            postconditions => {
                E_has_responded_to_negative_feedback_on_documentation => 1,
                E_disagrees_with_negative_feedback_on_documentation => 1,
                E_questions_Ms_assessment => 1,
            },
            action => "E_disagrees_with_negative_feedback_on_documentation",
            text => "Well, have you really looked at it yourself? I believe that my code documentation is very well done!"
        },

        # E replies to negative feedback about documentation: she agrees, but has a reasonable excuse
        {
            preconditions => {
                M_has_initiated_the_feedback_session => 1,
                E_is_known_for_writing_good_documentation => 0,
                M_has_given_negative_feedback_on_documentation => 1,   
                M_has_asked_about_reason_for_bad_documentation => 1,
                E_has_responded_to_negative_feedback_on_documentation => 0,
            },
            postconditions => {
                E_has_responded_to_negative_feedback_on_documentation => 1,
                E_agrees_with_negative_feedback_on_documentation => 1,
                E_has_a_reasonable_excuse_regarding_quality_of_documentation => 1,
            },
            action => "E_agrees_with_negative_feedback_on_documentation_and_has_a_reasonable_excuse_(1)",
            text => "Yes, for sure it can be improved, but we planned this for the next iteration"
        },

        # E replies to negative feedback about documentation: she agrees, but blames_tight_schedule
        {
            preconditions => {
                M_has_initiated_the_feedback_session => 1,
                E_is_known_for_writing_good_documentation => 0,
                M_has_given_negative_feedback_on_documentation => 1,   
                M_has_asked_about_reason_for_bad_documentation => 1,
                E_has_responded_to_negative_feedback_on_documentation => 0,
            },
            postconditions => {
                E_has_responded_to_negative_feedback_on_documentation => 1,
                E_agrees_with_negative_feedback_on_documentation => 1,
                E_blames_schedule_for_bad_quality_of_documentation => 1,
            },
            action => "E_agrees_with_negative_feedback_on_documentation_and_blames_tight_schedule",
            text => "Yes, for sure it can be improved. However, the schedule was too tight."
        },

        # E replies to negative feedback about documentation: she agrees, but blames a subordinate
        { #inactive => 1,
            preconditions => {
                M_has_initiated_the_feedback_session => 1,
                E_is_known_for_writing_good_documentation => 0,
                M_has_given_negative_feedback_on_documentation => 1,   
                M_has_asked_about_reason_for_bad_documentation => 1,
                E_has_responded_to_negative_feedback_on_documentation => 0,
            },
            postconditions => {
                E_has_responded_to_negative_feedback_on_documentation => 1,
                E_agrees_with_negative_feedback_on_documentation => 1,
                E_blames_subordinate_for_bad_quality_of_documentation => 1,
            },
            action => "E_agrees_with_negative_feedback_on_documentation_and_blames_subordinate",
            text => "Yes, for sure it can be improved. Michael was responsible - he seems to have forgotten to take care."
        },

Within the scope of the thesis, from the following list, multiple topics can be addressed, but of course not all of them:
* How can argumentation theory be taken into account when modeling the actions?
* What are limitations of the current formalism?
* Which methodology would enable developers to cover relevant actions, check for completeness and consistency and, in general, test the model?
* How can we modularize the actions into smaller mostly independent sets such that the set of actions becomes maintainable?
* How could possible actions be crowdsourced?
* Which actions are relevant if the purpose of the game is to train people for applying feedback strategies?

Some programming skills are expected. This thesis can be framed as a bachelor thesis or as a master thesis.

Contact Basil Ell or Pejman Sajjadi for more information.