The ensemble from ensemble-engine

Rule Editor: More Complex Controls

More complex controls, i.e. for types, change this to a text field that you can start typing in and it will auto-complete

Make "duration of 0" the way to specify "event", instead of the special keyterm "SocialRecordLabel" in validate.

Change Validate so that it isn’t the SocialRecordLabel nature of things that gets special treatment… and that duration of 0 is all that you need to specify events.

Rules "double dipping" by being run on multiple characters, boosting the volition for a single character each time.

If a condition for a ‘boost undirected’ predicate involves two people, both will increase the weight towards the boost. Bug or feature?

I believe this is how it worked in Prom Week

Cleaning up and commenting core code: Validate

This includes removing “comments to ourselves” that we no longer need.
Finish function API (the headers for all of the functions)
Go through all of the lingering TODOs in the code, determine if they are done (remove them) or represent actual lingering tasks (add them as issues)

Rule Editor: Advanced Controls

Advanced controls, maybe hidden until requested: temporal restrictions, separate out initiator/responder, more?

Add time-ordered rule functionality to tool.

Cleaning up and commenting core code: Volition

This includes removing “comments to ourselves” that we no longer need.
Finish function API (the headers for all of the functions)
Go through all of the lingering TODOs in the code, determine if they are done (remove them) or represent actual lingering tasks (add them to google doc)

Rule Editor: Full Keyboard Support

GUI for making schemata

"Synchronous XMLHttpRequest ... is deprecated" messages on the console.

“Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.” message in javascript console when loading up CiF -- change to asynchronous.

Switching the category of a predicate in the ensemble tool can lead to problems if they have different "min values"

Console: if you have one category with a min value of 0, make a new predicate with a value of 0, then SWITCH to to a new predicate with a higher min value (say, 3), tool will complain about an invalid predicate (0 is too small a value) and won’t let you switch to the new category!

Fancier version of Lovers and Rivals

A fancier version of Lovers and Rivals that uses jquery, require, etc.

Website

Create a website for Ensemble!

Probably by making a new repo under the ensemble-engine user and hosting via GitHub Pages.

Should serve as a good landing site for non-technical users. Should tell people, in general, about what it does and how it's used.

Think

If a journalist landed here, could they write an article about it?
If a game dev indie came wanting to use it for a game they're developing, would they know how?
If a games or generative narrative academic was trying to understand Ensemble from an AI, architectural, or theoretical point of view, could they easily understand how it works and how it relates to other systems?

Components

See also galaxykate's "Oops, I made an open-source art tool!" zine

Comparing Predicates in Social Record might include looking at predicates "it doesn't care about."

It’s super gross having to delete things from predicates like ‘timeEarliest’ and ‘timeLatest.’ Maybe make the sfdb just not look at fields it doesn’t care bout.

Directed/Reciprocal types should be written so that predicate-to-english sounds sensible

As an eventual style guide thing, directed/reciprocal types should always be written such that CharA is CharB reads sensibly. This is usually the case now (i.e. “angry at,” “dating”) but not always, making some predicateToEnglish calls inconsistent. (i.e. “Bob is dating Chuck”, “Bob is friends Chuck”. friends should be called “friends with” for consistency.)

It might be that authoring social schemas requires more tools for specifying how natural language should be realized. i.e. {“hates”, “hates”, “hated”}, {“friends”, “is friends with”, “was friends with”}. Although this is tricky if these need to vary for types within a schema: makes the creation format more complicated.

Verify Rule-Type-Switching Problem isn't a problem

Before Pulling Aaron's recent amazing authoring tool changes, I realized that I had some changes to the authoring tool committed locally that I hadn't pushed to the repo yet. One of them included the following commit message:

"Fixed a bug in the authoring tool that was changing the 'type' of rule files from trigger to volition if the editor switched back and forth in a single editing session."

To ease the merging process, I stashed my changes and simply did a pull. It's possible that in Aaron's refactoring he addressed the issue that I fixed in my local commit. But it should be verified that this is the case. If it isn't, a new issue to fix it should be created.

Should Unspecified Roles in the preconditions of a rule assume 'anyone'?

if a role isn’t specified in the preconditions on a rule have it assume ‘anyone’?

Wait, does it do this already? See Yarn rule ‘kind looking people are more likely to be trusted” -- there is a role only specified in effects and it seems to work. Maybe volitions and actions are different in this way? Should double check.

