Storyline Plugin
 

General idea: A LOTRO plugin that allows players to follow adventures throughout Middle earth that are written by other players.

Requirements (that I'm aware of)

• It would need to be able to monitor chat channels
• It would hopefully be able to monitor (or check) a players location
• It would need to be able to open a text window based on finding specific text in the chat channels (and hopefully also based on their location)
• It would need to be able to allow users to load the story they want to follow
• It would hopefully be able to display text when a story is loaded to get the story started (though this is not absolutely necessary)
• It would hopefully allow players to bring up the last text window in case they forget their next objective
• It would hopefully be able to allow story writers to write stories by creating a series of "events"

Events: An event would consist of 2 to 3 parts

1. A specific text in a chat channel (indicating the completion of an objective)
2. Hopefully a specific location (not always required)
3. A text window that opens telling the player their next objective

All objectives in writer's stories would have to create text in a chat channel (unless a script can truly monitor a person's location, in which case simply getting to a location could be an objective)
Examples of objectives:

• Killing a specific mob
• Winning a spar (I think this creates text)
• Getting a specific drop
• Selling a specific item
• Destroying a specific item
• Performing a specific emote to a specific NPC (or hopefully in a specific location)
• "Saying" something in a specific location (hopefully)

The stories would all follow a similar format and be linear (or branching). I suspect it wouldn't be possible to require multiple things as part of one objective (e.g. kill 10 orcs, or get 3 different drops). Nor do I suspect you could have a single story that requires the same objective at two different times (e.g. kill an orc, then later killing an orc), because each time would .
Text telling players the next objective => player completes the objective producing text in the chat channel => The plugin opens a window telling players the next objective...

Stories would also be limited compared to the ones in the game (e.g. no XP, no rewards, no interaction with items like burning a bridge, no items given to you players NPCs), but I still think stories could be fun.

I realize plugin writers are likely busy writing or maintaining other great plugins, so while I'm hopeful, I have no expectations. I was hoping it would be something simple I could do, but when I looked at LOTRO Alerts (which already had s lot of these features), it looked much more complicated than I could understand.

This is a neat idea. It is possible to work around the limit on the location (Lua has no programmatic access to location, only the chat response to the /loc command) by adding a "Look around" button that allows the player to test the location they are at (by issuing the /loc chat command) to see if they are in the correct location. As to repeating an objective and having optional objectives, there's no reason that couldn't be included - it's just a matter of planning the plugin so that objectives can contain multiple conditions. Also as you already guessed, this is VERY similar to what LotRO Alerts already does and isn't really that much more complicated than having an alert with multiple triggers (which is actually possible - in fact, using code snippets, you can have one alert that dynamically generates the definition of another alert).

As to in-game interaction, you are sort of correct, the stories would be limited in terms of rewards. However, there are kins that like to promote special events like scavenger hunts and murder mysteries where such a plugin might be able to play an interesting role and any reward could come from the kin sponsoring the event. Unfortunately, it would be fairly hard to prevent cheating (players could examine the plugin to determine how to fake completing objectives), so the entire event would have to be on the 'honor' system. Perhaps the scripts could be pre-shared such as being uploaded as 'add-ons' to the plugin.

I'll have to give it a bit more thought, as the plugin needs an 'Author' mode and a 'Player' mode and some way to communicate the script to the player(s) - actually very similar to a plugin I wrote for synchronizing horse back riding for a group practicing quadrille (not publicly available as it was specific to that kinship) combined with the multi-player version of Cards where a dealer controls the deck for a group of players (also not publicly available... yet... ).

EDIT:
I was just considering another trigger event could be having an effect placed on the character or having the character target an object or character (we can detect changes of target as well as the effects list on characters). Also, perhaps equipping a particular item could be a trigger as we have access to the equipped items list. Hmmmm, lots of potential...

I agree, good idea. :-D

