Open joshuaauerbachwatson opened 1 year ago
would require dynamic loading of user-provided code (or a DSL and an interpreter for it).
Just noting that iOS developer / distribution rules would preclude dynamic loading of user-provided code. Any code that executes as part of the app has to go through the review process. So, only the DSL / interpreter approach could fly in this context. I am guessing that we could go far with just a simple declarative system in which you declare how the art is laid out and then common code, distributed with the app, would do the actual cutting. But, that seems like a lot of work, compared to just providing more than one source deck (with distinct art), with the ability to extend this aspect of the game reserved for the developer.
The
PlayingDeckTemplate
class and theDecks
class with the available named decks are bothCodable
but we don't make use of that right now. So, the repertoire of named decks that is compiled into the app isn't extensible. The compiled-in list could easily be replaced by a managed file containing the same information in JSON format. We could then add user interaction support for modifying the file, which would allow users to define their own playing decks.A related idea that is out of scope for the moment is to allow users to provide their own
SourceDeck
implementations with accompanying graphic art. That is harder because the logic to understand the art and "cut" it into individual images for cards will vary depending on the art, so would require dynamic loading of user-provided code (or a DSL and an interpreter for it).A more limited "tailoring" option is if the game itself had more than one source deck (with distinct art) or at least the choice of some different card backs.
As even the customization of playing decks will require the addition of dialogs, this work will likely be deferred for a while.