Objects and identity:
Multiple copies of an object can exist, but all these copies are
semantically THE SAME object. Not a problem if the object is constant.
More problematic for objects which can be altered (i.e. child objects
added/removed) but it's OK as long as this limitation is explained.
There's not really any way around it while still supporting the nice
way of constructing/linking objects through the EDSL.
Could even be used to implement weird game features -- e.g. a
teleportation machine, or a bank, or whatever -- it could be in many
locations but still "the same" object.
This syntax:
require (foo) "message"
(do blah
blah
blah)
is bad, requires too many parens. It would be nice if we could just say
do require foo "message"
blah
blah
blah
i.e. like "guard". Make Adv a MonadPlus, with a "failure" mode of some
sort. should be pretty easy to do --> much nicer EDSL syntax!
Done!
Idea (3/7/08): Use ContT explicitly, and pass around two
continuations: one representing the "next thing" to be done
(allowing early exit from actions due to failed 'require's, and
another representing the "game exit" continuation. This way, all
the "stay/non-stay" stuff would be completely moot. A "stay" could
always be appended, but a "die" or "restart" or whatever could
always jump all the way out from however deeply they are nested.
Better idea (3/8/08): Create a custom monad transformer, sort of like
MaybeT except with FOUR constructors rather than two:
- Continue: normal, like 'Just' in MaybeT.
- Exit: computation should exit immediately. For use with 'die'
and so on.
- Fail: some requirement was not satisfied, so all subsequent
computation should be ignored; scope can be limited by a special
function to change 'Fail' into 'CondFail'. Note this function
does nothing to 'Exit' however.
- CondFail: A guarded conditional failure. When sequenced with >>=
acts just like Continue (). However, it can also be combined with
special orElse function, which chooses the first non-failing
condition.
Ideas for improvement:
* Per-object state, i.e. "properties". Something with Dynamic, perhaps?
(** v 0.1)
* Prompt monad for replay/testing/etc. (v 0.2+)
* Add 'scripting' capabilities for conversing with characters.
What should/could this look like? (v 0.2+)
* Configurable messages from the engine, along with library for
grammar stuff. (v 0.2+)
----------
Ideas for command-line parsing redo. Command-line parsing will now
return a custom data structure with as much parsing information as possible.
General principles:
* Keep as much information available as possible. Don't destroy any
information.
* Return lists of possibilities rather than arbitrary decisions.
* Put decisions in the hands of consumer code, providing as much support
for nice easy access to information as possible.
Keep original command line verbatim.
Next, lowercase everything, break into words.
Parse each word into a (String,[possibilities]) pair: original
(lowercased) word, along with a list of possible interpretations
(repurpose 'Comand' data type?)
- object, along with type (inventory, local, global)
- direction
Provide functions for extracting all of this information.