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

TextEngine #3

Open
Gankra opened this issue Oct 25, 2012 · 0 comments
Open

TextEngine #3

Gankra opened this issue Oct 25, 2012 · 0 comments

Comments

@Gankra
Copy link
Member

Gankra commented Oct 25, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant