The initial seeds for this framework came from the L5R die rollers posted by Rumble (http://forums.rptools.net/viewtopic.php?f=20&t=18224) and metatheurgist (http://forums.rptools.net/viewtopic.php?f=20&t=23866). From there I tried to add a minimal set of features that I wanted personally for running L5R. I found 's colorScheme lib a few weeks ago, and adopted it immediately for customizing styling, although the extent to which I really leverage the css classes therein is limited.
The general purpose of this framework is to enable the rules, not enforce them. As such I've made only a token nod towards "security", and very little towards enforcement (I make a modest effort to make sure the GM, if he's paying attention, can tell if a player is cheating). So, for instance, the system will ask you to set your stance at the start of your turn, but it won't prevent you from changing it later.
Features
Framework Features (v0.1a)
- Players
- Of course, an rKn die roller, allowing the setting of a bonus, designation of the roll as unskilled or emphasis, to the GM or to all players.
- An "STR" die roll builder dialog. STR stands for Skill-Trait-Ring Roll. The dialog lets you set up a particular roll against a particular TN, which in turn will bring up a roll dialog allowing one to set raises and add bonuses before rolling. (plus options for spending void, designating emphasis, unskilled, etc.). I also have a house rule option for an "open" roll, where one gets a raise for every 15 one beats the TN by.
- Void Tracking.
- A simple Don Armor feature, which allows you to designate what sort of armor a token is wearing, and its effects.
- Basic token statsheet setup, displaying Rings/Traits, Armor, Void Points and Wound Levels/Penalties
GM -- In addition to the above buttons, which the GM can use on any tokens (not just ones he controls) - Push Meditation/Medicine/Tea Ceremony buttons, allow you to generate roll dialogs for these skills to push to designated players with the resulting effects automatically applied (void recovery or wound recovery as appropriate. As the GM you can modify the base TNs, skills used, etc, the rules are sited for you for convenience and the dialogs seeded with the default values.
- The primary tool for the GM is the "GM Panel" which exposes its own set of features...
- Selection Control -- Automatically clear select, add pc's, pc's NPCs or your own NPCs to the current selection set. Also displays all the tokens currently selected with the option to remove any selected token from the current selection.
- Push Roll -- Push a roll you designate to the currently selected token's owners. This will generate a link with the given roll, at the TN you specify with link and description you specify. E.g. push Perception rolls to your players. You can specify the results to go only to you (the GM).
- Roll Init -- Part of the combat system (see below), the panel allows you to roll init and add to combat all the selected units by one of three methods: Each individually, By TokenImage as groups (so tokens with the same image share the same init), or all selected as one group init. Roll init, as per 4e rules requires you to set stances for each token before it rolls inits for them. It takes the init values from the token's stats or InitiativePool trait (if set), but gives you the option to modify the die roll before rolling.
- Push Damage -- Push Damage to selected tokens, set whether armor reduction applies to the damage (if armor was set with the don armor feature above). This will bring up a Receive Damage dialog with values customized by your specification, for the token owner, allowing them to specify any special reduction they might have, and spend void to mitigate damage.
- Rest -- Rests all the selected tokens, brings up a dialog allowing you to tailor somewhat the degree of recovery. Allows entry of a custom formula, or use of the default 4e rules for "a night's rest". Applies to selected for void and wound recovery (indicated separately).
- Set Scene -- I have a particular feature I've wanted for GMing, which I added to the panel. This feature allows you to "set a scene description", describing a location, mood, weather, whatever. Scene description is sent to the PCs in a special font, and updated in a "Scene" frame, which the PCs can dock somewhere to see the current scene at a glance (I dock mine at the top of my chat list).
- 4e Combat flow. Discrete 3 stages. GM initiates combat by "Starting Combat". Pushes a roll init dialog to the players. As per 4e rules, tokens must set their round 1 stance before rolling initiative.
- Brings up a Combat Frame which can be docked that is updated as combat flow progresses--indicates the stage of combat as well as the round. In Stage 1, this frame will display who has not yet indicated they are ready (having exerised or passed on their stage 1 options). In Stage 2, this frame will indicate whose turn it is, provide a handy end turn link if you own the current acting token, as well as a Delay action link. If you are currently delayed, this frame will allow you to indicate your desire to act after the current actor.
- Support for Stage 1 actions -- Void options to swap init, improve armor tn, or your improve init.
- Stage 2 actions -- Reminds players to set their stance at the start of their action in stage 2 after the first round.
- Stage 3 clean up -- Resets modifiers from Stage 1, and handles Center stance init bonus for next round (also clears delayed initiatives)
The framework contains two lib tokens--Lib:L5R and Lib:colorSchemes. The Lib:colorSchemes token is unmodified, at this juncture, from the version in its latest release (see above). The Color Scheme Manager button on that lib will bring up the dialog for setting your color preferences. Lib:L5R is not intended to be used directly. Instead, all the features you might want to use are exposed via Campaign macros for the Players and the GM. These buttons should be safe to drag wherever, as you like, afaik.
Recommended Server Settings
- Strict token ownership
- Use Individual Views (not sure this is really important, tbh)
- Restricted Player Impersonation
- Players Receive Campaign Macros
- Use ToolTips for [] Rolls
I have a host of disclaimers for the wary .
Disclaimers
As a result of the above facts, the code in this framework is very ad hoc. I had no experience with MT or what it could do, and the code reflects this. Depending on when I wrote the given macro, there is a sort of evolutionary progression of the code--It's in desperate need of a rewrite. The longer I worked in MT the more "sophisticated" my use of it became. This can be very confusing if one goes to look at the code, as I use different patterns as time goes on. Worse, I attempted about midway through to enforce some coding conventions and guidelines, but those conventions turned out to be insufficient and were grown slightly as I continued working. I also never went back and completely rewrote the old code to conform to those rules. Most of the code is not commented, in part because it took me a while to become confident in my ability to comment code without causing side effects.
Finally, this framework is very much an Alpha/WIP. As I stated at the first, I wrote this framework for a game I never actually got to run. Thus, it's seen very limited testing. One of my goals here, if people are interested, is to get some help testing its features
I have not currently scheduled additional time to expand this framework, but if there is sufficient interest, I might. While building the framework many ideas occurred to me for other features which I could add that might be fun. I list many of those below.
Future Features
- Possible Features -- There were a number of features I considered adding while I was writing this framework that were beyond my original conception. Mostly these represent things I figured out how to do once I got into the scripting of MT. A few are features I chose to cut, due to the time sink aspect of this project in the interest of getting it out there sooner, rather than later. As I mentioned above, future development of this framework (by me, at least) depends largely on how much, if any, use/commentary it gets here. If no one is using it, it doesn't seem worthwhile to add features to it?
- The first thing I would probably do would be a major code review and refactoring to normalize & standardize the code, naming and coding conventions and patterns used. Also offload commonly used subfunctions in contextless macros.
- Combat Action Frame -- This was the main cut feature. Mostly I decided that what it could do with what little I had in the framework so far felt rather limited in value. The idea is to have a frame in combat where you can prep your combat action, either a melee attack or a casting action. The framework already has a good understanding of what any given token's TN to hit is, as well as how to roll dice and designate raises. But, no skills, no weapons and so no damage (except perhaps for NPCs), etc. The rudimentary bits of the frame are in place.
- Stance modifications -- The other main cut feature. Most of the effects of stances could be automated given the Combat Action frame above. The infrastructure for this is largely in place, already.
- Add to the Combat Action Frame actual action tracking--1 Complex or 2 Standard actions, plus free actions. Some sort of description of available free actions, possibly even with tracking for the idea you can only do one of each. Specification of an attack as a complex or standard action, and tracking thereof. Tracking complex action to Mastery Level casting requirements for Spells.
- Weapons. Analagous to Armor.
- Clan libs. Lib Token per clan, set to the mon image for reference of clan specific info in future expansions and campaign inclusion of the mons for future character sheets, etc. Clan Name, Clan Image, etc. Families as well.
- School libs. Lib Tokens for each school to use in conjunction with a hook/event type system to implement school technique modifiers in the framework.
- The specialized push dialogs for skills (e.g. Push Meditation) could be generalized to allow a MT saavy GM to push an arbitrary roll with an arbitrary set of automated "rewards" for success. Surfacing (exposing) this capability would require a new dialog/frame. These could even be saved to a library on a GM Lib token (to avoid loss on future upgrade) allowing GMs to develop collections of personalized automated tests.
- Skills -- Three parts. First, add support for the specification of skill ranks and emphasises on tokens. Second, add to the "data" library knowledge of every skill, description, emphasises, default trait, etc. Wired in lookup/access for STR, etc.
- Spells -- Analagous to Skill above. Three parts again, one for specifying a token's knowledge. A second for adding this information to the campaign's "database". Third, leverage the reward lexicon to automate spell effects.
- Abilities (For NPCs), Kata, Kiho, Merits/Flaws each analagous to the Skills or Spells above. I'm not sure where the line is with AEG for this sort of thing. Not to mention, this is a lot of data entry. Skills would definitely be the first, most significant feature to add, imo. But use thereof, requires significant data entry by players as well as rptok tracking. YMMV.
- Character Sheet -- This feature looks like I cut it, but actually it was never on my list. For my games, I felt my players would not want to maintain separate copies of their characters both in MT and outside of it (we use pdfs a lot). There are degrees of this feature. NPC vs. PC sheets. Edittable vs. Display only. Then get into number tabs (include skills? gear? spells? schools? etc.). A great deal of time could be wasted^h^h^h^h^h^h spent here.
- Party Frame -- This is something I personally could see being quite useful. After writing the selectionUICmp for the GMPanel I thought a party frame for combat, listing out each combatant with a variety of info for tracking and GM command console for combat could be really useful. Push skills, push damage. integrate with the generic reward tracker (below). Give Init, display who'se delayed, who owns each token on the list, void spent this round, void left, wound level, TN to hit, stance and when it was set, etc. Also add to selection, etc. Useful features for watching for cheating as well if one were so inclined.
- RP Point Tracker/Generic Reward Tracker -- Allow the GM to define various kinds of rewards (default example being XP, but could also include Glory, Honor, Duty, etc.) and set up a system to adjust those values via a dialog/frame and programmatically.
- Add Sides to combat -- This would be a framework enhancement allowing the GM to specify groups of tokens as being "on the same side" for faster/easier target menus for selecting friendly/enemy/allied tokens where that might be desireable.
- Extend Color Schemes -- I thought about doing this while I was building the framework initially. Basically adding to the options the Color Scheme system allows for to include fonts, font size, etc. and adding some class markups for chat messages as well (announce, combat.announce, etc.). Would go hand in hand, presumably with a beautification effort of my many dialogs and frames. I made a first pass attempt to make them not ugly, but they are far from pretty, and only marginally leverage the options exposed by the Color Schemes library.
- Campaign Settings panel -- For setting house rules, as house rules get implemented. For instance, I would add the concept of "Open" rolls to this panel as they are a house rule of my own. Other house rules which might get implemented could similarly be tweaked here.
- Inclusion of other MT drop-ins. For instance there's a sound token thread I've been meaning to check out. And there is a promising looking thread on graphical backgrounds that could be nice.
(Also, the token collection I made... https://www.dropbox.com/s/9gjhl2fa0juyg92/Tokens.zip)