As I was playing with a sample story, it struck me that one of the things the author should be able to do is reference the current player by name so I added the ability to include "@PlayerName" in story text which is replaced in the reader with the player's name. After reviewing the in-game quests, there are probably a number of other variables that should be defined for quest text such as @Class (Hunter, Captain, etc.), @Race (Dwarf, Elf, Hobbit, Man), @Honorific (gender specific title, Sir or Ma'am), @Vocation (probably not @Profession since it would get complicated trying to determine which one to resolve to since we all have three unless we also add some limited form of scripting... although... code snippets might be a neat future feature, @Code{} where the function within the brackets is replaced by whatever it evaluates to...).

Any ideas for others? Specifically those we can easily determine from the API.

I should have a simple prototype available for testing soon (assuming mother nature is done playing cats cradle with out power lines) - there's a couple of things I found annoying in my alpha testing that I want to iron out first. Very limited functionality right now, but enough to give you an idea of the direction I am headed.

What distribution model did you decide upon for the stories? I think it's important to make it as easy as possible. Preferably not requiring users to unzip an archive into a certain place and type in its path.

The easiest I can think of, as I mentioned above, would be to distribute each story as a separate plugin (called, for example, "StoryLine - <story name>") so that they all appear as separate items in Plugin Compendium, and installing a new story is trivial. As a benefit, each story includes all the Lua code necessary to "run" it, so the user doesn't have to worry about updating the "player" plugin separately from the stories.

Another alternative would be to include all the stories in a single plugin that you maintain, such that when a new story is published, you update that plugin and people can update it with Plugin Compendium to see the new stories. Then you would have to oversee everything, like lunarwtr does for Plugin Compendium.

I can't think of anything else that would be useful (i.e. characteristics that an NPC should be able to "know" about a character as part of a story). The name/class issue actually crossed my mind at one point, and I immediately assumed that feature wouldn't be available, so that's awesome that you worked it out. It will be a nice touch.

Oh also, if a prototype will be ready soon, perhaps now would be a good time to decide on a name for the plugin. I'm not sure if "Storyline Plugin" is what you'd like to go with, I just couldn't think of anything better at the time. :)

I haven't decided yet. I agree that it should be as simple as possible since the idea is to get average people who may not be technically savvy to create stories. I don't care for packaging the player with the story, keeping the data and the player separate is beneficial for maintenance and updates plus the player is a fairly complex plugin in its own right. I do like the idea of distributing just a simple stub plugin, basically a wrapper around the data, just enough to allow importing it into the player - note, importing and saving the definition as a .plugindata file is helpful for things like tracking statuses and editing/copying but a stub would make it easy to import since available plugins can be searched programmatically so there'd be no need for the user to type in a path. Unfortunately, creating a plugin file as well as a .plugincompendium file may be beyond the capability of many. I've run into quite a few that don't know how to create a zip file :(

Initially, I am leaning toward something as simple as copy and paste. Allow the plugin to generate a text version of the definition that can be displayed for the user to copy and post anywhere. Other readers could then copy and paste it back into their client for import. Most users can handle copy and paste and parsing the text version could be fairly simple. One benefit of this mechanism is that it could be expanded to work with private chat channels so that the story definition could be sent via repetitive chat messages in-game - for a short enough story. One drawback is that it eliminates the ability to include images.

I'm definitely against the idea of a central repository that I would maintain - too many ways that can go wrong, for instance, I could get run over by a bus at which time everyone would be out of luck.

I'm not in favor of an external executable tool, but that would make packaging stories for publication much simpler.

Lots of pros and cons for all the methods so I'm still considering options.

FWIW, I've been wrestling with the issues of data Import/Export since ver 1.0 of IRV back in 2011. Due to limitations in the API I've never found a solution simpler than copy/paste :(

Yeah, and unfortunately a TextBox can only hold 64 kB of data, which isn't a lot for a story.

Keep in mind, you can make things a little more difficult for story authors than end users. If someone is motivated enough to make their own quest, they are probably willing to read and follow some directions on how to package the story into a plugin.

Making things as easy as possible for the end user should be the goal, to maximize usability for users who are neither technically savvy nor motivated.

Well, one nice thing about this plugin is it could be packaged with a single "story" that is a walkthrough on how to use it (or one for users, and one for writers). So if there's something you want to do that is slightly complicated, that might be a way of dealing with the issue.

I like the idea of copy/paste for the simplicity & safety, but I'm not sure if that will stop people from creating executable (I just really don't know). If that's going to be an issue, perhaps a single executable posted to Cnet, that adds any stories placed in a certain file might be an option. You guys would know the issues better than me though.

I've been using "Storybook" for the prototype but there's probably a better name (I liked Compendium but Lunarwtr has already used that. Twice :P ). Any other ideas?

Might I suggest the following names: Anthology, Analect, Omnibus, Treasury.

Don't know that I would ever author anything, but if someone created an interesting story arc I might use the plugin.

Hmmm, I kind of like Anthology. A collection of short stories is quite fitting.