WISHLIST: Most wanted features…

[tmedwards]

What features would you most like to see in, or not see in, SugarCube v3?

You're not limited to a single item, so feel free to go nuts.

NOTE: This is a community wishlist, not a promise to add or remove anything.

[ChapelR]

I see there's an issue for stateful audio, which is a good idea. What are your thoughts on moving to the Web Audio API for things like gapless loops?

[tmedwards]

There's no issue on the tracker for it currently, but it's something that I'd like to do.

The Web Audio API has matured, settled, and is well supported at this point, so using it today is no longer like trying to slam dance through a minefield.

[tmedwards]

Users have always been able to create macro aliases, but it would be nice if that capability were easier to access or, at least, more exposed.

For example, in v2 (and v3) you can do the following:

Macro.add('la', 'linkappend');

I propose a macro that provides access to the feature as well, e.g., something like <<alias>>.

For example:

<<alias "la" "linkappend">>

[RynGM]

I like Sugarcube 2 a lot, so it's hard for me to think of anything. I don't think it's missing anything crucial. So I'll I'll try to list out quality of life things. None of this may be possible - or there may be solutions already - but I figure it doesn't hurt to raise it.

Audio

I'm running some Javascript you kindly provided for handling BGM and sound (thanks for that!). Audio is one of the areas I bump heads with, particularly when it comes to projects stopping or starting.

I guess some things I'd be interested in would be expansions to these audio features, like:

• Support for multiple looped tracks that are remembered when you save, and if you set both to loop, both tracks resume playing in said loop when you load a game. That way you can layer something like a BGM and a windstorm track, and be assured players will continue to experience that when they resume play.
• Some way to run an IF statement on what audio is currently playing, so you can decide to stop that audio using conditional logic.
• When you're using Itch.io and you leave mid game by just existing, gameplay takes up where you left off but the audio doesn't. This means there's silence until the next audio event.

Delayed Text

Again, an area I'm using some JS which you awesomely provided. This is an area I spend a lot of time in. Currently I mark off each sentence with a delayed class, so each sentence appears in a staggered way. This can be time-consuming with longer projects.

Again, not sure if this is possible, but maybe if there some way to mark a passage with a tag, and it applies delayed text to that passage - either per sentence or per character (Not sure how it would figure out the length of a sentence, though, so maybe not). I guess I'm just asking for more innate support for playing around with delayed text.

That's all I've got for now - I'll post again if I can think of anything else.

[RynGM]

Thought of another one! If in Debug mode there was a text box to type in a passage to jump to for debugging, that would help a lot. Currently, it involves having to go to the console with a few clicks and then remember the long command I need to enter to get me to a passage. This can be time consuming when testing something something over and over again.

[HiEv]

Yeah, I wouldn't mind if some of the functions in my "Music" sample code were obsoleted by being included in SugarCube v3. Such as the TrackExists() function, to determine if a track is loaded yet, the isPlaying() function, to determine if some music track is already playing, a function like the <<PlayTrack>> widget, which you could give a track to play and it wouldn't restart the track if it was already playing, a built-in volume slider and mute button, etc.

Basically, make it a lot easier to automatically resume the music on the track it left off on when reloading a save.

That said, IMHO, delayed text is an idea that developers seem to think is fun or interesting, but players hate. So I'd be cool with not implementing that, or at least making it "fast-forwardable", so that players can skip the delay with a keypress or a settings toggle.

[ChapelR]

I think audio state is one of the issues! Hopefully that includes everything you mentioned.

Agree that native support for player-skippable delayed text with configurable animations would be awesome as a core feature.

[ArdiGame]

Support for swipe touch gesture for sidebar for better mobile usability.

[ChapelR]

I think the sidebar is going away, but if it does make it in, in some form, I agree.

[tmedwards]

I think the sidebar is going away […]

Not going away, just becoming user centric.

And yes, this is a good idea.

[brushmen]

I wish for a more elegant way to modify the currently immutable passages array, so that hasVisited() can be more easily simulated during a testing situation. I don't currently use save files to do later-story testing because it still takes "too long" to make little tweaks here and there (ie I have "too many" variables to track for a choice-heavy IF) to said save files.