Er, just double tested with exact same situation above and seems to not work? See two similar rules in testVolitionRules: “"A trusting person is more likely to give trust." did work, but "Someone with a kind face seems trustworthy." did not. The difference between these is one is a ‘condition on initiator->all responders” and the other is a “all initiators->condition on responder. The former worked, the latter didn’t. Maybe this is what is happening here?

Speed profiling / optimization

Allow social schema categories to be "exclusive" (only one value possible at a time)

Possible extension: Add a new specification field "exclusive" for a social schema category, i.e. for a quality that a character could only ever have one of at a time. Example: current location, character type, etc. When a new value is registered in Ensemble, any old values are unset.

This is more complex for directed categories. I.e. does this field mean character X can only ever have one entry of this type, or only one entry per unique character Y? Similarly for reciprocal: does it mean both characters cannot have another item of this category?

(One could make the case that this kind of behavior ought to be up to authors, and in many cases is unnecessarily limiting. I.e. making "relationship" exclusive assumes no nonmonogamous relationships, making "character class" assumes no multiclassing, etc.)

Ensemble.get functionality to fetch the history of a particular character.

References to cif.get should likely be ensemble.get

New “get” option: get “history” Right now cif.get() returns the ‘current state’ of the sfdb, but there might be times when you are interested in seeing the history of a particular character. It looks like we don’t currently have the means to fetch that? It would be nice if we did!

Rule Editor: Add Reciprocal Button

An "add reciprocal" button for volition effects: if you click for a rule that increases desire to start dating, adds a new rule that decreases desire to stop dating.

Console: Deleting a rule should automatically make it no longer the "active rule"

Console: in ruleEditor line 110 (delete rule) (this was the line number at the time of initially writing this, is likely very different now) -- deleting the rule should probably make the deleted rule no longer the active rule.

Cleaning up and commenting core code: RuleLibrary

This includes removing “comments to ourselves” that we no longer need.
Finish function API (the headers for all of the functions)
Go through all of the lingering TODOs in the code, determine if they are done (remove them) or represent actual lingering tasks (add them to google doc)

Update/clean Yarn schema to be a standard example schema

The ‘yarn’ schemata in the schemata folder has ‘cloneEachTimeStep’ - confirm that that should be changed to duration = 0, and then change it.

Support multiple ensemble instances at once.

Refactor to support multiple Ensemble instances at once. Start w/a command like var world = ensemble.newWorld() and then have independent SocialRecords, rules, etc.

Make Actions Still return something interesting if there are no valid terminals.

Functionality to make it so that even if you don’t get to a terminal in an action, you still see how far you got (i.e., oh, you didn’t get to askoutTerminal1, but you DID get to AskOut, let’s do something special for that, too!)

Refactor out library dependencies

Refactor out library dependencies, if possible. util.js, jQuery. Possibly underscore? Can duplicate most useful functions within a cifUtils module if needed.

Time ordered rules: change the way they identify changes to the social state?

Potentially Revisit: Do we want to change the way that ‘ordered’ rules work to look for ‘changes’ in the social state, rather than the state itself (what does that mean when only looking at a single timestep? Or when looking at the first time step in a range?)

GUI for making actions

Cleaning up and commenting core code: SFDB

This includes removing “comments to ourselves” that we no longer need.
Finish function API (the headers for all of the functions)
Go through all of the lingering TODOs in the code, determine if they are done (remove them) or represent actual lingering tasks (add them to google doc)

Design Tool adds "value" attributes to volition rule effects, which should not be present.

In the Effects of a volition rule, there… shouldn’t ever be something with a ‘value’ attribute defined. This causes unhappy discrepancies/mismatches. In the validating process of volition rules we should check for that and raise a flag if there is an issue. (Apparently the DESIGN TOOL adds this. Remove it from the design tool?)

cleaning up and commenting core code: Ensemble

This includes removing “comments to ourselves” that we no longer need.
Finish function API (the headers for all of the functions)
Go through all of the lingering TODOs in the code, determine if they are done (remove them) or represent actual lingering tasks (add them to google doc)

Module Loading Solution

Research: decide whether to stick with Require or switch to some other system for module loading (CommonJS, other alternatives? maybe we don’t even want a module system, just attach everything to a single global variable “ENSEMBLE”?)

Debugging/Tracing Solutions

Debugging/tracing. We have some stuff hacked in for Yarn, but what’s the best long-term solution? That won’t slow down normal execution? (Priority level?)
JS equivalent of “signals”? Much faster than events.

Enforce that all "types" across all "categories" are unique