That's a solid workaround, and hadn't occurred to me. I think the most important part of knowing the location would be when players are supposed to do something in a specific location (such as look). Or when they're supposed to "say" something to an NPC. That would work for both, but I guess another workaround for when you're supposed to "say" something to an NPC, is to have another objective where they're supposed to emote "Hi" first (since that would tell us they're actually at the NPC.

If they're doing an objective where they have to kill a mob, then LOTRO has done a good job at giving mobs a ton of different names, so I don't think the location matters that much.

Honestly I wouldn't have even guessed that was possible, but I'm happy to learn it is. That opens the door to a lot.

Honestly if I were "writing a story" I wouldn't mind doing it in a text editor and using a specific format. I imagined it (in my mostly programing illiterate mind) working somewhat like the abc files work. Actually, there's a quiz game I downloaded once that used an xml file and tags to parse the information if that type of format could work.

e.g.
<Title>This is the title of the story</Title>
<author>This is the person who wants credit</author>
<Intro>This is the dialog that starts the adventure. Perhaps it's supposed to be from an NPC, or perhaps it's supposed to be a letter, regardless it gives the players their first objective<Intro>

<objective>
<chatboxtext>This is the text the plugin monitors chat for<chatboxtext>
<count>Number of times the text above needs to show up to trigger the "dialog" for the next objective</count>
<loc>location requirement for the chatboxtext to count</loc>
<dialog>This is the text that opens in a window when the first objective is complete which gives the players their second objective<dialog>
</objective>

Of course, I could be way off in thinking this type of thing could work, but if it could, then I don't think it would be too much to ask for story writers to follow such a format. Also, it occurs to me that doing it this way would probably limit the storyline to linear or branching (choose your own adventure type).

Hmmm... I didn't realize that. Maybe I should compile a list of everything that shows up in the chat boxes. :)

Part of what gave me the idea was LOTRO alerts, another part was we used to play a LOTRO RPG game, and people wrote a bunch of stories for it that are probably still online. Another part, was that I would like to see LOTRO continue after SSG stops writing stories.

The need for an Author mode is twofold. First, the limits on plugins reading files. Plugins only have access to .lua source code files and .plugindata data files. Second is complexity in format. In order to control the flow of an application they would need to follow a fairly strict set of rules. There would be nearly as much source text defining the flow of the story as the actual content, thus the need for a tool to write them. The trick is to make the Authoring tool powerful enough to write complex, interesting interactive stories but simple enough for most people to use.

The Alerter interface is actually far more complex since much of its functionality revolves around the response where in this plugin, the response would be the "Reader" mode part of the plugin with basically a text window showing the current text, a couple buttons with appropriate responses and perhaps a "review previous" button to see the previous text and the chosen response. All of the complexity of this plugin's UI is either behind the scenes or on the Authoring side where all of the flow control stuff gets defined, like what kind of objective this step has, what are the valid choices, what step do you go to depending on which choice the user makes, are any choices "success" vs. "failure" choices and what happens for each, etc. Fortunately, it can be presented in a way where there are very few choices to make at each step (like a wizard), starting with type of objective, showing only the relevant choices at each stage so the author doesn't get overwhelmed. The finished script would then be saved as a .plugindata file that would have to be shared with the client. Imagine a plot with a dozen choices throughout and the amount of formatting required for a hand authored script where one simple typo would throw off the whole thing and the user having no idea why, people would get frustrated and never write stories. Also, by using a plugin, the author can define a location simply by going there and clicking the /loc botton to capture the in-game co-ordinates, or target an NPC or object and click a 'Target' button to capture the name, complete with accent marks, etc. making it easier to create the script accurately (with the ability to manually enter the info if the user so desires). I actually have a similar tool I use to capture the names and locations of annotations when creating the default data files for new areas for MoorMap and TerrainMap.

