First MekHQ splash art piece complete

December 30th, 2011

That is the artwork for the loading screen. It was done by Anthony Scroggins, aka Shimmering Sword. I think he did a fantastic job. If you want to see this image in your game right away, download this art, rename it mekhq-load.png and put it in data/images/misc.

Taharqa MekHQ

Donation goal reached!

November 25th, 2011

We have reached the goal of $270 for the MekHQ splash screens. Thank you to everyone who contributed. I have already commissioned Shimmering Sword to work on the art. He is a bit back-logged at the moment, but I hope to have at least one available by the next release or the release after.

Again, thank you to everyone for your contributions.

Taharqa MekHQ

Help make MekHQ prettier

November 9th, 2011

Ok, its been a long time since I last posted, but I have been very busy with MekHQ (not to mention Real Life). One thing I have wanted to do for the next release of MekHQ is to create an proper startup screen and loading screen when users start up the program. I finally got around to doing that, but one problem remains: I have zero art skills to create some nice opening art on these screens. That is where you come in. I have asked around about the price of commissions with some deviantArtists and Shimmering Sword has agreed to come up with some nice opening art screens for $135 a shot. So if you ever have thought about contributing to MegaMek or MekHQ, but didn’t know how, this is your opportunity because all we need is your money!

To give an idea of how these screens would look, I am posting up a couple of mock-ups with existing art. This will NOT be the art of the final product.

To donate, you can use the donate button on the sidebar or the one at the bottom of this post. I should make clear that you are not donating to the MekHQ or MegaMek program directly, but rather specifically to the commissioning of two art pieces that will be used by these programs.

Thanks for your help.







Write your comment within 199 characters.

Taharqa MekHQ

TO&E anyone?

May 1st, 2011

Still a work in progress, but JTrees are pretty cool.

Taharqa MekHQ

MW2.MINE: Design Goals

February 25th, 2011

I am continuing to work on my own home-brewed battletech RPG, but most of the work is scattered on various notepads or swirling around in my head. I was in the middle of working out a long post regarding my thoughts on opposed check mechanics, when I realized that I was implicitly relying on some design goals to make my arguments, even though I have never made those design goals explicit. Given that my major criticism of aToW is that it seems to have no coherent design goals, it is a bit hypocritical to not be more explicit about my own design goals. So after giving it some thought, I have come up with six explicit design goals that I am trying to follow as I develop MW2M. These are core principles that I think are necessary to make a mechwarrior RPG work, and for the most part they are principles that I believed have been overlooked in previous iterations of the RPG.

#1 – Mechanics should parallel those of the Battletech game, whenever possible

Players should be able to transition fairly seamlessly between the board game and the RPG. The lack of parallel between 3E and the board game was undoubtedly its greatest failing. While ATOW did move back to a 2d6 for the RNG, there is still a huge disconnect between the board game and the RPG. The most glaring issue is the decision to use an “add skill to the dice roll and compare to a difficulty number” resolution system rather than the “roll greater than or equal to your skill plus modifiers” resolution system that Battletech uses. While it is true that the two approaches are mathematically equivalent (more or less – see my next post for details), the aesthetics are different. Players shouldn’t have to do extra cognitive work every time they step in or out of the cockpit to remember which mechanic they are using.

The parallels should go beyond just the mechanic, however. The most obvious case is that of the combat modifiers which should mimic those of the board game, so that an experienced Battletech player will know precisely what the mods are for shooting at long range while running, for example. In general, when faced with a design decision, I am looking first to see if there is a solution that can be found in the mechanics of the board game. A prime example of this approach is my decision to use the cluster hit table to resolve auto-fire, in a way that is parallel to the method for RACs and UACs in the board game. Another example would be the use of a “6 hit” system to track damage and an associated KO check that mirrors the KO checks of the board game.

#2 – Every point of difference matters

The most challenging aspect to creating a Mechwarrior RPG is the fact that the underlying skill ranges in the board game are fairly small: three points separate elite pilots from green pilots. In addition, the 2d6 has a limited range and variance which means that small differences in TNs can produce big difference in the probability of success, as anyone who has played the game knows. Thus, differences in skill and attribute scores should reflect substantial differences and they should matter for outcomes. You should expect a character with one higher skill level or one or more point in an attribute than another character to win significantly more opposed tests against that character.

