One big macro, or lots of little ones?

Discuss macro implementations, ask for macro help (to share your creations, see User Creations, probably either Campaign Frameworks or Drop-in Resources).

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice

Post Reply
meshon
Cave Troll
Posts: 75
Joined: Fri Mar 26, 2010 10:54 am
Location: AB, Canada

One big macro, or lots of little ones?

Post by meshon »

First I just want to say thank you to all the people who post on these forums and respond to questions. I've been working on upgrading an old (and very simple) framework for a skirmish game to something more automated (and much more complicated) and I've been able to find many answers here. So partly I wanted to stop lurking and just say thanks! With all the great information here I haven't had any reason to post questions.

However, back to the post topic. I'm making a framework for a game that has a lot of exceptions to its basic rules and I'm working on the attack sequence. On the surface it is pretty simple: you roll a die against a target number to hit. If there's a hit you roll to wound and if the wound is successful you roll for injury. However, every step of the way has all sorts of things that can modify the results. Most weapons have special rules and characters can get special skills that affect the outcome of various parts of the process, and factors like range, cover and movement all play in.

In my planning stage I've outlined about a dozen or so steps and I'm wondering if it is better to have a macro for each little step or to have just a few macros that do everything. I'm inclined to go for a bunch of smaller macros that get called in sequence because it makes the code easier for me to manage but I'm wondering if anyone who makes very intensive frameworks has any advice. What are the pros and cons of each approach?

And again, thanks for all the questions that have been answered here, even though I hardly ever post!

cheers,
Meshon

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: One big macro, or lots of little ones?

Post by wolph42 »

Hi Meshon, welcome to the active part of our community :wink:

funny thing is, your question sounds a bit like aliasmask vs me, am is (mostly) for modularity and small macros while im (mostly) for large macros that do it all. Basically its a matter of style. That and from a 'correct' programming point of view) AM is better then me.
What it boils down to is this: large macros will eat stack, while many small ones will eat speed. Thats the trade off, AFAIK (besides matter of style, modularity etc.).

