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
Refactor FontEngine and Dialoger so that FontEngine takes all the parsing tasks of Dialoger. Rename FontEngine to TextEngine and make it a wrapper for a TextParser and TextRenderer class which can be modularly swapped out to allow changing of syntax and rendering.
Note TextEngine is fully implemented while TextParser and TextRenderer are abstract classes with key functions left unimplemented. Ideally implementations will extend these two (though they can be disregarded).
No progress has been made on the implementation of these two classes and the refactoring of Dialoger.
Original Issue:
The idea has come up of creating a generic API so that:
(a) The way conversations are displayed
(b) The way text formatting is parsed
(c) The way text is rendered
Are split up into three separate replaceable modules. Don't like how we render text? Swap it out. Don't like our syntax? Swap it out. Want conversations to just be alerts? Swap it out.
As it stands, (a) is handled by the Dialoger class for the most part. However it performs some of the roles of (b). For example it parses the text into "batches" (the @ delimiters).
(b) and (c) are handled by FontEngine, however for the most part, FontEngine is already broken up into essentially two parts, the parser and the renderer, via the parser handing the rendering code FormatRange objects, that describe what to render. However it ultimately is one object and shares a bunch of stuff.
The questions would then be:
Is it worth it?
Should the batch parsing be moved out of Dialoger, and/or Dialoger split into two objects (batch parser, and batch renderer)?
Should FontEngine be broken into two classes, FontParser and FontRenderer?
Also how would this be architected?
With not much thought it would make sense to me to do it something like:
DialogParser has a DialogRenderer has a FontParser has a FontRenderer, and the core engine basically just dumps the text to DialogParser and calls it a day. Similarly the command prompts just go straight to FontParser to handle themselves, I guess.
The text was updated successfully, but these errors were encountered:
Refactor FontEngine and Dialoger so that FontEngine takes all the parsing tasks of Dialoger. Rename FontEngine to TextEngine and make it a wrapper for a TextParser and TextRenderer class which can be modularly swapped out to allow changing of syntax and rendering.
Proposed implementation of TextEngine here: https://github.com/Gankro/Sburb-Legacy/blob/text-engine/TextEngine.js
Note TextEngine is fully implemented while TextParser and TextRenderer are abstract classes with key functions left unimplemented. Ideally implementations will extend these two (though they can be disregarded).
No progress has been made on the implementation of these two classes and the refactoring of Dialoger.
Original Issue:
The idea has come up of creating a generic API so that:
(a) The way conversations are displayed
(b) The way text formatting is parsed
(c) The way text is rendered
Are split up into three separate replaceable modules. Don't like how we render text? Swap it out. Don't like our syntax? Swap it out. Want conversations to just be alerts? Swap it out.
As it stands, (a) is handled by the Dialoger class for the most part. However it performs some of the roles of (b). For example it parses the text into "batches" (the @ delimiters).
(b) and (c) are handled by FontEngine, however for the most part, FontEngine is already broken up into essentially two parts, the parser and the renderer, via the parser handing the rendering code FormatRange objects, that describe what to render. However it ultimately is one object and shares a bunch of stuff.
The questions would then be:
Is it worth it?
Should the batch parsing be moved out of Dialoger, and/or Dialoger split into two objects (batch parser, and batch renderer)?
Should FontEngine be broken into two classes, FontParser and FontRenderer?
Also how would this be architected?
With not much thought it would make sense to me to do it something like:
DialogParser has a DialogRenderer has a FontParser has a FontRenderer, and the core engine basically just dumps the text to DialogParser and calls it a day. Similarly the command prompts just go straight to FontParser to handle themselves, I guess.
The text was updated successfully, but these errors were encountered: