+
Skip to content

Overview: Responsibilites of textboxy #41

Open
@glitchroy

Description

@glitchroy

In this doc, I will try to outline what responsibilites the textboxy project should have and how it is structured. Probably just for internal use and as an overview.

Different parts of textboxy

  1. textboxy is a dialogue management system. That means you should be able to create branching dialogue trees (of limited complexity) with effects such as pauses directly in-code. This dialogue tree should be indepentent from the actual representation of the dialogue.
    • Includes defining text and control codes, the flow of different dialogue passages, conditional branching and labels.
  2. textboxy is a textbox management system. That means it should take dialogue trees as code and display them in-game.
    • Includes performant drawing of the textbox and the text itself as well as special effects, drawing and positioning the textbox in relation to the game world or camera and taking and processing inputs from the player.

That means textboxy is split into a logical part that should handle defining the flow and content of the dialogue itself, and a displaying part, handling the drawing of text and textboxes.
How should these two responsiblities interact? Ideally, the logical part of textboxy is decoupled in such a way that in can be input from any source, e.g. the in-engine code or an external file. The displaying part should not care where the code is defined, as long as it is well-structured.

textboxy-drawer?

Should the two parts be split into two projects? Having a lightweight textboxy-drawer (or interpreter) as a add-on of sorts for scribble would allow game devs to only include that if they provide external dialogue trees.

What would a dedicated drawer have to include?

  1. Code for drawing and displaying text and textboxes
    • Scribble
    • Textbox drawing
    • Textbox sizing / positioning
  2. Code for handling the structure of the dialogue tree (input)
    • TbyBranch lifecycle logic
    • Data structure handling

Can point 2 be somehow included in the actual dialogue tree data, cutting the theoretical size of textboxy-drawer down to the actual drawing only?

Dialogue tree markup: textboxy-gen

How should the data that textboxy-drawer takes as input be structured? Let's call the in-code editor that works with TbyBranches textboxy-gen.

What would textboxy-gen need to include?

  • Exporting the content, logic, flow and branching of the dialogue tree into data.
  • Clear, understandable syntax for the end user that fits into GMS syntax.
  • Should not need any GMS objects or scribble dependency

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionFurther discussion is requested

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载