Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overview: Responsibilites of textboxy #41

Open
glitchroy opened this issue Apr 22, 2020 · 0 comments
Open

Overview: Responsibilites of textboxy #41

glitchroy opened this issue Apr 22, 2020 · 0 comments
Labels
discussion Further discussion is requested

Comments

@glitchroy
Copy link
Owner

glitchroy commented Apr 22, 2020

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
@glitchroy glitchroy added the discussion Further discussion is requested label Apr 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Further discussion is requested
Projects
None yet
Development

No branches or pull requests

1 participant