You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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?
Code for drawing and displaying text and textboxes
Scribble
Textbox drawing
Textbox sizing / positioning
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
The text was updated successfully, but these errors were encountered:
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
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?
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?
The text was updated successfully, but these errors were encountered: