This language is intended to describe game data for use with https://github.com/benknoble/frosthaven-manager. (Really, there is likely to be more than one language or sub-language for different kinds of data definitions. But I expect them to look mostly similar and co-operate in some way.) It thus needs to be easy to write (by non-programmers) and forgiving of mistakes (small changes in syntax should not lead to large semantic changes). My thoughts on this are unfortunately spread out, so jumping into details is probably difficult. But I do identify some major questions at the end.
Describe an example program. What does this program do?
Example programs might:
describe a monster's statistics, in the normal and elite variations, across 8 different levels
modify an imported monster to create a unique variant, possibly based on calculations from values known at a later run-time
describe a monster's deck of ability cards, including initiative number, actions on the card (possibly in "special format"), and whether this card triggers a reshuffle of the deck
describe a set of monsters for a scenario, possibly by (the equivalent of) requireing monster programs (this might even be extended to optionally including player information in the same way)
Who would write programs in this language?
(Racket programmers, data scientists, artists, etc.)
Boardgamers, mostly. It thus needs to be easy to write (by non-programmers) and forgiving of mistakes (small changes in syntax should not lead to large semantic changes).
If you have futher examples, test cases, or datasets relevant to the
language, please describe them below.
Do you plan to implement this language? If so, are there any topics you would
like help with?
Yes, I plan to implement this. I'm particularly interested in
syntactic advice: how can non-programmers describe nested and referential data without needing to learn something complicated like JSON or YAML and without annoying "compiler errors" or invisible changes to meaning? Since I plan on making GUI applications that manipulate (some of? embedded calculations may be challenging) the data, I also need the format to machine-writable (readable is a given, since I'll need a parser).
semantic advice: since the language is mostly (but not entirely? there may be embedded calculations, essentially functions over pre-defined bindings) data-carrying, how can I make the data available to other programs, especially when the file containing the program is only known at runtime? In other words, what could the compiled result look like?
How can I embed support (e.g., syntax checking) for these languages into a standalone GUI application? I plan on creating GUI editors for them, but they won't be traditional text editors. I expect some folks to use a traditional text-based approach, however. Perhaps bundling separate programs is the way to go… I already plan to (eventually) ship multiple applications.
This language is intended to describe game data for use with https://github.com/benknoble/frosthaven-manager. (Really, there is likely to be more than one language or sub-language for different kinds of data definitions. But I expect them to look mostly similar and co-operate in some way.) It thus needs to be easy to write (by non-programmers) and forgiving of mistakes (small changes in syntax should not lead to large semantic changes). My thoughts on this are unfortunately spread out, so jumping into details is probably difficult. But I do identify some major questions at the end.
Example programs might:
require
ing monster programs (this might even be extended to optionally including player information in the same way)These programs have no output or function other than to translate one data format into another readily useable by https://github.com/benknoble/frosthaven-manager.
Boardgamers, mostly. It thus needs to be easy to write (by non-programmers) and forgiving of mistakes (small changes in syntax should not lead to large semantic changes).
An example of the current monster database format is https://github.com/benknoble/frosthaven-manager/blob/c8ebf9e1b95a99687593c7d45a9c3e7a5b1e3c74/sample-db.rktd
Yes, I plan to implement this. I'm particularly interested in
Related issues:
Thematically related: https://cacm.acm.org/magazines/2012/1/144809-creating-languages-in-racket/fulltext