Macro Use Cases

[RPTroll]

Use case: Adding/removing temporary state w/ variable data to a token, for the length of an encounter/spell duration/etc.

Possible implementation: I'd like to be able to dynamically add (and then remove) 'temporary' properties on a token to track predictable but relatively rare effects over several rounds -- which, I realized belatedly, are arguably separate token manipulation commands, tangential to macros (as long as macros can use them).

This prevents having to predict and pre-code every possible temporary condition variable that may arise during play. I'd prefer that non-temporary properties not be removable (for obvious reasons). I'd like the temporary properties clearly identifiable so that they can be cleaned up easily (facilitate deleting all of them at the end of an encounter/day/session/whatever).

Example: D&D-type Regeneration, where certain kinds of damage (fire, acid) cannot be regenerated. To track during battle, I need 3 HP properties: MaxPossibleHP, MaxRecoverableHP (which will decrease only with non-regenerable damage, but can increase back to MaxPossibleHP with Healing spells or longer-term rest), and CurrentHP (which will decrease with all types of damage, but will regenerate a few points/round back to MaxRecoverableHP during battle). And I need a RegenRate, rather than hardcoding or typing in the same value every round (and maybe a string, NonRegenDamageHint, in case it's something other than Fire/Acid).

Since only a handful of beasties can normally regenerate, but *any* PC/NPC can regenerate with certain spells/items, I would rather not have to add these properties to every single token that gets created: There are hundreds of similar cases that would bloat every token with lots of unused properties. I would rather have a set of macros, addRegen (to token), doRegen (per turn), takeRegenDamage (asks separately for FireAcid and Other damage), and then removeRegen to tear down the temporary token properties.

I like this one.

[Azhrei]

Use Case: Macro writer should be able to create a variable that is tied to a delimited list. Upon execution, the delimited list will be presented to the macro user allowing for selection of a singular value from the list. This value will then be assigned to the variable for use in later functions.

That is brilliant! I don't know why I didn't think of that already. That would be amazing. Especially if you can store the delimited list in a property. So you'd have one like WeaponList that would contain all your possible weapons, or SpellList, etc. Love it.

Umm, isn't that the same as my description of Use Case 3, where I suggested that a property would contain a list of possible states and the program would create a dropdown box for the user to list one?

I would add something else, though: when the dropdown box is used in a numeric expression it should return the index of selected word, and when used in a string context it returns the string. That allows us to present a list of words for a dropdown box, then use the return value to index into a separate property so that a separate string can be accessed.

For example, propA contains "Grapple,Trip,Disarm" and propB contains "+0,+4,+2" to represent the bonuses for each of those actions. Now we cause the dropdown to appear based on propA (with Grapple, Trip, and Disarm) and use the return value (of 0, 1, or 2) as an offset into propB to find the bonus (+0, +4, or +2).

This will require the dropdown box feature and some way to subscript the values contained in a property or variable. I suggest something like "choice(propName, number [, delim])" where the property name is first, then the index number of which string is desired, and then an optional third value to change the default delimiter from comma to something else (maybe even a regex?).

Sorry, that's not a use case any more. I was just disappointed that I didn't get credit for my use case! I think I'll just lay down and cry now ... (boo-hoo-hoo)

[jfrazierjr]

Use Case: Macro writer should be able to create a variable that is tied to a delimited list. Upon execution, the delimited list will be presented to the macro user allowing for selection of a singular value from the list. This value will then be assigned to the variable for use in later functions.

That is brilliant! I don't know why I didn't think of that already. That would be amazing. Especially if you can store the delimited list in a property. So you'd have one like WeaponList that would contain all your possible weapons, or SpellList, etc. Love it.

Umm, isn't that the same as my description of Use Case 3, where I suggested that a property would contain a list of possible states and the program would create a dropdown box for the user to list one?

I would add something else, though: when the dropdown box is used in a numeric expression it should return the index of selected word, and when used in a string context it returns the string. That allows us to present a list of words for a dropdown box, then use the return value to index into a separate property so that a separate string can be accessed.

For example, propA contains "Grapple,Trip,Disarm" and propB contains "+0,+4,+2" to represent the bonuses for each of those actions. Now we cause the dropdown to appear based on propA (with Grapple, Trip, and Disarm) and use the return value (of 0, 1, or 2) as an offset into propB to find the bonus (+0, +4, or +2).

This will require the dropdown box feature and some way to subscript the values contained in a property or variable. I suggest something like "choice(propName, number [, delim])" where the property name is first, then the index number of which string is desired, and then an optional third value to change the default delimiter from comma to something else (maybe even a regex?).

Sorry, that's not a use case any more. I was just disappointed that I didn't get credit for my use case! I think I'll just lay down and cry now ... (boo-hoo-hoo)

Sorry Az.. didn't mean to steal your thunder...I guess I missed yours when I read over them too...

[Mr. Pokeylope]

I was actually discussing the drop-down idea with another member of my campaign today, before coming across this thread. I had come up with a couple ideas:

Code: Select all

[var = {"foo", "bar", "baz"}]
[var = {"foo" : 2, "bar" : 1, "baz" : 3}]

The first one would return the displayed string, the second would return whatever value you associated with the given value.

I then started wondering if it wouldn't be more consistent using function syntax, like:

Code: Select all

[var = dropdown("foo", "bar", "baz")]

although I'm not sure how you would handle the second case above using that syntax. And neither of these allows you to store the choices in a property, which definitely seems desireable. So maybe:

Code: Select all

[var = dropdown("foo, bar, baz")]
[var = dropdown("foo, bar, baz", "2, 1, 3")]

[Azhrei]

Sorry Az.. didn't mean to steal your thunder...I guess I missed yours when I read over them too...

No worries, mate. I was being a bit melodramatic, I admit.

Rethinking my mention of a "choice" function, I think I would prefer "select" instead. It's the same term that HTML uses, so it might be familiar to users. At least, to those who've played with HTML a little bit.

[jfrazierjr]

Well... seeing how I already stole one...perhaps I can come up with something unique:

Use Case: Provide ability to prompt user to input all needed variables for a macro at one time.

Design notes: Suggest an alternate syntax which allows "pre-naming" of fields which dynamically creates a window with all fields so that that the user does not have to sit through multiple "popup" prompt windows. This can(should) also be considered when evaluating the FREQ to allow the user to design a list of choices to be driven by a combobox or html select style entry so that both syntaxes can be presented to the user in a single window for user input.

[Stitched]

I was actually discussing the drop-down idea with another member of my campaign today, before coming across this thread. I had come up with a couple ideas:

Code: Select all

[var = {"foo", "bar", "baz"}]
[var = {"foo" : 2, "bar" : 1, "baz" : 3}]

The first one would return the displayed string, the second would return whatever value you associated with the given value.

Without know the syntax, I don't think you need to do it twice. You can just create a dictionary that stores "key" with "value" either using something like "dict" (at least that's what most language have when handling list objects...

[Azhrei]

Use Case: Ability to preparse OR have a syntax to define ALL prompting fields in one shot and build a dynamic window with the fields labels and text/select fields for each in a SINGLE shot.

Um, a use case is a description of what you want the program to do, not a description of a user interface process or a shot at a possible implementation.

The rest of this is way more detail than users will care about, but it may help to define some of the terms that the developer(s) will use.

The goal of use cases is to clearly define what the program needs to be able to do. The next step is often a scenario diagram that describes the steps needed to accomplish each use case (just written in plain English, often in a bulleted outline style). Possibly a sequence diagram is created that tries to add some design elements to the scenario diagram (for example, guessing that there might be a "login" object used to validate a security check).

Whether the sequence diagram is done or not, there's usually a brain-storming session next where developers try to figure out what the major components of the application will be. I personally like the use of CRC cards for this, but different approaches work better for different people. All terms used to this point are within the domain of the customer/user. For example, any work done to this point should use terms like "player character" instead of "token", since the first is the general term that the user will understand while the latter is something that only makes sense to the developer(s). The reason for this terminology restriction is so that the customer/user can be involved in usage testing using the terms they're familiar with. This reduces communication errors. Plus, if the terms come from the user's problem domain then everything we've created so far can be verified by the user. And if it's correct, we've got a boatload of documentation completed already!

Then come all the other diagrams: class diagrams, state diagrams, action diagrams, collaboration diagrams, and so on. Usually the first of these is considered pretty important because it can give a high-level view of the entire application. The next two are used in certain cases, where the functionality of some piece of code is described in ambiguous terms or whose full functionality hasn't yet been discovered.

Hopefully that wasn't too obnoxious. There's a lot of other terminology as well, but the above gives an overview of the process. Object-oriented programming consists of analysis, design, and coding. Analysis is the definition of the problem, design is the definition of the solution, and coding is where the solution is turned into an application via some programming language. If the first steps are in error, effort spent on the later steps is wasted. This is why one of programming's most valued tenets is, "Know what you're trying to accomplish." A simple phrase that can takes days or weeks to answer for even the smallest applications...

"We now return you to your regularly scheduled program."

[jfrazierjr]

Use Case: Ability to preparse OR have a syntax to define ALL prompting fields in one shot and build a dynamic window with the fields labels and text/select fields for each in a SINGLE shot.

Um, a use case is a description of what you want the program to do, not a description of a user interface process or a shot at a possible implementation.

Yes, of course you are right. I edited the "use case" and then created some design notes....

[Azhrei]

(I'm glad you took that with the tongue-in-cheek that it was written with! I was worried that you might misinterpret! But...)

Your edit is still -- strictly speaking -- not a use case. Word it so that it describes a particular problem that you're looking to solve and it becomes a use case. For example,

Code: Select all

Use case:  A user wants to be able to run the same commands over and over but provide different values each time.

Being prompted for the values is a solution, not a description of the problem. The problem is, "The user wants to do such-and-such." The solution is, "The program will do this-or-that."

Also note that I didn't use the word "macro", since that's geek-speak and not the language the user would naturally use. Even the use of the word "command" is suspect...

We all understand what you want because we understand the context. But ideally use cases do not consider context -- if they do, the definition of the problem that the program is trying to solve changes! How much sense does that make?

Writing use cases is an art. I'm not very good at it, to tell you the truth, but I have done it lot. I keep hoping that some day it will become second nature. I've seen people that are good at it spend weeks just defining the problem before any design or programming begins!