The biggest challenge for this plugin is actually distribution of the story scripts. The problem is that there is no way for a plugin to scan "all files in a folder", that is, the plugin needs to know what file it is looking for. There are two possible solutions, one is to have the user enter the name of a new story file once when importing a new story, the other is to have all stories use the same file name when importing (and get saved by the plugin as a distinct name once imported). That way, either the user provides the name or the name is a known value. The drawback to the first method is that users invariably find ways to enter information incorrectly and complain when it doesn't work. The drawback to the second method is that users would have to download and import files one at a time. I'm leaning toward the first method even though it does require some tiny amount of user input, it would be more efficient. It could even be simplified with a small external script the way songbook creates song libraries, but I am generally against telling users to trust executable code from an unknown source (there are bad people in every walk of life, even plugin authors...). Unfortunately, due to the different platforms that LotRO runs on, there are even some problems with using external scripts. The simplest and safest is still to just have the user save the .plugindata file in the correct folder and type the correct name into the plugin once per import.

The really cool (or scary) thing would be for someone to produce "LotRO-Zork" with the plugin...
"West of Hobbit Hole
You are standing in an open field, west of a white Hobbit Hole, with a boarded front door."... nooooooooooooooooooooooooooooooooooooo!

Of course, there is another huge hurdle. Internationalization. Without violating the EULA and using the .dat files for source info, it is fairly difficult to produce a story that can be used in languages other than the one it was authored in. Fortunately, the numeric co-ordinate format issue is fairly easy to overcome, MoorMap handles that with ease. The harder part is specific text matches in the chat text. MoorMap and Alerter also handle that well on the authoring side and the UI, but don't even attempt to handle it for chat stuff - for instance, you need language specific triggers for Alerter. It may be that this plugin can only practically work for stories in the language in which they were originally authored. I'll think about this a bit more, but I doubt there's a really good simple solution.

I'm thinking the natural data model for the user-defined "stories" would be a finite state machine. At any given time, the player is in a certain state, and the author defines various "transitions" to go to other states. That way the whole thing can be visualized (by the author) as a graph, with nodes representing states, and edges representing transitions.

The transitions can be triggered by chat messages, killing a mob, eating a pie, targeting an object, etc.

Each state can have its own variables/behaviors, including an introductory text message that shows when you enter the state (the "quest text"), or a timer that starts when you enter a state, and goes to another state when it expires.

Internationalization is a pain, but not impossible. I usually swap out a different chat parsing function depending on the active language.

I was reluctant to even ask before, because I thought it might complicate things, but it seems you're taking my suggestion to a whole new level. So I have to wonder. Would it be difficult to allow writers to put images in their stories? Since the writers couldn't put actual items in the game for players to see, if they could make images of what they're supposed to see (such as a letter, runes, a sword... whatever) show up in a window, it would enhance the stories.

Unrelated:
By the way the idea of the players being in certain states never occurred to me. The way I envisioned the idea originally they would have been able to skip to the last objective, or skip from one branch of a storyline to another. I suppose that also makes timers for parts of stories possible as well. That was something that passed my mind, but again I thought it wouldn't be possible.

Also I didn't realize a plugin couldn't scan a file (shows how little I know), but players have to type in the name of a file to play an ABC file, so I'd hope that wouldn't be a problem for this.

Additionally the idea of allowing writers to use a loc button, or target button never occurred to me either. It makes sense though. They'd probably have to walk their way through the story anyway to get locations, and doing it this way would cut down greatly on mistakes.

Anyway I'm impressed. What you guys are talking about now sounds much better than what I originally suggested.

Images are certainly doable. I've included text and image displays in a couple of plugins, one a tutorial plugin allowed the author to publish his PDF tutorials as in-game accessible plugins and the other, Bookcase, was designed to allow users to share their own stories. Basically, as long as the image files are included in the zip file with the story script and saved to the right location, we can display either JPG or TGA formatted images. Custom images are even used by MoorMap as Overlays, images that users can show over the map to display things like best paths or deeding areas (like the Berry's Deed Overlays) or where the best concentration of ore nodes are, etc.

