Home

Welcome to the sashimi wiki!

A small "roadmap" of sorts for different areas of work.

Engine Improvements:

• Add movement room to room.
  • Implement: "Instead of going nowhere" for the sample story.
  • Note: "unvisited" changing to "visited" needs to be supported.
• Add support for: doors, locked and unlocked.
• Add Conversation support.
• Add action pre-conditions, filters, and likelihood. This should help provide more realistic menus: ex. no "open" on a "closed" container; "Kissing" is more likely to appear near the front of a list for an "actor"; etc.
• To improve godoc, separate the "script" package into public api, and a sub "internals" package.
• Scenes.
• Fixup ugly names in the existing class hierarchy.

Model and Table Work:

• Compare and contrast current model access with go,java,something introspection.
• Create tables for models; save/load tables.
  • Note: the model currently use raw pointers, but that may need to be changed.There's a conflict that i would both like the model to be add-able to from outside sources, and yet complete "solid" -- no broken,trailing references -- whenever its built; and that the modal from the perspective of Go is "readonly".
• Implement relations with value. This would support exclusive ownership rules -- room, container, supporter, inventory, wearing, holding -- all via the same table. )
• Remove the need for a server to compile the game each session; fix the fact relations change the "archetypal modal".
• Minor: move StringId from "model" package to "id" package
• Considering sharing a single interface to set values in the model. A "set once" for the compiler, and a "reflect to template table" for the runtime. Perhaps the code data structures could be shared, and that underlying object/map could be passed out of the compiler and into the runtime.
• Consider supporting external table data.The script would define the schema, The compiler, possibly by specifying the source in the script, would merge that data into the db. It's possible the "script" layer could use that table api to model property by value relations.
• Add save and load for the runtime.

Web Mockup Improvements:

• Implement a structured text, report, response interface to hide the auto-generated "look" description text.
  • TBD: What about "brief" text: "In one corner of the room, a large aquarium bubbles in menacing fashion."
  • Investigate making room names itself be a response to support highlighting, clickablity. ( The client could decide what to do with each response type. )
  • Revisit room content listing; take a look at Inform7's activity.
• Add action filtering, pre-conditions mabye, categories to actions? ( ex. to hide print default parent; could also do this by simply not having an icon associated with it )
• Templates should be re-implemented using Mustache so they can expand on the client when they need to. (ex. Tooltip text, clickable descriptions. )
• Support for app engine:
  • Host multiple story files in memory simultaneously; Revist the use of init().
  • Runtime values should push and pull changes via an interface; this would be a great time to fix up relationships which currently change the model.
  • Cookies to save a user's session.
  • Instigate using https://github.com/elazarl/go-bindata-assetfs to bin up the html and javascript into a solid executable.
  • Improve unit tests around frame numbers, race conditions, and out of order data.

Rule Fixes and Improvements:

• FIX: sushi's "Search cloths" can happen with the cabinet closed.
• FIX: sushi's "Close aquarium" doesn't produce a message; in fact there are several actions which don't print responses.
• FIX: what should searching a container do?
• Clothing: Actions and rules for take on/off, etc.
• Rule followup: Ensure pickup rule for "fixed-in-place" works.
• Rule followup: Ensure brief and handled work as expected.
• Consider making "Player" a global variable layer to allow shifts in perspectives. Use the parser push to vary the action source dynamically.

Experiments:

• A way to pass parameters to game events.
• Micro state-machines: behavior ( scripts, event sets ) separated from the properties, and data of a state itself. Note: interestingly, the Inform supports that objects don't have to be a container to be openable. As long as something has a compatible set of properties ( interface ) it works.
• Path finding over relations ( esp. for rooms )
• Experiment with extracting callback snippets using AST and save them to the db as document entries. Implement some sort of go tool which compiles from the db back into go code.
• Experiment with json-ex for saving and running callbacks in javascript.
• Investigate "reverse templating" for running script commands. For example: Go("set the initial $player position to the $room").

Constraint based compilation:

• Implement type ratcheting to allowing the same instance to be defined as using multiple, but non-conflicting classes. For example, the two statements "the table is an object", and "the table is a supporter" are non-conflicting.
• Add type susing using default property values.

Scripting Improvements:

• Dependency injection for script callbacks.

• Remove The("action.source") which is fragile, and hard to remember.

• Add support for class default values. ( ex. implement always, usually, or initially? for text and num. ) Simplify the templates that work around this, for instance the story headlines.

• Consider using one global namespace for "scripting" and "callbacks" packages; a shim which calls the correct underlying package based on context.

• Consider switching to property variants. There was some thought this would clean up some of the property management; It would also enable possessives:

    The("card's supporter") => variant
    The("table's supported objects").List()
    The("card's supporter").Object()
    The("card's description").Text()
  

• Lists of objects need full support.

• Allow the definition of events without associated actions.

• The "rotating" event definitions are really confusing, as is the source/target/context muck up. Find a way to fix this up. ( See for example: "showing it to" .)

• Allow new constraints to be added to sub-classes. For example, possibly: The("containers", Called("canisters"), AreUsually("opaque"))

• Allow template parameterization using local variables. ( Maybe look at this as part of mustache support? )

• A more terse "report" syntax would sure be nice. ( See for example "report already open" )

• Add support for user defined global variables.

• Consider supporting adding instance properties without classes: ex. "The fish food can be found or hidden". ( I have mixed feelings still. Even though inform supports this, it seems easy to cause bad behavior. )

• Delegate the parser's behavior to the script via callback(s) in someway? noun callbacks on the parser spec, and requires(enclosure), Can("listen").And("listening").RequiresNothing(), //.RequiresOne("actor"),

• Use "Understandings" to reference objects during scripting ( ex. "the fish" instead of always "the evil fish" )

• Minor: add an "Or", to allow reuse of event handlers. For instance: When("searching").Always(giveFood), When("looking under").Always(giveFood).

• Minor: until type-sussing works, simplifying prop declaration would be nice. For example, maybe: The("props", Called("telegram", "bouquet", ...).

Improve IF Playability:

• Add parser disambiguation states: Which do you mean, the evil ring or the nice ring?
• Add "take all", and other such standard commands.
• Add support for real short names and long names.
• Support in/definite/article printing: some, a, the.
• Support correct capitalization of nouns, especially at the start of sentences.
• Distance matching for nouns both by the parser and at compile time.
• Replace current pluralization code with the Clayton pluralization algorithm.
• Add support for bold, italic, and colored text, possibly by using embedded codes or filters in the text.
• Continuous time control embedded in text. ( Why print "beat", when you could actually have a ... beat. )

Misc.

• Determine whether the examples run on Windows.
• Help command to list all commands
• Support for a script based "test me" command. It would be nice to test the game output and states with some simple expectation statements.
• Add unit tests for the event package and its dispatch; event bubbling, capturing, listening, removing, etc.
• Refactor the "runtime" package. It's iky in there.