When loading a schema, should enforce that all “types” across all categories are unique. (I.e., you can’t have a relationship “friends” and a status “friends.”) This assumption makes parsing console commands easier, and is probably a good best practice to avoid potentially confusing problems.

Console: Switching between volition and trigger rule tabs sometimes cause files to be re-written incorrectly.

Console: Display bug (which sometimes yields an actual bug). Set up: A schema that has volition file defined, but no trigger file. Click Rule Viewer tab, make a new volition rule by clicking new volition rule button. this takes you to rule editor tab. Without clicking “update rule” go back to rule viewer tab. Now click on the trigger rule tab, and then click make a new trigger rule button. When the dialog comes up to name the trigger file, click cancel. A rule appears to show up in the trigger list, with the same file name as the volition file (but cannot be clicked on, indicating display bug). HOWEVER sometimes (I cannot reliably recreate this) it does seem to save “over” the file (turning your volition file into a trigger file, and eliminating all rules from it except the rule that was appearing as a display bug).

"Xmlhttp not read" messages on the developer console when starting ensemble.

“xmlhttp not ready!” messages when initializing ensemble in a sample game are scary, but seem to not be problematic. Just remove them? Or fix them?

Add an “isInitiator” field to volition rules

Add an “isInitiator” field to volition rules with three potential values:
“initiatior” means that the rule pertains to a character wanting to engage in an action.
“responder” means that the rule pertains to a character determining if they will accept or reject the action if it is done to them.
“both” means that it affects both the initiator and the responder, as outlined above.

When the effect of a rule involves two roles, but the condition doesn't have two separate roles.

Console: If you are writing an effect that involves two people, but the condition doesn’t have two separate roles specified, the effect that involves multiple people won’t display the second role properly. This is actually probably desirable behavior, but even if you do add the additional role in the conditions, the effects won’t update until you’ve fiddled around with it (e.g., switch the category and back)

Tool Documentation

Ensemble.set example in 'basic' tutorial

Add an ensemble.set example in the ‘basic’ tutorial that already exists (the one that talks about your game loop).

Examples of writing rules that cover classes of actions.

(i.e. if Bob is in love with Chuck he is more likely to take all positive actions towards him)

"Reverse volitions" don't always work for determining if an action should be accepted

"Reverse volitions" don't always work for determining if something should be accepted.

Here's an example:

Consider volitions between a character who is ‘arrogant’ and a character who is sycophantic. Sycophant has high volition to praise arrogance. Arrogance has low volition to praise sycophant. ---> Does this mean that Arrogant is likely to refuse praise! I think so, but that doesn’t seem right!

This should be addressed somehow.

Console: Too many backup files being generated.

Console: When you make a new file for rules (say, trigger), and then you load to a new schema, and then make another new file for rules (say trigger), and then save, it will save backups of BOTH files: solution -- when you loadSchema/ call init in ruleEditor, clear our the ‘backup’ cache?

GUI for making characters

Rule editor volition values use named ranges and are validated.

Volition weights also needs to be a validated text entry (like numeric conditions)

In 'time ordered' rules, make it so that you specify not only the order, but also the duration.

special field in ‘order’ predicates to enable the case of “Bob and Jane were dating for 50 turns continuously, but then they broke up, how tragic.”

Make sure that the "Load Schema" button in the tool actually works

Make sure that the ‘load schema’ button in the tool actually works (seems like you have to refresh and pick a new thing. Just pushing the button and choosing a new thing does nothing?)

Keep context/local history of the traversal down a tree; context lasts longer than a single action.

Keep around context/local history of the traversal down a tree (SocialGameContext from IMMERSE) -- context that lasts a little longer than a single action.
e.g., Not just a quest, but a quest chain!

Rework predicateToEnglish to use printed character names instead of IDs.

Some difficulties:
predicateToEnglish is in RuleLibrary, which does not have access to CiF.getCharactersWithMetadata (needed to extract printed names from char ids). Would need to either a) register character names with ruleLibrary at the time they are set/updated, or b) add in a way for RuleLibrary to access CiF functions.

Need to make sure this isn’t going to screw up anything that needs to extract the character ID from a “predicateToEnglish” result and use it elsewhere. I don’t think anything requires this right now (and if it does, it should be changed) but should double-check.

ensemble-engine / ensemble Goto Github PK

ensemble's People

Contributors

Stargazers

Watchers

Forkers

ensemble's Issues

Recommend Projects

Recommend Topics

Recommend Org