ludonarrative / storyassembler Goto Github PK
View Code? Open in Web Editor NEWStoryAssembler: a dynamic choice-based narrative generation engine
License: Other
StoryAssembler: a dynamic choice-based narrative generation engine
License: Other
This currently lives in Coordinator.getNextScene()
Right now you'd have to manually insert your logic in there on a per-project basis. It'd be better if:
Was expecting to see some cool dynamic story but instead got a dialog with "go left" or "go right" the end. Did I miss something here?
Refactor "wishlist" to "storySpec" and "wishlist items" (if it exists somewhere in code base) to "spec entry"
This would be good to manage having one-off characters that only appear for part of a scene, or removing characters when they leave / die / etc.
Currently, if you want to start a scene in timeline view, you have to make sure in the scene's config field "descriptionText" you have a link like this:
<a href='#' class='beginScene' id='begin-testScene2'>Begin Scene</a>
At the very least, we should only require that a link with 'beginScene' class is in it...setting the id of the scene to begin off the text value of the link's id (Display.js:606) is...horrible.
Template should be written as _link/1/
, which should display in that spot the display text of choice 1. Choice 1 should then be hidden from being shown, and all clickEvents registered to clicking that choice should instead fire when the hyperlink is clicked.
To reproduce:
In populateKnobs() when it checks length of wishlist for if (sceneSpec.wishlist[x].condition.includes("["))
the length is 19 but there's only 14 entries???
Timeline isn't accurate any longer (or as general) and can be confusing.
-Refactor name of view everywhere in code
-Change "year" to "scene label"
-Update documentation
(getStorySpec)
id
year
characters (dictionary with props "name", "nickname", "gender")
wishlist (array)
dataFiles (array)
startState (string array)
UIvars (obj array, props: varName, label, characters, affectedBy, range)
mode (obj, props: type, initiator, responder) -this might only be used when we say we want to label speakers and that's buggy???
(loadNoPathFallback)
id
text (fallback text to display if scene can't continue but we're in release mode)
(loadSceneIntro)
id
text (intro text for each scene)
(loadBackground)
id
src (location of background image for scene)
(loadAvatars)
sceneId
characters
-id
-graphics (which graphics pack to use)
-age (actually just used to delineate graphics pack)
-states (state conditions paired with avatars for those conditions)
we should probably get rid of graphics and age, and instead use an explicit "src" prop in states with the full filename
var setUISceneContent in Display.js is the function I'm primarily looking at...
...essentially it looks like a bunch of the timeline functions got mutated into graphView, then when graphView got ripped out it ripped out the stuff that made timeline stuff work.
Use the canonical version or go back in history of Display.js to figure out best way to re-factor this to preserve the stuff we want (shimmerText, possibly config knobs???) but not get all the other graph stuff.
In regular title screen mode, it shouldn't display all the scenes if you put it in release mode.
All the code is in there to route it correctly, we just don't mess with it. Update docs and tell people that setting it high can result in choices taking a long time, etc etc.
Currently there are lots of state variables from playthrough initialization (scenes, etc) that don't get cleared out or reset between scenes. We need to formalize our approach and add in that functionality (was custom-coded in Emma's Journey and then ripped out when we pulled the library out).
Currently textClickFuncs lives ~line 295 in Display.js, and contains all the click functions bound to shimmer wishlist text. Instead it should live in its own file.
We can keep the syntax of {shimmer|shimmerFunctionName|initialValue}
inline for scene descriptions...that's pretty good.
Possible names for more framing one:
frameworkDisplay.js
systemDisplay.js
pageDisplay.js
gameDisplay.js
Possible names for StoryAssembler's one:
storyDisplay.js
fragmentDisplay.js
pageDisplay.js
In Display.js, this line:
else if (nextScene == undefined)
needs the correct code to return to the main screen without weirdness.
Currently StoryAssembler picks the first item in the list of valid items returned, which makes it 100% deterministic (which is good for debugging).
Factor it out though, so it can be exposed as a scene config. It's an easy way to make the system way more dynamic.
Essentially deactivated for now (if not present in config, defaults to monologue, which doesn't really do anything currently) but there's a deactivated StoryAssembler to automatically pick fragments based on who the speaker is as well. This feature was implemented back in...2017? 2016? Then it was abandoned and drifted into "deactivation-by-code-never-executed" over time. It used to have three different modes (narration, monologue, dialogue) and would prioritize fragments that allowed the normal exchange to continue.
Currently you'd need to add
"mode" : { //what mode dialogue exchange takes place in for the scene
"type": "dialogue", //can be dialogue or monologue
"initiator": "friend1",
"responder": "protagonist"
},
to your config file, and make sure each fragment has a speaker.
This could probably also come back integrated in with the avatar stuff, as that seems to be where a lot of character logic-y stuff is now.
Currently hacked into Display.js, but render should be changed from returning just a string to returning
{ text: "some text", onClicks: [{id:"span1", onClick:function deedle() } ] }
and then appending the onClick functions to a placeholder in processTemplate().
Then at the very end, it should by default replace the text with .text property, but should check for onClicks and if the array has stuff, cycle through searching and add them to the elements?
Right now there are a lot of straggling localstorage/State keys that aren't being used. Once we split out the repo, need to remove the chaff.
The whole "mapping a json file to a string alias and then putting that alias in an array of strings at the top of Coordinator in the proper order" is a total nightmare.
We might be able to do away with this and re-factor it using ES6 classes (probably most hygienic way?)
Key requirements:
Currently there are two approaches:
Display.createKnobs() : makes HTML elements (sliders)
Display.populateKnobs() : actually put in values and binder functions based on dynamic wishlist DSL
Display.processWishlistSettings() : process knob values and do string replacements on dynamic wishlist items
Display.createShimmers() : makes HTML elements (shimmerSpan) and sets values in localStorage
Display.processWishlistShimmers() : takes localStorage values and does string replacements on dynamic wishlist items
I propose that we should re-factor so that we use a #2 approach, and for #1 roll createKnobs() and populateKnobs() together into createKnobs(), and change their function so that they're writing to localStorage. Then we use processWishlistShimmers() approach for finalizing in both cases. This way we can demonstrate two UI approaches to hooking into dynamic wishlists.
We need to further separate (MVC-style) the module dependencies so that all the stuff specific to our displays is done independently of the data structures of Coordinator, etc.
Ideally, it should probably go like:
Use cases we need to handle:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.