So I have considered making a duplicate visited() function that does the same thing as hasVisited() but looks through a mutable array of passages (that I track of in passagedone), but that's another array (smaller if I don't count duplicate passage visits). I would probably do that for when transfering game data from one game to another (like a sequel), but for a single game I wonder if there can be a more elegant way.

My current method is having a debug HUB passage jump to passages I want hasVisited() to register as true and have those passages have checks that send me back to the debug HUB where I can jump directly to later chapters of a story to do testing on that chapter alone. This ad hoc method looks really messy, and I wish I can keep related debugging code just inside the debug HUB, set passage visit to true like I can set flag variables to true.

Thank you! 😇

[BawdyInkSlinger]

I also want this

[HiEv]

Saves should (optionally?) include the current variable values, instead of just the values that the passage had when you entered it, if there have been any changes to the story or temporary values. That data would be stored in the save file as an "extra" bit of information, not included in or changing the passage history.

Thus, loading would probably need two extra steps, where it would load the passage with the data you had when you entered the passage, then it would update those variables to match what they were when the game was saved, then the passage would execute (allowing it to display those changed values), and then it would update those variables again to match what they were when the game was saved (in case the passage execution changed any of the variables). (Perhaps make those two updates into A, B, or A+B options?) That should make the page display as it was when saved (in most cases, though admittedly not all cases) as well as the variables having the same values as when saved.

As an example, think about saving during a character creation screen. Most people would assume that they could design their character, save, and then if they reloaded, they'd be back at the same point they were when they saved. As it is currently, by default they'd be back to the defaults on that character creation screen if they reloaded the save.

For another idea, how about the ability to add "triggers" to story variables, so that the "trigger" code would be executed anytime that variable changes? Some code would need to be put in to detect infinite loops (when two or more variables keep triggering each other), but triggers would remove the need to put widget/macro/function calls after changing certain variables which then always need to update something else (like health bars and such) or allow variables to automatically "clamp" themselves to within certain value ranges. The "trigger" function would receive the variable name, the old value, and the new value, and if a value was returned by the function, then that variable would be set to the returned value, instead of the new value (essentially acting like a "getter").

You might also want the ability to "pause" and "unpause" individual triggers, for cases where they're going to be updated repeatedly in a short amount of time, and the "trigger" doesn't need to be called until the end. The "unpause" would activate the "trigger" if the value had changed since the "pause" was initiated.

[ChapelR]

I do think SC3 is going to support proxies so that can handle the trigger stuff.

I agree about save recording the current state as long as it isn't automatically loaded, recording it as an extra partial state like you suggest seems like a good way to go.

[tmedwards]

You're talking about restoring the state of the entire page, and that's not nearly as simple as you seem to be imagining.

To be clear, restoring the working variable state is easy—though requires bloating save again. That, however, is only one small part of properly restoring the state of the entire page, which is what you're really talking about.

Everything would have to become statefull: markup, macros (1st and 3rd party), any custom JavaScript running in the page, etc.

This is not a simple task.

[Amancham]

Not a programmer, but would it be possible (and probably easier) to add a warning if the condition (variables have been changed but will not be stored in the save) is true so that players know "Hold on, if I save now and leave, these changes will be lost"?

(Sorry, for unqualified comments, I am pretty new and wanted to just lurk, but this post caught my attention)

[ChapelR]

SugarCube should move to GitHub flavored markdown. I feel like this was discussed before, I just wanted to get it here to get it on the record and see what people's opinions are.

[HiEv]

While I could see the benefits, it seems like it would just destroy backwards compatibility in many cases and require that users relearn the markup syntax.

Probably not a good idea.

[ChapelR]

A major version switch is the time for ruining compatibility, if you're ever going to, and markdown syntax is a standard across the Internet, so many users are already familiar with it. I think the benefits of moving to a "real" dialect of markdown outweigh the short term pain.

[MinusGix]

I think that switching the entries in http://www.motoslave.net/sugarcube/2/docs/#markup-style , headings, and to the relatively more standard markup style would be a good idea.
I don't really see much point in changing the image syntax, but not really against it.

What I would be against is what some markdowns (ex: github, reddit) have: Double space at the end of a line or an extra newline to get an actual newline. This makes writing harder, and the line-continuation works quite well for when you want lines to fold. So, in my view, not folding (or whatever markdown calls it) by default seems to be the best option for writing.