To use a term that is popular in game design, a Mechwarrior RPG cannot be built around “granularity.” You cannot quantify small differences in skills and attributes between characters. Some people see granularity as very important to an RPG, but I tend to think it is overrated. Small differences in skills and attributes translate into small differences in the probability of success, and given that few skills are used with a very high frequency in any given game session, you are actually very unlikely to see the difference matter. Its a small N problem. If one character’s probability of a successful diplomacy check is 5% higher than another character’s, and you only roll diplomacy checks 3 times in a gaming session, then it is reasonably likely that the character with the lower diplomacy score will succeed as much or more often than the character with the higher diplomacy socre. This has frequently been my experience with low-to mid-level d20 adventures where the difference in skill bonuses between characters are so small relative to the range of the 1d20 that rolling checks like listen, gather information, and diplomacy seems like a total crapshoot. You would need 100′s of rolls to really be assured of picking up a difference of less than 5%, so even for combat skills such granularity is often more for purposes of fluff – that is it makes the person with the character sheet “feel” like there is a difference – than for real differences in play. This ultimately just creates a sense of dissatisfaction that the differences in fluff don’t actually come out in play.

So I actually like to have big differences in scale between attributes and skills, and returning to design goal #1, it better matches the board game as well. The tricky part is that you have to be careful to represent those differences properly in all aspects of the game, not just in the core mechanic. For example, right now I am trying to decide how strength should affect melee damage and I need to do it in such a way that a 1-point difference in Strength actually produces a substantial difference in the damage bonus.

One of the big potential problems with non-granular systems is that power creep can get ridiculous. This has been a problem with every edition of the Mechwarrior RPG. My favorite example from MW2 is the bartender template from the Null Set adventure that had maximum scores on LRN and CHA. The problem is that the GM wants to ratchet up the bad guys a little bit (make this bouncer stronger than the other one for example) and they do this by bumping up attributes. Pretty soon, they have topped out the distribution and every two-bit thug has maximum STR and BOD. So its important to keep some benchmark in mind for how common various attribute scores and skill levels are. ATOW has taken the opposite approach. When I asked someone to stat out the Black Widow on the boards in order to get some benchmark of what a really incredible character looked like, I got a bunch of flak from the developers and their sycophants that it was inappropriate to stat out named characters. Apparently, they don’t really get the idea of providing benchmarks. They also might be afraid that such attempts will only point out the flaws in the system.

Of course, another problem with non-granular systems is that they can be very tempting for min-max munchkins. Which brings me to the third design goal:

#3 – You can’t stop munchkins, but you can discourage them

The potential for munchkinism is inherent in any system, but it is particularly problematic in a mechwarrior RPG. For the most part, people want to play mechwarriors (duh) and who doesn’t want them to be badass? Given that only two skills define a mechwarrior under the board game rules, its fairly easy to min-max any character creation system to get ridiculous gunnery and piloting scores. Herb’s official response to this issue in ATOW was basically that its up to the GM to prevent munchkinism. While I agree that its ulimately up to the GM to set limits on characters, handing the GM a game system that is ripe with the potential for munchkinism is a bad idea. Putting the blame on GMs for bad game design is insulting.

I am doing two things to reduce the impact of munchkinism in MW2M:

a) Non-linear costs for skills and attributes.

It seems that linear point-buy systems are nearly universal in RPGs these days. By linear, I mean that increasing a skill or attribute one level requires the same amount of points regardless of where on the distribution you are. Linear point buy systems have the advantage of ease of use, but, as a statistician, I hate them. If we think that attributes and skills are distributed in something like a bell-shaped fashion, then linear point buy systems make no sense. It should cost more to move to the highest pinnacles of skill and ability than to move from average so slightly above average. Non-linear costs also reduce the impulse to munchkinism because jacking your character up very high in one attribute/skill area has much more serious costs on the rest of your attributes and skills.

b) More attributes and every skill uses multiple attributes.

