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)
Events: An event would consist of 2 to 3 parts
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:
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... ).
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
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.
<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>
<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>
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).
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.
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.
|All times are GMT -5. The time now is 12:18 PM.|
vBulletin® - Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.