As to states, yes, a state machine is the natural implementation of a scripted quest application. Basically the way the built-in quests work or like those old books where you would read a page and then make a choice which tells you which page to go to next (or like the old text adventure games like Zork). While we can expand on the simplistic transitions of a Zork game by having mult-part objectives, optional objectives and even objectives that can be done in any order in parallel, it is still just a state machine, just a slightly more complicated one.

Images shouldn't be a problem. You could distribute each quest chain as a directory, with all the files inside that it needs. The user would only need to enter the directory name to allow the plugin to find it.

Or, indeed, each quest could be distributed as a self-contained plugin, which includes all the Lua code, so that it would appear as a separate item in the Plugin Manager, and the user wouldn't have to enter any filenames. It's not like this is 1995, when we had to conserve disk space. Plugins are tiny compared to disk capacities.

I missed your reply because I was typing mine at the same time and never noticed you had posted until just now. :o

Yes, I think what you're referring to is "Choose Your Own Adventure" books, which I loved when I was a kid. At the end of the page, the reader would be asked to make a choice, and go to a different page depending on the choice.

That might be a useful way to organize the user interface for a story author. He edits a large collection of "pages", and specifies "page jumps" based on a user's choice, or one of the other triggers we've mentioned above (e.g. killing a mob).

I had a thought regarding the idea of a ;loc button. Perhaps instead of that, there could be a button that is defined by the writer (on each "page" of the story). That way they could use custom emotes by overriding the text (again I'm not really sure if this is even possible, but based on your other comments I suspect it might be).

e.g.
/laugh laughs awkward at <target>'s joke.
or
/lookaround searches the field at ;loc for Glaerdor's sword

Maybe have 2 boxes on the author's side where he defines the button such as:

Button name: <the text on the button displayed to the player>
Button action: <the text sent to the chat box>

e.g.
Button name: Search
Button action: /lookaround searches the field at ;loc for Glaerdor's sword

That might actually simplify other parts because then the plugin wouldn't have to monitor for a separate location and emote. It could simply monitor for one predefined text that contains both.

Also (unrelated) I realized this plugin might also be a good tool for creating in game tutorials, or something like an orientation for a kinship. :)

Anyway, I hope I'm being helpful. Feel free to tell me to stop anytime, I realize I'm pretty ignorant about this stuff, so I wouldn't be shocked to be told I don't know what I'm talking about.

I'm not real keen on using the ;loc embedded in text because it increases the parser complexity. Not only are the region names are different depending on which client you are using but by embedding it in other text you significantly increase the complexity of the patterns for matching the text. The /loc (or /pos) command always returns the result in the same format. Additional complexity means a greater chance for errors at runtime (this client will be complex enough without adding to the potential for bugs). The author can be able to change the label on the button that the user presses, but the underlying chat command should be as simple and reliable as possible and that means using "/loc" (or "/pos").

So far I have identified the following 'types' of objectives that are fairly easy to implement (with some unavoidable complexity on the generic chat match):
1=get to location (use /loc to test)
2=find target
3=chat match
4=kill x (count) enemy
5=acquire x (count) items - they must be in inventory simultaneously (no grabbing one from the vault, putting it back and grabbing it again :P )
6=have effect
7=use skill
8=equip item

Let me know if you think of any other types I should consider.

As to "knowing what you are talking about", that doesn't matter when brain-storming. Some of the best solutions come out of what initially sound like crazy ideas when brain-storming so keep throwing ideas out. Some will stick, some not so much, but they are all valuable (besides, this is your original idea).

