For activating new current node and deactivating its parent.

Could be used later for presenting the newly activated node's body text

So much simpler (and type-safer) than the current "select any GameObject in your hierarchy".

It'd be great to have a generic GUI function like this which draws a checkbox dropdown menu and returns the value selected.

  static Value GUICheckbox(Value[] options)

That way we could reuse this across lots of our components.

Refactor player onGUI method the handle interactions and annotations separately, as well as change how prompts work

General menu system for switching between scenes.

What happens if you add multiple interactions to an item? Are there multiple prompts?

You can use a TriggerInteraction to do multiple interactions nicely, but that might not be a user's first intuition.

That way, we can turn on the next Twine node in a story and have that node disable its parent.

Currently, there is not much scaffolding or support for area based interactions. This needs to be created.

Player Area Annotations Property

FirstPersonInteractor.areaAnnotationsInRange must be coordinated and set by appropriate area annotations as the player enters and exits their bounding boxes.

Note: Implementing Player.drawToolbar(annotations) is blocked by this task. This can be implemented separately (as in, will be separated into its own Git issue), but relies on FirstPersonInteractor.areaAnnotationsInRange being set.

We should start deleting old branches after they've been merged into master.

No need to keep a bunch of these around...

The wiki page needs to be finished. I'll finish this sometime soon.

Fix the size of the GUI, etc

This issue is somewhat blocked by issue #67, which will setup Player.areaAnnotationsInRange is populated.

However, we can still implement this, as long as dummy information is sent to Player.drawToolbar(annotations).

Player Toolbar

The player will automatically draw a toolbar with .areaAnnotationsInRange as its contents using drawToolbar(annotations). This function must be implemented.

We also need a good way to activate items in that toolbar...

SwivelInteraction rotates a bit off of what a proper door would.

(note from user demo)

This could raise some new issues or give us more ideas on what is good/bad about the Prairie workflow.

It will also give us a more interesting demo to show than the abstract game with spheres and cylinders! 🎮

(Note: this probably won't be a tutorial itself -- but it would help us see what steps need more documentation).

This prefab is far too important to not ship.

Could we add debug.drawray so the raycast is visible in the scene window?

https://docs.unity3d.com/ScriptReference/Debug.DrawRay.html

for easier import!

For example, suppose a user has a directory with a bunch of text files with names that match Game Objects. This importer would go through that folder and add each text file to an annotation about the Game Object that matches the name of the text file.

This is pretty brittle (changing names of objects would stop the importer from working). We need to discuss this further and think about how it would work.

This might be more intuitive than having the user add multiple interactions for each potential Twine node.

Does TwineJson not work for large Twine stories? Can we fix it somehow?

Let's find out.

If the "prompt" variable in FirstPersonInteractor were the empty string "", instead of "Press F to", changing the "prompt" within an interaction script could directly change the GUI box on screen (helpful for when interacting with an object changes the user's options i.e. Tumble, Swivel)

Make the inspector only show title, body text, and maybe a link to the parent / children.

The default one is trash. Let's make a better one (where you don't need to specify number of elements) and has simpler add and remove buttons.

It'd be great to have a generic GUI function like this which draws an Array UI Element, and returns the result.

  static class PrairieGUI
      static T[] list<T>(T[] elements) where T : Object

That way we could reuse this array UI element across lots of different of our components.

The Twine Status box has some strange behavior and funky margins on different large and small screen sizes.

When you enter a new TwineNode, it will open the TwineNode text GUI, but you can press some button to minimize it.

Right now, there are two main types of TwineNode interactions: area-based (e.g. entering a room), and click-based (e.g. clicking a light switch).

But there's a third type that shows up in some of the Workhouse Twine stories: the player can make a decision (without explicity doing anything in the space) that will change what options are presented to them.

For example, the player could wake up in the morning and decide to be rebellious that day by not doing their chores. This decision will affect their options later on, but the decision isn't made by entering a room or clicking anything.

To implement this, we could add a checkbox (or something similar) to a TwineNode interaction to indicate that it is a decision. Then, in the on-screen TwineNode HUD, we could display some text below the node's body text. The text could list all the possible child nodes and an associated key to press to activate them (i.e. "Press X to rebel by not doing your chores today").

Right now, the basic walkthrough tutorial assumes quite a bit of knowledge about Twine, Unity, and Prairie. We should emphasize that this tutorial is not meant to be the starting point for using Prairie (or, it could be the starting point, as long as it points to smaller tutorials for each concept it uses).

Also, we should re-do the GIFs and perhaps make them into small YouTube videos or GIFv / Gfycat clips. Perhaps a good option is to use Gfycat's Gif Brewery mac app to create GIFs that we can host on Gfycat and embed in the wiki with play/pause/fullscreen controls. (This is feedback from Austin after he looked at the tutorial).

Based on my demo, but maybe also with more interactions

There are some general structure tips for a Twine story to work best in Prairie (i.e. storing "variables" in your states, setting up states that result from clicking on things, etc).

There is also at least one tag that you can use to get some Prairie functionality: prairie_decision (see #91). So we should document this too.

The rest of the interactions don't have a verb-noun structure (like "Start Slideshow") so I think we should remove the verb from this interaction to keep it consistent with the others.

From user testing:

The surprise entrance of a Prompt component was confusing to some. Is there some way to make that more obvious? (or to fill in sensible defaults for prompts?)

This is apparently more difficult than I thought.

Will continue work.

I think all we need from Standard Assets is "Characters" (and its dependencies)?

We need a wiki page for linking Prairie to a Unity project.

Set up annotations to handle all three types of annotations (ignore toolbar of area annotations for now?)

(re: the Boston Massacre)

Annotation drawing Summary

Annotations must be given a summary field and draw it to screen (if it exists) inside of Annotation.DrawSummary().

Once this is implemented, it should auto-magic-ally be incorporated by FirstPersonInteractor. See #65 for information on the changes made to stub this function.

to just Annotation and Slideshow