MW2M uses eight basic attributes. Thats a lot of attributes, and it is moving in the opposite direction of many RPGs these days which seem to be trying to reduce the number of attributes. Furthermore, every skill requires the use of two attributes. There are a couple of reasons for this design decision. First, I actually like having more attributes as it allows for more differences between characters in a system where granularity is low (see #2 above). For that same reason, using two combined attributes to actually get TNs for the game allows for a great deal of diversity in the actual derived characteristics of each character. There are 28 total derived characteristics that can be created by combining two attributes together. Second, this diversity makes it much more difficult to min/max character creation.

Take, for example, the attributes important for a mechwarrior. Gunnery is determined by DEX+RFL and piloting is determined by ITU+RFL. Furthermore, KO checks are made based on BOD+WIL. So five of the eight attributes come into play when determining the quality of a mechwarrior, and thats leaving out additional issues like leadership and tactics. Its much more difficult to munchkin five attributes than it is to munchkin one or two, especially when attribute costs are non-linear. Admittedly, RFL is the obvious attribute to target for a munchkin, but I am counteracting this by making RFL much less important in other areas of the game like skills than DEX and ITU.

#4 – Lethal, but playable

Given the aesthetic of the Battletech universe, I want combat to be fairly “gritty” and lethal. Unarmored characters should be able to be taken down (not necessarily killed) with one or two gunshots. Lethal RPGs can be problematic, however. The irony is that lethal RPGs often have some of the most interesting and realistic combat rules, and yet they are precisely the RPGs where PCs will avoid combat the most. For my own purposes, I don’t necessarily plan in having a lot of combat outside of mechs, but I still want the combat system to work. There are two ways that I think you can make lethal RPGs still playable:

1) The difference between PCs and NPCs isn’t hit points, its edge.

In Hollywood movies, the  heroes typically don’t shrug off a bunch of hits when they face the bad guys, they just don’t get hit. They don’t get hit not because they are much more elusive targets, but because they are the heroes. This kind of dynamic is best emulated in an RPG by giving the PCs (and some important NPCs) access to edge points (or bennies/fate points,etc.) that can be burned when something bad happens to them so they can say it didn’t happen. Edge points are finite, so dramatic tension is maintained, but it also gives PCs the confidence to engage in combat instead of running from it.

2) Gratuitous use of red shirts.

This is a military-oreinted game, so it makes sense that when PCs engage in combat, they will often do it as part of a larger unit. This gives the GM access to a host of red shirts that can be used as damage soakers by the GM and PCs. Dramatic tension is mantained because people are still dying (and the PCs might like to keep some of those red shirts around) but the PCs can be given the opportunity to be the “last men standing,” so to speak.

#5 – Human-focused, but capable of scaling

I think one of the hardest design issues in RPGs is allowing for scaling between characters that might have vastly different abilities, within a limited RNG range. You want your system to produce differences between humanoid characters for instance since a lot of interaction will be between such characters, but you also want to be able to throw in the occasional elephant or dragon. A mechwarrior RPG is more human-focused than most, but I still want to be able to throw in the occasional giant alien bug-thingie and have it work.

This is particularly difficult when we have a narrow RNG because its easy for some creatures to completely jump off the RNG. What should an elephant’s strength be, for example? And can I design an opposed check system that allows for elephants to pretty much always beat humans at strength checks, but that still allows variability between say an elephant and giant alien bug-thingie?

One way I am thinking about handling this is to allow for multiplicative scale effects in some areas. So attributes might top out at say 10, but size differences between characters might produce a “multiplicative” effect on physical attribute checks. Another example, would be animal intelligence. Animals might have regular intelligence scores, but when doing opposed INT checks against human characters they would be a multiplicative level lower. Thus, you don’t get into the problem of tying a skill like “tracking” to intelligence. I am still working out the details of how the multiplicative effects would work.

#6 – Usable by non-RPG campaigns

A lot of people like to run full-scale Battletech campaigns that allow for character advancement and specialization, without running a full-fledged RPG. I am running one now, for example. I want to make the RPG system for character creation and advancement useable to these types of campaigns. That means establishing a couple of things:

a) XP accumulation for missions and downtime

I need a set of rules that govern how XP is gained both for taking part in a scenario, and for downtime between scenarios. I plan on splitting skills into “sets” and XP in combat will be applied to a certain set, while XP between scenarios will be applied to a “general” set. The general set can then be used to purchase skills in other sets either at double/triple the rate, or by converting it into XP in that set through training.  The details are still being worked out, but the idea is that I want to allow for the advancement of both btech related skills (boardgame and campaign ones like leadership, tech, negotiation, etc.) and “fluff” skills without making the character necessarily pay for buying fluff.