[cyrusfirheir]

A way to run importScripts()ed code optionally from within SugarCube's scope. Will allow for separating code to sit outside the HTML, among other things.

[BawdyInkSlinger]

I think that would be great as a DRM feature too.

[cyrusfirheir]

@AcademyOfF DRM on a client side app would be sorta... what do you say... potato.

[BawdyInkSlinger]

couldn't you have the imported scripts on a server that require a username and password to get? I guess once you get them can be shared. That may not make it worth it

[greyelf]

The type of DRM you describe is fairly trivial for a knowledgeable person to overcome when they have complete access to the source code of a locally run Twine Story HTML file, and once that person has bypassed/disabled the DRM they can share it on web-sites that are specifically setup for sharing such content.

To achieve any sort of serious DRM you would need to store more than just the "imported scripts" on a secure server, like the contents of the Passages themselves. This is how standard web-apps work, the data they display/update is stored on a secure server, and all end-user based updates (like variables) are validated there before they are persisted. And this client-server model isn't current a part of any of the main story format.

[BawdyInkSlinger]

what I would not like in version 3 are any passages that swallow output. Even if you should never have output on certain passages, swallowing output can cause some difficult to troubleshoot bugs.

[BawdyInkSlinger]

alternatively, I'd want those passages to throw errors if there is any nonwhite space output from them.

[ChapelR]

I believe silent code is still visible in debug mode.

[ChapelR]

Move special passages to tags.

Like StoryInit —> init tag
PassageReady —> ready tag

The benefits are numerous:

1. Easily have multiples of special passages without needing to use includes.
2. Libraries or examples can freely use these special passage features without as much concern about conflicts.
3. I think tags are in general a better and more sensible fit for this kind of usage.
4. Special passages as they exist now can be a compiler-specific feature. This reduces the risk of collisions (though since we have a spec for twee, this is a minor concern).

I'd be okay with deprecating old special passages instead of outright removal.

[tmedwards]

The problem with this idea is the same reason Twine 2 dropped the script and stylesheet tags in favor of the singular Story JavaScript and Story Stylesheet sections.

When you allow multiples of any passage that contains code where ordering might matter, then you're giving users an invisible footgun.

This was a consistent low level issue with Twine 1's script and stylesheet tags.

For a few specific replies:

1. Including other passages at least gives users control over ordering.
2. JS libraries are better off using events. Libraries consisting of markup and macros do rate some concern, but how many of the really are there.

This is not a no, I don't dislike the idea in general, but ordering issues aren't something I'm keen to inflict upon users again.

[ChapelR]

