Hold on! It says "Roll 1d6 twice". This is probably the confusion, as you should only be rolling it once to get plus/minus, then rolling 2d6 for months.
Ah, I see. I'll get that straightened out.
Are you getting any value out of the Admin (or asTechs) discussion?
Yes, I am.
Solution: Set basic unit types (Mech, tank, infantry etc) with base unit sizes for cash levels and then use 2D6 to deviate forces from standard norm.
That sounds quite a bit like my first draft of the force construction rules, and was my preferred approach because - if it worked - it would give nice control over force size and composition. However, I realized my end result was just an overly-complicated, annoying way of "building whatever you want." I wouldn't mind going back to it if ya'll can fix the problems I ran into:
My first system was intended to allow construction of forces of any size, any unit composition, and any era. To do this, the player would first select a force size and select the desired numbers of various unit types (how many 'Mech lances, fighter points, infantry platoons, DropShips, etc.)
Next, the force would get budgets for unit purchase based on the type of sub-forces. 'Mech lances were given X C-bills per lance, infantry platoons got Y C-bills per platoon, etc. While not a critical element of my rules, I added that to avoid deviating from the initial force size, money had to stay in separate "pots" - 'Mech funds couldn't be spent on fighter funds, for example.
The system got further complicated when you started factoring in unit technology and weight. A budget adequate for a 3070-era assault 'Mech lance would be over-sized for a 3025-era light 'Mech lance, so adjusting for technology and sub-force weight required further rules to set sub-force budgets based on whether your wanted them to be light, medium, etc., and what level of technology they'd have.
Fine. You get nice, neat budgets that scale with the force size and composition and many other things. What was the problem?
The core problem of the whole system was that there were no ultimate checks and balances to limit a player to a particular force size, just a bunch of rules that would only slow and irritate the player. Consider this example:
Bob wants to make a Lyran 9-lance 'Mech battalion. So he looks up the budget for 'Mech lances. In my abandoned system, the budget per lance would depend on desired lance weight and technology. In your suggestion - correct me if I'm wrong - there'd be some 2d6 rolls (per lance?) to give some variation to the budget. Either way, Bob takes that final budget per lance, totals it up for 9 lances, and sets out buying 'Mechs.
Part way through the unit purchases, Bob realizes he's running short of cash. He really wanted that command company of Atlases but after buying those he only had money for two companies of low-end medium 'Mechs and lights. That's not a proper Lyran unit, which should at least also have a company of Zeuses and nothing under 50 tons in the scout company.
But, oh, wait a second. Bob realizes that if he's not getting enough money per lance, he can just get extra lances of 'Mechs and not fill them out. Or he can use an entire lance's budget on 1 'Mech. (If he had a gamemaster this might not fly but Bob, like many BT players, doesn't have a GM for his boardgame-intensive campaign. And asking for approval from the other players in his campaign is a sure thing, since they're hoping to play with that force, too.) So Bob revises his budget to cover 15 lances and buys 9 lances of the 'Mechs he wants. He then ignores the 2 empty companies on his TO&E sheet.The problem stemmed from "pick whatever size you want." When you "Set basic unit types (Mech, tank, infantry etc) with base unit sizes for cash levels and then use 2D6 to deviate forces from standard norm," a player can readily throw budget limits to the wind by changing the size of force. Further, unlike character attributes or unit record sheets (both of which have lots of stats to double-check the math behind a character's or unit's build and consistent restriction), there wasn't a convenient way of checking to see if a military force built with "any size you want" rules was correct. I mean, another player might wonder how Bob managed to build (for example) 100 million CB lances when the biggest lance budget was (for sake of discussion) 40 million CB, but what are they going to do if Bob says he just consolidated budgets for several lances and sold off some junk 'Mechs?
You could add restrictions like "must buy 4 'Mechs per lance" (so players can't try the "1 super 'Mech per lance" trick), and "cannot share budgets between lances," "must be of the designated lance weight class" and "must be of the appropriate technology," but do you think such rules would later prevent a player from shuffling his TO&E to consolidate his favorite designs and isolate the cheap filler units? Let alone invoking unit purchase and sales rules after the start of a campaign to get rid of trash units in favor of smaller numbers of dream team units?
So, when I stepped back and looked at my "any size force" set of rules, I realized it was basically an overly complicated, irritating means of letting players build whatever they want without any real budgetary restriction (despite lots of rules and tables on budgets). The fix for that went in two directions: first, random, limited budgets are the basic force generation system you see in this .pdf draft. Second was a much more honest, compact optional rule that said, "Yeah, build whatever you want" rather than wasting all that word count on easily-bypassed budget restrictions.
Now, Minerva (and anyone else), if you can craft some rules that both allow the construction of a force of any size, technology, and era while making budgets relevant and without the problems I listed above, then I'm all ears.
Providing rules for building OpFors of a set size is something I CAN do relatively easily, since the players building it are probably not inclined to play funny games with the accounting of their NPC opponents. A table with some recommended budgets by unit type should address the issue.