b) The use of non-combat skills

I need a set of rules that governs how certain important non-combat skills like negotiation, scrounge, leadership, etc. can be used in the campaign context outside of the combat situation.

Taharqa MW2.Mine, RPG Design

Watch For Landing Dropships

December 9th, 2010

Yeah, that is pretty much what it looks like. Landing dropships are coming to MegaMek. Watch that proximity damage.

Taharqa MegaMek

New look for My Monkeys campaign

August 2nd, 2010

Over the past few days I have been testing out a wonderful little PHP/MySQL program developed by Juho Savela (BitterOne on the BT boards). The best way to describe it is as a content management system/blog for organizing a mercenary campaign. You can see his campaign here. After much begging and pleading, he agreed to send me a copy of his files, so I could use them on my own campaign.  I am still fiddling around with it, but you can check out the new look for the Flaming Devil Monkeys here. I will be posting all campaign related stuff there rather than on this blog in the future.

We have also started up a sourceforge project for this little tool and we will be working to make the thing a bit more flexible and generalizable. I also want to add several features myself.  Enjoy.

Taharqa Flaming Devil Monkeys, My Campaigns, Projects

The CGL Situation

May 21st, 2010

As I write this, the hearing in Seattle today on Catalyst Game Labs’ future is about to begin. For those who have not been keeping score, three parties are seeking for force CGL into bankruptcy in order to recover money they feel is owed to them. In dollar terms, the primary claimant is Wildfire Press, the creators of the CthulhuTech game, who claim that CGL has not paid them royalties which they claim amount to $37K. The second claimant is Paul Stansel, the father of David Stansel-Garner (a former CGL employee), who gave CGL a $20K loan. The third claimant is some guy named Sugarboard who claims that CGL owes him money for work (not freelancing). The underlying action (catalyst?) that set all of this in motion was that Loren L. Coleman, one of the co-owners of CGL, took out a rather massive amount of money (no one knows exactly, but most guess somewhere upward of $600K) from CGL’s warchest through unauthorized withdrawals, and that has left the company capital-depleted and unable to pay all of its debts in a timely manner.

CGL has a response to all of these claims, but at this point its basically “he said, she said” and only the production of documents and testimony at the hearing is going to sort out who is right and who is wrong. So, at the very least, there is a non-trivial probability that CGL will go under, making the debate over the license renewal a moot point. Of course, it will probably take some time for the court case to sort itself out, so the waiting game begins.

I have been silent on this blog about the CGL situation. Some people might have seen a few of my posts on the various forum threads where this crisis is being discussed, and likely have tagged me as “pro-CGL.” That is probably truer than the alternative, but the honest reason why I have remained (mostly) silent is that I am (1) very ambivalent about the whole mess, and (2) I think it is best to withhold judgement in the absence of facts. The rush to judgement by many in the community (particularly the Shadowrun community) has really bothered me, and I can’t help feeling that some level of schadenfreude is involved.

What I find particularly irksome is the tendency of some to declare anyone currently affiliated with Catalyst Game Labs a “bad guy.” It is worth noting two things here. First, the only inappropriate (that’s right, I will not call it “embezzlement”) action here was on the part of Loren Coleman. Second, the people most negatively affected by this action are the other people still at CGL (owners and employees). The only real negative outcomes for fans are publishing delays and the uncertainty associated with the transfer of the license to a new company. The single person most negatively affected by all of this is Randall Bills (because it was his share of the money as a co-owner that Coleman dipped into), and yet he has probably taken more flak on the boards than Coleman himself.

A lot of the hostility is directed at Randall because he is letting Coleman remain with the company rather than canning him. This critique, of course, ignores the fact that Randall can’t get rid of Coleman, because they are co-owners of the company. As I see it, his only real alternative would be to reform a new company without Coleman and compete for the license. But he doesn’t actually have the capital for that does he now? If people would read between the lines here, they would see that Randall is doing his best to save his company in a strategically sensible fashion, moral issues of right and wrong aside.