Thanks for viewing my input as brain-storming (as it is intended), instead of demands (which it isn't), because I'm still figuring out what can and can't be done, and wouldn't make demands regardless. What I envisioned would have been more simple, and less useful.

At first I imagined EVERYTHING being based on matching text with the chat. However, if I understand correctly, that particular feature is a problem for internationalization, whereas the other 7 objectives on your list wouldn't be a problem.

Before realizing this, when I was thinking only about one language, I assumed puting an action into a button (such as an emote) would make things more simple. I figured the author could do the action, then paste the chat command for the action, and the resulting text into the authoring tool. I thought that way they could be 100% sure everything will work as planned.

However, if everything was like that, then everything would have to be done 3 times (logging out and on under a different language between each) in order to do everything in 3 languages. I see how that would become a lot of work.

I'm not sure if performing an emote is something a plugin can detect outside of "chat match". If it is, that's GREAT. Perhaps in a story they could sometimes have a 2 part objective. 1) get to a location (/loc) and 2) perform an emote (e.g. lookaround). I assume that way the two things would be easy for the plugin to pick up.

If emotes are only visable to a plugin based on "chat match", then perhaps that's okay too. There's a limited number of emotes, and a limited number of languages LOTRO supports. Even if the plugin doesn't translate the emote for writers, I'd be plenty happy to try every emote in every langage to make a chart. Then, I assume, writers could set a trigger for each language.