Overall I think the best advice is: do what you feel best with. Its your code, you''re probly the one who will update and maintain it the most so make it comfortable for you. (and don't forget to add lots and lots of comment).

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: One big macro, or lots of little ones?

Post by CoveredInFish »

Using lots of small macros allows you to reuse code. So you dont have to write it twice, but even better you dont have to debug it twice (or even more times). But you have to send data from one macro to another, so it adds usually a little overhead to each small macro. And now we're again where "matter of taste" begins. I lwas teached I should never write the same code twice, but in practice i'm less strict.

Oh yeah ... and what wolph said.

User avatar
aliasmask
RPTools Team
Posts: 9023
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: One big macro, or lots of little ones?

Post by aliasmask »

Modularity vs Design is a common problem to deal with. But if you start with modularity, it's easier to collapse it for performance, than to do the reverse which I often do. I like the modularity because it's easier to read if you name your functions well. You don't want to go overkill on the modularity especially if that function isn't used or is expected to be used anywhere else. I have rules of thumb when creating functions:
  1. Does the function help simplify a process I will do multiple times in the code that's not in a loop? This is asking do I have to type the same code over and over.
  2. Can this function be used for multiple processes with a change in data? Many times we write very similar code throughout and only change 1 or 2 variables. Functions are great for this process.
  3. Is this process distinct from the surrounding code? You don't want to take random chunks of code an put it in to a function. It should have a very specific purpose.
  4. Will I be using "big data" structures? Big is kind of arbitrary, but I would define it around 300 pieces of distinct data. When you have big data, the cost to pass the data to function becomes increasingly time consuming. If you do it once, then it's not that big a deal, but if the function is in a loop and called several times then you'll notice the difference just making the call to function.
  5. Is my function longer than one page? Once I have a function that is 40-50 lines then I take a closer look at it so see if I can shorten it up. This is all for readability. If you can see all your relevant code at one time, then it's easier to debug or review. But with Big Data, this isn't always possible.
  6. Does it help separate mixed processes? You have 3 core processes, Get Data, Process Data and Output Data. I talk more about that in the link. There's nothing harder to read than regular output to chat and code mixed together. A quote in the wrong place and everything blows up.
The downfalls of modularity.
  1. Physical separation of code for reference. You'll find yourself tracking an error and in turn tracking where all the individual functions are. I use RPEdit and Notepad++ (in signature) to make this easier using bookmarks, function collapsing and formats to identify functions.
  2. Referencing Lag. Not only do you have to sometimes build structures just to pass the data, but the act of passing data is an extra process. Also, MT doesn't handle nested structures very well, so if you have a complex structure you may want to consider not passing the whole thing.
  3. MT Macro Lag. If you have too many macros on a token, it can cause lag through the User Interface. Too many is also arbitrary, but I say if you have 100 macros on a token, that may be too many. When ever you click on a token it has to redraw all those buttons in the Select and Impersonate frames. This isn't too much of a problem on lib tokens because they generally are not clicked or moved on a regular basis.
  4. Functionality Creep. The tendency to keep adding features to a function is there. Sometimes it's just better to create a new function instead of adding another parameter to an existing function. As another rule of thumb, 3 arguments to a function is ideal.
I think one great thing about modularity is having a bit of code in one location that can effect many processes. I don't want to debug code and have to change it in 10 locations to make my update. Changing one bit in one function makes life easier.

keyword: amsave programming bestpractices


meshon
Cave Troll
Posts: 75
Joined: Fri Mar 26, 2010 10:54 am
Location: AB, Canada

Re: One big macro, or lots of little ones?

Post by meshon »

Thank you very much for the feedback. I'm pretty sure some of the code I'm writing would make certain better programmers cringe...

But I figure I'll get it running first and then make it run smoooooth later.

cheers,
Meshon

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: One big macro, or lots of little ones?

Post by jfrazierjr »

meshon wrote: But I figure I'll get it running first and then make it run smoooooth later.
I would suggest not. Doing things this way will end up costing you far more time. I would personally suggest you STOP doing and start thinking first. Spend a few days thinking about the various things that need to get done and break them down into conceptual pieces.

A simple one for example "Attack". This seems really simple on the surface, but when you really think about it, it breaks down (usually) into one or many sub pieces (depending on your level of automation desired and of course game system). Here are some thoughts on breaking this down:
  • Usually, an "attack" is a roll of some type, optionally compared to some target value(this second part adds more work)
  • bonuses to the "attack" , from abilities, weapon being used, range, etc?
  • penalties to the "attack", such as range, the attacker not being proficient with the weapon of the attack, target cover/concealment, etc
  • Now think about the above and what happens if the attack may target multiple targets. How will you handle DIFFERENT bonuses/penalties for each target separately(if at all)
Of course, those are just a few possibilities, but hopefully you get the idea. Trust me, it's far easier to break things down conceptually before you begin writing than after you have a huge macro(and less error prone also)....
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: One big macro, or lots of little ones?

Post by wolph42 »

jfj has a point. As reference here a structural breakdown of my melee and ranged attackmacros:
example breakdown
Colors represent scope (if the child has the same color it has the same scope),
the three main functions all work with a new scope.
example.jpg
example.jpg (126.02 KiB) Viewed 5436 times
Obviously this initially is overkill, but the structure of the whole process does help you to outline the modularity of your code.

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: One big macro, or lots of little ones?

Post by CoveredInFish »

While Joe is absolutely right I want to say the other way is okay too - if it has more momentum for you and is part of your learning process.

I did both. When I'm all professional and about to start a serious project I totally think first - as it only has benefits. Way more difficult to add this data in all these functions or change the data structure to another or rewrite my output functions again and again ... the more complex your project is the more time will each little rework cost. And this will be much more than your thinking phase in the beginning!

But when I'm all "lets try this" I might have so much momentum that I just throw out some code. And then it evolves a bit and I start to add something here and there ... oops, now its a project of considerable size. Okay, I would have been more efficient if I had planned the project from the beginning, but then I might never had done it at all.

(okay, a bit lengthy post, dont know if this gets my point around or if its of any interest, but well ... here it is)

meshon
Cave Troll
Posts: 75
Joined: Fri Mar 26, 2010 10:54 am
Location: AB, Canada

Re: One big macro, or lots of little ones?

Post by meshon »

I'm sort of using the "some of each" approach. :|

I did a lot of planning and notes outside of maptool just to help me view the bigger picture. This is important as I'm just getting to the part where I make the roll to hit and I've already identified more than half a dozen distinct steps.

However I am still learning so it's harder for me to plan fully; I just don't have the experience. There's been at least one point in the process where I've made a big change to how things work. Because I've been making smaller pieces of the attack sequence I have found it fairly easy to adapt when I find a new exception buried in the rules that I need to account for.

But in the interest of making progress I've been avoiding spending too much time on the things that aren't crucial; I get sidetracked waaaay too easily!

One thing the posts here have shown me is that the process of planning macros is at least as important as the practice of writing them.

Cheers!
Meshon
CoveredInFish wrote:(okay, a bit lengthy post, dont know if this gets my point around or if its of any interest, but well ... here it is)
I'm going to need to say the same thing about mine!

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: One big macro, or lots of little ones?

Post by jfrazierjr »



I did a lot of planning and notes outside of maptool just to help me view the bigger picture. This is important as I'm just getting to the part where I make the roll to hit and I've already identified more than half a dozen distinct steps.

However I am still learning so it's harder for me to plan fully; I just don't have the experience. There's been at least one point in the process where I've made a big change to how things work. Because I've been making smaller pieces of the attack sequence I have found it fairly easy to adapt when I find a new exception buried in the rules that I need to account for.

But in the interest of making progress I've been avoiding spending too much time on the things that aren't crucial; I get sidetracked waaaay too easily!

One thing the posts here have shown me is that the process of planning macros is at least as important as the practice of writing them.
While I think planning the macros's is important, IMHO, pre-planning your characters "properties" is just as important. Due to speed concerns, you don't want to go overboard on really deep or wide(deep meaning number of levels from the top, wide meaning LOTS of individual items) complex properties(String properties, String Lists or their JSON equivalents). HOWEVER, some use of such features can make your code a lot cleaner and easier to understand. For example. In D&D 4E, each character has about 18(or so.. I did not count so guessing from memory) possible skills. I would generally create one Campaign Property to store the skills in as either a JSON object or a StrProp(StrProp's are FASTER, but JSON's have a few less restrictions and thus are a bit easier to code AND are the future of MapTool's macro system) Example below using two different methods of storing skills(neither is "right", just A WAY) as a JSON object:

Code: Select all

{
    "Skills": {
        "Diplomacy": {
            "Ability": "Charisma",
            "Training": 5,
            "Focus": 3,
            "Class": 1
        },
        "Endurance": {
            "Ability": "Constitution",
            "Training": 0,
            "Focus": 0,
            "Class": 0
        }
    }
} 
OR a more succinct version

Code: Select all

{
    "Skills": {
        "Diplomacy": {
            "Ability": "Charisma",
            "Points": 9,
        },
        "Endurance": {
            "Ability": "Constitution",
            "Points": 0,
        }
    }
} 
Of course, the above is a sample. Both options total 9 points of "Diplomacy" skill, however the former breaks this down into source. If you decide to go with the former though, this takes a bit more up front work of combining the values to get to the total points, BUT gives you options. For example, let's say your system has a special rule that allows a skill check in some cases, but not others and the determining factor is "the characters is trained OR has focus in that skill." With the latter, you don't have enough data to know one way or the other. But you do with the former.

So, while thinking about the structure of the macro's upfront can be important, thinking about your data structures is equally important also as it will influence how you code your macros(I would dare say as long as your macros' don't eat to much stack or take to long to run, thinking about your properties structures is far more important upfront. Of course, you could always re-work things, but depending upon how much you plan to automate or not, it's typically a lot faster and easier in the long run to do it right the first time(OR perhaps just go into your first foray with the understanding that you might want to throw stuff away at some point and start over so you can do it the right way... again, depending on how much work you have put into stuff, sometimes it's far faster to throw away what you have and start from scratch..)
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

meshon
Cave Troll
Posts: 75
Joined: Fri Mar 26, 2010 10:54 am
Location: AB, Canada

Re: One big macro, or lots of little ones?

Post by meshon »

jfrazierjr wrote:So, while thinking about the structure of the macro's upfront can be important, thinking about your data structures is equally important also as it will influence how you code your macros
Wise words. I'm still figuring out the ways json objects and arrays can be used. I use them a bit but probably not enough so that's why it is nice to hear the voice of experience. It's really excellent to see other people's code both for style and for new ideas. Thank you!



cheers,
Meshon

Post Reply

Return to “Macros”