The bottom line is that, whatever we may think of Coleman’s actions, it is in our best interest (as fans) that CGL survive. I will admit that I have my concerns about the future of CGL with Coleman still at the helm. Even if he has reformed, as Randall claims, CGL’s reputation is sullied as a result of his actions. At the very least, CGL is going to have difficulty acquiring licenses to publish other people’s games after their experience with Wildfire.  And the loss of capital is going to create more delays in getting books published (although if that applies to A Time of War, I can’t say I will be disappointed). On a pragmatic level, however, I am 100% hoping for CGL to recover and prosper in the future, rather than rooting for their demise out of some misplaced sense of honor and justice. I am not an aggrieved party, and neither are any of the fans bitching and moaning on the boards. I don’t know what exactly transpired, I don’t know exactly how it is being resolved, I don’t know whether the Bills family will still send the Coleman family a Christmas card, and frankly its none of my business. What does matter is that (1) CGL has been producing great material for Battletech, (2) they have reinvigorated the brand, (3) they have been supportive of MegaMek, and (4) they will never mistreat the universe because they are its biggest fans. Why would I want to risk all of that on a new company that might give us a new version of clickytech, or worse yet, let the license lie fallow, or even worse yet, send MegaMek a Cease & Desist letter? The answer is that I shouldn’t and you shouldn’t either. Let the parties that were actually affected by this fiasco sort it out themselves, and keep your fingers crossed that CGL comes out of it alright in the end.

Taharqa Battletech

MW2.Mine: Autofire

February 2nd, 2010

Ok, I have been thinking a little bit more about autofire. In my previous post on damage, I decided to stick with the “MoS multiplier” that aToW and MW3e used to deal with burst fire. However, after thinking about this some more and looking at how a variety of systems handle automatic fire, I have decided to develop some more specific rules about autofire.

It seems that every system handles autofire a little differently and gun nuts tend to complain bitterly about the way it is handled in most systems.  A lot of early systems just made to-hit rolls easier when using burst fire, which isn’t quite right because burst fire actually tends to be quite inaccurate.  Concentrated burst-fire is more about stopping power (i.e. putting a bunch of bullets in the other guy rather than one) and “bullet spraying” is more about suppression than an honest attempt to hit anything. The most common technique in most existing systems is to add some kind of damage bonus for burst fire to simulate the stopping power and then to add on some option for suppressive fire.  The problem with the first approach is that increasing damage artificially improves armor penetration in most systems because you do more damage on a single attack. Now I am by no means a gun nut. I have never even held a real gun, much less fired one. So most of my knowledge here is about what others have said. That having been said, here are my goals for autofire in MW2.MINE:

  1. A system that provides players with several tactical options that allow for more interesting gameplay, without adding needless complication.
  2. A system with a sense of versimiltude without getting into the nitty-gritty details of real-life modern warfare.
  3. Distinguish a full burst that might be fired at multiple targets or a single target, from a short concentrated (typically three-round) burst mode.
  4. Integrate double-tap rules into autofire rules.
  5. Allow for a suppressive fire option.
  6. Make burst fire powerful, but not an auto-kill in most situations.
So here are the rules I came up with:

Taharqa MW2.Mine

MW2.MINE: A solution to the Piloting/Gunnery problem

January 19th, 2010

One of the most difficult things for any RPG translation of Battletech to manage is the translation of the one unit difference in piloting and gunnery skills to a generic skill system.  For example, a mechwarrior of “regular” skill level has a gunnery TN of 4, but a piloting TN of 5.  How do you re-create those two different target numbers when the underlying skill levels are supposed to be the same?  Both MW2 and aToW implicitly assume that a regular pilot actually has a higher skill level in Gunnery than in Piloting, which is fairly unsatisfying, and also makes it difficult to “benchmark” an average skill.  MW3 just translated the 0-10 rpg skill levels to battletech skill levels more slowly for Piloting than for Gunnery which was a total hack.

I ran into the same problem in my initial post about MW2.MINE.  But I think I may have a solution to the problem. The solution is to change the two linked attributes for Piloting from DEX/RFL (agility) to RFL/ITU (reaction time). I think its reasonable to argue that reaction time is a better measure of natural ability in regards to piloting and driving than is agility.  After making this change, let me present once again a template for the average mechwarrior character: Read more…

Taharqa MW2.Mine