search

swooboo / HERITAGE

HERITAGE is a text adventure game engine, written in Javascript, capable of interpreting .heritage files.
GNU General Public License v3.0
0 stars 0 forks source link

Parsing game definition data #3

Open swooboo opened 7 years ago

swooboo commented 7 years ago

I think I'm almost done with game entities definition, and I suppose now it's time to code the parser. I've read your take on it, and I liked it, but had a feeling that there's got to be a better way... There's one I found online - PEG.js. It's a full-blown parser, and it seems to fit our needs, but I'm not sure how well it will handle the lack of closing token for each entity. EDIT: found another one - nearley.js, which looks like a more mature one, v2.7.7, in comparison with v0.10 for PEG.js.

What do you think @TheLastProject?

TheLastProject commented 7 years ago

I have no experience with any such libraries, although they look okay. Especially nearley.js looks fancy and helpful for documenting. The main point of HERITAGE's grammar is to be simple for non-developers, but it has gotton hacky over time, so if you want to make changes to simplify parsing, by all means feel free to do so, it could use a bit of cleaning up anyway.

swooboo commented 7 years ago

Thanks for the insight. I'm all for having a simple grammar so creative non-developers could generate content, and I think you made a good job of keeping it that way. I didn't start writing the parser yet, so I don't know what you have in mind. Which cleaning up are you talking about?

TheLastProject commented 7 years ago

On the subject of cleaning up, mostly the functions are not logically named and can become really messy in complex situations: https://heritage.readthedocs.io/en/latest/pages/functions.html

swooboo commented 7 years ago

The 'not logically named' - are the names you're referring to are @, !, # and $? If so, I'll probably replace it with one format with sub-names, like @(calculate turn + 1), @(update turn: turn + 1) and so on.

TheLastProject commented 7 years ago

I suppose that's already a good improvement. Slightly more verbose but more readable.

swooboo commented 7 years ago

I've read into nearley a little more. It looks really good for us, check this CSV parser example - https://github.com/Hardmath123/nearley/blob/master/examples/csv.ne. This looks really close to .heritage files, with the exception that there are different modes of parsing for each entity type. Other than that, it parses multi line data. Also, the grammar definition looks pretty clear to me. I'll probably start with this CSV grammar and work on top of it.

bd82 commented 7 years ago

Hello.

I've found this discussion via the the link to the nearley issue. There are many Parsing Libraries in the JavaScript world.

I am aware of at least seven. And have created a performance benchmark for those. http://sap.github.io/chevrotain/performance/

As the author of one of these (Chevrotain) I am probably biased 😄 But if you are looking for an option which can be "client-side only" The two top options to look at would be:

Simply because these two have no code generation phase.

I think PEG.js and Ohm.js can also be used in a "client side" only manner but that may require placing the grammar inside some html tag or even worse in a literal string.

swooboo commented 7 years ago

@bd82, thanks a lot!!! I'll definitely look into these. I found only 2 and not 7, this definitely will be a good research. My picks were PEG.js and nearley...