I didn't think of the ordering issue, I'll admit, but I do feel that alpha-numeric order, or really any consistent, documented order (not something I believe happened with Twine 1's tagged passages) could work, right?

You're right about libraries, but I still think it'd be an improvement for them to be available.

I'm a little more on the fence because the order thing is definitely an issue, but I'll keep thinking about solutions because I'd prefer to have tags if we can think of a good way to do it.

[greyelf]

If more "special tags" are added to emulate specific Special Passage (and I like the idea of them) can their names be something less common than "init" or "ready", so there is less likely hood of a naming clash with end-user tag names.

[GwenTastic]

If you ask me ordering should be done in alpha-numeric order.
if that's not enough then maybe a way to overwrite it? maybe by (optionally) adding a number after a dash to indicate an index and any non indexed ones get loaded afterwards.
or maybe some Config.initLoadOrder = ["Passage 1", "Passage 2"]; as a possible overwrite.
i think there are many ways to resolve the order issue, iirc TweeGo also usually ends up using the alpha-numeric ordering because that's pretty much how the OS end up feeding it the files.

[Lavorther]

Not sure if this is feasible or something that should be added on the story format level in the first place, but maybe some buttons on the sidebar (or somewhere else) to in/decrease base font size of the passages? I've heard multiple people write their own implementations for it, and it's a nice thing to support out of the box from an accessibility perspective. Maybe also have one or more options related to it in the Config API, for example to disable it, or to specify the font sizes it should use, etc.

[ChapelR]

One potential issue with a one-size fits all solution is that a lot of layouts use em/rem measurements to be responsive, which scales based on font size, so if it's implemented at the format level, it may be hard for users to take advantage of. That said, as long as the option to turn it off and/or configure it your own way (e.g. targeting only the passage area for the changed font size, instead of the whole doc or the body), then it probably won't hurt anything.

This might also be a case where a cookbook or docs example might make more sense. We can at least do something like that for SC2 in the meantime.

[tmedwards]

IME, this idea generally comes in two flavors:

1. I want all fonts and/or the entire page to be bigger/smaller.
2. I want the main play font(s) to be bigger/smaller.

The former scenario is generally better handled by zoom tools—browser, system, or 3rd-party. The latter scenario is, literally, one of the things that the Setting API was made to handle.

I, generally, do not suggest an infinite adjustment—e.g., +/- buttons—because that almost never works out in the end. If you need something like that, then you're almost always better using zoom.

Anyway, continuing on with the latter. My usual suggestion is to use a list, but a range would work too. In either case, simply supply a range of sizes relative to the default size—e.g., -4, -2, 0, +2, +4. There's no example of this in the docs, because, as Chapel pointed out, there's no one-size-fits-all solution—especially considering user CSS—but I could add something basic.

Related SCv3 Specifics

• The default font size is now a bit bigger (16px → 18px).
• I'm slowly moving various default thematic settings—e.g., colors, font sizes, etc.—over to custom properties, so making basic thematic changes should be easier (see: https://github.com/tmedwards/sugarcube-3/blob/pre-alpha/src/css/global.css).

[tmedwards]

NOTE: Both examples adjust the global font size, which may or may not be wise depending on the project.

One possible example for SCv3 (currently works)

var fontAdjNames = ['-4', '-2', '(default)', '+2', '+4'];
var fontAdjHandler = function () {
	var $html = $('html');

	if (settings.fontAdj === '(default)') {
		$html.removeAttr('data-fontadj');
	}
	else {
		$html.attr('data-fontadj', settings.fontAdj);
	}
};
Setting.addList('fontAdj', {
	label    : 'Choose a font size.',
	list     : fontAdjNames,
	onInit   : fontAdjHandler,
	onChange : fontAdjHandler,
	default  : '(default)'
});

/* The default value of `--font-size-primus` is `18px`. */
:root[data-fontadj="-4"] {
	--font-size-primus: 14px;
}
:root[data-fontadj="-2"] {
	--font-size-primus: 16px;
}
:root[data-fontadj="+2"] {
	--font-size-primus: 20px;
}
:root[data-fontadj="+4"] {
	--font-size-primus: 22px;
}

One possible example for SCv2

var fontAdjNames = ['-2', '(default)', '+2', '+4', '+6'];
var fontAdjHandler = function () {
	var $html = $('html');

	if (settings.fontAdj === '(default)') {
		$html.removeAttr('data-fontadj');
	}
	else {
		$html.attr('data-fontadj', settings.fontAdj);
	}
};
Setting.addList('fontAdj', {
	label    : 'Choose a font size.',
	list     : fontAdjNames,
	onInit   : fontAdjHandler,
	onChange : fontAdjHandler,
	default  : '(default)'
});

/* The default value of `font-size` is `16px`. */
html[data-fontadj="-2"] {
	font-size: 14px;
}
html[data-fontadj="+2"] {
	font-size: 18px;
}
html[data-fontadj="+4"] {
	font-size: 20px;
}
html[data-fontadj="+6"] {
	font-size: 22px;
}

[greyelf]

The fact that the end-user may be using Accessibility tools to control default font family & size of the web-browser may need to be taken into consideration when implementing any sort of "story format level" control of font sizes.

[HiEv]

Rather than only having a fixed number of save slots, additionally have an option for an unrestricted number of save slots, where on the Save/Load screen you have the option to save as a new slot or overwrite/delete existing save slots on the save page, and it also shows the amount of save space remaining (and perhaps how much space a save would require?).

[MinusGix]

Been a while, and this is a bit late.

• If setup is still around, then make that more visible in the documentation to encourage writers to use it more. Likely showcase it nearby variables.
• Give setup its own sigil like normal variables and temporary variables. This makes it nicer to type, which really does matter when in the flow of writing text/code. I'm not certain of which to use, and I would greatly prefer it (in the sense of implementing support checks on it in T3LT) if it didn't use the existing $.
• Some form of basic enumeration support. This could be just a built-in macro, but the main goal is to encourage storing a number identifier that is then turned into the string rather than using strings for everything. I imagine this would help avoid some performance issues as projects get larger.
• As well, less reliance on javascript in certain places could make things nicer for analysis, but I can't think of any particular pain points at the moment, but I haven't had to look at it in a while.

[MinusGix]

This sub-comment will be explicitly about things that might make analysis a bit easier (through T3LT), it will be updated as I find more:

• References through strings are a cool concept but have the issue that in cases like <<textbox $name>> it isn't an uncommon mistake to write that instead of <<textbox "$name">>, but the former is also correct and is used so can't have an error mark against it.
  • Not sure how to resolve this so that the intent is clearer to the user and to the analysis. A custom syntax (bikeshed: $&name) would maybe help a bit (and allow some optimizations if you go for opaque references).

[MinusGix]

Minor List:

• I really like using asterisks for italics and bold, and would like if it could be used or was a available as an option. I rarely use the list markdown as well, so that wouldn't be be a problem.

[GwenTastic]

• I'm wondering if there could be an improved support for js classes.
  which basically comes down to removing the requirement of the .toJSON and .clone methods as part of the class definition, but at the same time i don't think that everything should automatically be saved in State/History, since there probably are benefits to classes that only exist in a single passage or only deal with some visual output.
  Tho i also faintly remember that there won't be a history.

• If the plan of using IndexedDB for save files haven't changed, i think it would be nice to have at least an API to create additional tables and columns in IndexedDB for in-story purposes.
  For example people could create their own Bestiary in it's own IndexedDB table separate from the Save file, or some Item/Enemy table that can be used to fetch objects/instances from which could be a good alternative to a "lookup table" with all elements inside a global object or function

[tmedwards]

As far as an actual default behavior. I doubt that's ever going to be a good idea considering the user base.

[GwenTastic]

The database isn't going to come preloaded, so you'd need to have the data on-hand in the first place, which defeats the purpose of the database.

i mean yeah, so does the in-memory lookup table too?
my initial thought was around the idea of being able to create tables upon "StoryInit" where the database also could get populated/seeded from, and potentially skipped if the table and/or data exists.
wasn't really thinking on having it fetch the data from the web.

[greyelf]

to create additional tables and columns in IndexedDB for in-story purposes.

How will the end-user delete these tables when they have finished with the Twine project that created them?

eg. Twine projects don't have the equivalent of an "uninstall" process, which non-Twine projects generally use to clean up any content they have created on the end-user's hard-drive.

[tmedwards]

I'm going to use game below to mean a Twine project: game, story, whatever.

i mean yeah, so does the in-memory lookup table too?

Not at all.

If you bundle the game data with the game, then it's already there in whatever form—presumably whatever's most useful. Loading it into a database from that point serves very little useful purpose.

If you're downloading the game data from a remote, then you still have to fetch it first. Again, loading it into a database from that point serves very little useful purpose. UNLESS a) the amount of data is large and b) it doesn't change often, in which case caching it in a database makes sense since you can avoid redownloading it on startup.

my initial thought was around the idea of being able to create tables upon "StoryInit" where the database also could get populated/seeded from, and potentially skipped if the table and/or data exists.

I get the idea. If I were to do it, then it would be part of SugarCube's JavaScript storage API. Thus, it would be usable even in the JavaScript section let alone StoryInit.

wasn't really thinking on having it fetch the data from the web.

Considering that's about the only scenario where it makes any sense at all—see the first section above—I honestly can't understand what you're thinking.

Databases are great when you need to perform various and sundry queries upon your data. IME, this is rarely the case with game data. I honestly can't conceive of a scenario at the moment where you a) have your game data and b) don't already know how it's best organized and used for your project.

[tmedwards]

I know I'm being a downer here, but I'm really not trying to be. I just don't see how this is truly useful for a Twine project.

Do you have a concrete example where pushing data you already have—since you said you weren't thinking of remote data—into a database would somehow be more useful than simply making use of said data directly?