Perhaps emotes would be a nightmare to deal with though (this is what I'm beginning to suspect). In that case, the /loc button with different text (i.e. lookaround) would do the job by itself, and the writer could simply write the action into the story text. The biggest difference being the character doesn't make the emote movements. If the emote movements became important to players & writers, and the emote text was difficult to deal with, then I suppose a workaround would be to make the emote an action that isn't really required that they do before the action that completes the objective. I suspect most people simply wouldn't even notice it wasn't required.

One of the things I liked about the idea of using emotes (when I was thinking everything would have to be done by "chat match") was that it was another way of confirming a player reached a certain location. For example if they reach a specific NPC, then perform an emote to the NPC (such as /wave). The target's name comes up in a specific channel. However, if the plugin can detect who you have targeted, then that's even better.

The only other thing I can think of that MIGHT be considered as an addition to your list (besides emotes and/or target if they're possible and desired) is acquiring something in the barter wallet.

Personally, I would have been impressed by something super simple that put all the work on the writers, but I don't mind throwing out ideas as long as they're not viewed as demands. I don't know how hard it is to do one thing vs another, so something I might think is simple might be a nightmare in reality. I realize that.

I had forgotten ;loc and /loc did different things. ;loc gives coordinates in 2 dimensions that aren't very specific, so I thought it could be used to indicate that a person is generally in the right area, while not requiring them to be on an exact spot. Now I realize that /loc is much more specific. I assume there would be a way to allow a range for /loc, whether it would be by matching only the first 2 or 3 digits of each value, or by some other means.

I suspect at this point the best way for me to contribute would see if I could come up with a story to see if there's anything I hadn't considered that would be needed or desired by writers.

I'll add "Acquire x Barter Currency" to the list of objectives. Although, that does lead to one problem as not everyone has the enhanced wallet, so some users will have some currencies as items in their inventory. Perhaps we can leave it up to the author to set two objectives, "Acquire x Items" or "Acquire x Currency" and add an option in a future version to automatically add both objectives for known currencies - unfortunately, there is no mechanism in the API to determine the item associated with a currency so that list would have to be manually compiled and maintained (new barter currencies are added quite frequently).

One way to deal with the multiple language specific responses is to simply store a language flag in the story indicating which language it was written in and warn the user if they try reading it with a different client. That's certainly workable, at least for version 1.0.

Emotes get a bit tricky because not only do they have different text for each language (and different commands for each language), they can also generate different chat messages depending on who or what you have targeted. There are a couple of solutions, the simplest would seem to be to allow the author to specify multiple chat texts for each chat objective. In the long run that also solves part of the internationalization problem since the author could just include a pattern for each language the story supports.

For the emote chat messages, I exhaustively researched every one of the possibilities a couple of years ago in making this plugin, which translates the messages into Russian. There have been a few new ones added since then, but the majority of the work is done, for English.

I also came up with an efficient way to do the parsing. The naive way would have been to apply several hundred regexps to every single chat message after it arrived. I thought this would be potentially costly in terms of CPU overhead. Instead, after receiving each message, I replaced the player's name and the target's name with placeholder strings. Then I used that string as the key when searching the translation table. Hash table lookups are very fast.

On another note, not every possible objective needs to be imagined before something useful can be made. Specific features that are required for a "proof of concept" story could be implemented. Then future stories will provide guidance about what other features are needed.

I 100% agree. I hope I'm not complicating things. I suspect a 1.0 version with a decent first story could spark a lot of interest using only kill counts and /loc (and possibly find target). In fact, I think you could even work with just /loc or just kill count. And if I'm wrong, then it's probably better to find that out before a bunch of work goes into designing complicated parts for the plugin.

What I suspect though, is that custom stories will become a typical feature of large kinship activities. I also suspect even a 1.0 version would be useful for horse races, because now people could be required to reach certain spots, and it would be a little less on the honor system. Additionally I think it could be a cool way to have an "orientation" to a kinship, provide walkthroughs for instances, and provide tours for your house (a way to explain stories or the meaning behind items you've collected).

Now that I think about it, perhaps some sort of race where people run around completing objectives (without any real story, just to showcase what can be done with the 1.0 version) might be a good way to introduce the idea to people at first.

I've thought it might be neat to tie in stories to some of the NPCs or places that are special but not part of the existing stories - the boy under the steps in Bree, the Cat house in bree (where is the owner?), the rabbit cave, all of the killer bunnies on their bear skin rugs (there are a few scattered about), the cabin with goldilocks and the three bears, the mourners at the old graveyard north of Bree, etc. Lots of fodder for new stories.

I've got a 500 LP code floating around that I was planning to give away (I've got a ton of LP stored up on multiple accounts already), perhaps a story contest would be appropriate. If it is popular enough, perhaps you could even get SSG to sponsor prizes for regular, annual (or even more frequent) story contests (they've donated prizes to kin events before).

EDIT:
As to a prototype - I was making good progress before I got sidetracked by the annoying inability to change the height of the skinnable textbox controls (you can change regular ones but the skinnable ones use a fixed height background). The issue was that this plugin is most likely to appeal to role players. Role players seem to like either fancy skins that put them in the mood for their characters or "minimalist" skins that keep the UI from ruining their immersion. Either way, they seem to like skins. Add to that the amount of reading (and writing) in this plugin and I wanted the UI to be as scalable as possible so I started messing around with user selectable fonts and sizes with dynamic UI layout when I ran into the button issue. We can either have scaling button fonts or skinable button backs but not both. Frustrating. I finally settled on a compromise where the plugin automatically selects button font size by the largest font that fits on a button (about 22 pt) from the font family chosen by the user - the rest of the UI will use the full size font the user has chosen so the text will be easily readable.

Speaking of Feature Creep. As Thuralor commented, it is good to get something out, even if it doesn't have all of the desired features. Feature Creep is a term used by software designers to refer to the almost endless cycle of adding new features, implementing and testing them only to find more new features to add. That cycle can push a project's development waaaaaay past any reasonable delivery date. A friend of mine was working for years on a game engine but he kept adding new ideas faster than he could implement the old ones. I used to joke with him about the Feature Creep and one day he finally renamed the project "Feature Creep", splash screen and all (and no, it isn't finished yet :p ). So, while I've been listening to ideas and brainstorming, I haven't been idle. However, don't expect the prototype to have all the bells and whistles (but there will be a few nifty ones).

I love it. One of the benefits of player produced stories is that they can funny if they want. They can also allow the players a lot more choices if they want, because nothing it going to affect the main story.

I wouldn't mind donating to the cause myself, and I suspect SSG will really like the idea. Part of the reason I had the original idea (which has now been improved) was because I thought it could help increase the longevity of the game, possibly even after SSG is done writing stories. Plus, from what I've read in the forums the role playing community has felt somewhat ignored and this might go a long way towards making them happy.

It occurred to me that perhaps we could convince SSG (among other things) to give a title to anyone who enters a story in the contest. I suspect the role players would really like that.

As far as feature creep, I'm sure even the 1.0 version will blow the concept I envisioned out of the water. So while it's fun to talk about bells and whistles I'm certainly not worried about them.

I do look forward to helping promote the plugin though.

I was thinking something like "Made of Hamsters" :p as a tip of the hat to MoL, "Made of Lions", who creates most of the in-game quest content as well as the old joke about the servers being run by hamsters on exercise wheels. I know Turbine did some custom titles for some events in the past, but I don't know how receptive the current crew are. It wouldn't hurt to float it past them after the plugin is ready for prime-time.

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.

Once upon a time would be nice.

Just some previews
Authoring Window with Story Selection
ScreenShot00129

Authoring Storyboard window - those Transition arrows were a royal pain :P
ScreenShot00130

Authoring Storyboard window with Chapter Maintenance Info tab
ScreenShot00131

Authoring Storyboard window with Chapter Maintenance Objectives tab
ScreenShot00132

The reader window with a brief chapter with two objectives
ScreenShot00133

So, it is coming along. The Storyboard was a challenge to create but I think it can really helps authors visualize the flow so I wanted it in the first version. I still have a few bugs to exterminate but should have the prototype available to beta soon. I'm still considering Import options but so far the idea of distributing stories as a data file zipped with a very simplistic plugin is most appealing.

Haha. The graph is awesome. Looking forward to trying it out.

Congratulation!


I like this idea and the Garan's version is very nice! ;)
I don't have a time for participate in this projet but I can made a french translation, if all word are on only file.

(Mon anglais n'est pas très bon.. Sorry! ^^)

Cordialement français

It looks amazing!

I would have never come up with an idea like the storyboard window. However, now that I've seen it, I suspect it will be a really nice feature, and that it will make it a LOT easier for people to plan stories.

Well, Beta ver 0.2 is available for download (don't ask what happened to 0.1, we don't like to talk about that...) :p

http://www.lotrointerface.com/downlo...Anthology.html

It will probably take a couple of days for Lunarwtr to add it to Compendium but if you've ever downloaded another plugin manually you can download it manually. There are several components, ONLY load the "Anthology" plugin via Plugin Managers or manually, the others are loaded internally and should not be loaded manually or by a manager, even the Tutorial is loaded internally.

I'm disappointed that you decided against exporting the stories as complete, stand-alone plugins.

An uninitiated user now has to install two plugins, load one of them, and then follow author-supplied instructions on how to import and run the story (choose Import/Export, choose the story in the plugins list, click "Import Lua", click "Main Menu", click "Reader", click "Load", click the plugin name, click "Select").

Whereas if you exported the stories as standalone plugins which included the reader source code (but not the Authoring and Import/Export code) all the user would have to do would be to load the story directly from the plugin manager. (This would also eliminate the problem of different stories being incompatible with different versions of Anthology.)

I think it will reduce the popularity of the system. Maybe not significantly, but somewhat.

I had considered packaging the reader with the stories but that creates a whole new series of problems with bugs and fixes. If something goes wrong with a story either due to a bug in my code or SSG changing the API, it is much simpler to reproduce and fix the problem in a central reader plugin. There were a number of other factors but long term maintenance was by far the biggest.

It would still be a central reader plugin. It would just have the story data packaged along with it. You'll still end up using the story-author's data to reproduce issues, either way. I don't see how your debugging task is simplified.

I think the way you have chosen to do it creates more long-term maintenance problems than it solves. You'll have to maintain backward compatibility with old stories, and in practice, that will mean testing your updates with old stories before releases.

But the main reason, as I've said several times, is that ease-of-use for the end user is absolutely paramount, if you want this thing to be popular. But I'm beating a dead horse now. It's a cool plugin, I'm sure it will get lots of use.