The version from before the last major revision can be found HERE
The original version can be found HERE
----
I commonly get asked after my longer posts "what's the point of your post?" - or something of the like.
In three parts, as short as I can make them:
Every time I've ever observed or engaged in the discussion of "what's the true definition of the MechWarrior video game genre" and/or "what should the MechWarrior video game be based on," and someone says that the BattleTech boardgame ("TT") should should define the MW video game genre or be what the MW video game is based on...
...others inevitably post that the TT doesn't define the genre in any way but "spirit" or "flavor" (don't ask them to define "spirit" or "flavor" - they use these words, but they quite often don't know what they mean by them or can't describe what they mean in understandable ways) ... and that converting the TT to the MW format can't and won't work.
If any reasons why this can't or won't work are offered, they are usually variations on (and mostly limited to) "but .. DICE! RNG! TURN-BASED! RANDOM! It would remove human skill! THAT JUST WOULDN'T BE FUN! If there is any more discussion after these "reasons" are given, it's usually people talking right past each other. Virtually nobody on either side will examine the validity of their basic presupposed ideas - and nobody will define their central terms (or ask the other side to do so). Pretty much all of these discussions I've seen stop at this stage.
So, having the core rule books on hand, Solaris skunk werks, playtime in Megamek, and too much time on my hands, I decided to do what hadn't been done on the forums; actually examine the boardgame rules themselves, and see if they could convert, as a functioning system, over to the real-time first-person human-skill and human-choice based outcomes video game format in a way which would be FUN...
... and see if the so often and so loudly claimed problems actually cropped up. Yes, I know, utter heresy, but I figured, well, heresy or not, someone at least ought to see if the claims are true.
Turns out that these claims are false. This is the first part of "the point."
P.S.: I don't want and am not advocating first-person MW Tactics/MechCommander/Tabletop. If this is all you have to say, you're wrong, and you're not doing your position or anyone else any good. I quite clearly posted "real-time first-person human-skill and human-choice based outcomes video game format," and nothing in the rest of the post negates that.
Moving on:
In the few comments we've seen from the developers about the conversion from the TT to the MW format, they've tended to characterize the parts of the boardgame combat system and converting it to the video game format like so:
- Attacks in the tabletop game would randomly hit different sections of an enemy ’Mech; this doesn’t need to be recreated in a video game because it’s fully represented by the skill of the player"
- "Those factors and those variables take care of having to create this ... this randomness and addresses you know, pilot skills and all the things that exist in the tabletop all the rules that exist in the tabletop game to make the game fair not just say, "I shoot you with all my weapons and I hit 100% of the time" so that's why there are dice in tabletop games is if there weren't you would always choose to do the maximum amount of damage."
- "[DAVID]Attacks in the tabletop game would randomly hit different sections of an enemy ’Mech; this doesn’t need to be recreated in a video game because it’s fully represented by the skill of the player."
- Russ: (in the Three Moves podcast) We get a lot of stuff for free because we are using a physics engine, because we have line of sight, and we have the ability to do raycast and detect whether we are hitting objects. We don't need to create or simulate randomness or pilot skill, so that's one of the advantages we have, ...
- "Zyllos: With many discussions on convergence of weaponry, has there been any discussions on why/why not more variability should be added to weapon fire, thus spreading the damage more across a target?
A: We’ve removed randomness from weapon firing in favor of skill."
- "From Day 1 our goal was to take the TT rules and create a game that reflects the spirit of those rules. Since so many of the TT rules are designed to work around simulating skill and randomness we end up with a situation where there is no 1:1 mapping of damage/hit points from TT to live simulation."
Or
- "[DAVID] While there hasn’t been anything that I would call a great difficulty, the thing that we always have to keep in mind is that we want to capture all of the flavour of the tabletop game but need to be aware of when a direct translation of a tabletop system won’t work for a real time computer game."
There aren't many Developers comments on this topic... but these that we do have, in and of themselves, can be validly understood to say that the hit-location tables (this is a TT combat mechanic/rule) don't have any valid part in the MW video game genre, because the hit-location mechanic just simulates "randomness" (murphy's law), and not anything else.
They also say that to-hit combat mechanic is just there to enforce fairness; to stop 100% hitting all the time, not to simulate anything else.
These things, when combined, render the necessary conclusion that the BattleMech doesn't have a significant part in the overall aiming equation - why? Simply this; because there are no other combat mechanics in the TT game that represent any of the "aiming" that's going on; and they've said that these two combat mechanics are actually pilot/player skill and a simulation of "murphy's law." There's nothing else left that describes any of the weapons aiming - they've said it all either simulates randomness or pilot gunnery skill - nothing about the 'Mech.
If these are not just things they've posted and the necessary conclusions from them, but also what they really think, than the Devs have ... (how do I say it nicely) ... not gotten it right - THIS is the second part of "the point"
(DEVS, feel free to correct me if these aren't how you view these two Combat Mechanics and your conclusions about the 'Mech part of the aiming. I'd rather be fully informed on this, but I can only work with what I have.)
I haven't come to this conclusion lightly. I went into the actual combat rules and looked to see if these statements from the DEVs made sense - are any of the rules contradictory to these conclusions. I even made sure to check with and put the question about what the hit-location table represents to the people who hold the IP on the BT setting, who's job it is to actually KNOW these things.
And just a little bit more:
Because the Devs started by leaving out the part of the TT combat system that simulates the Weapons-aiming that the BattleMech does they've caused themselves problems... problems which have at times been "fixed" in some very non-intuitive ways.
These problems were forced on them because they used numbers that were based around the fact that the Pilot AND the 'Mech take part in aiming the weapons (the TT armor and weapons stats)... in a combat mechanic (FPS/Shooter) that doesn't factor for the BattleMech's part of weapons aiming. The armor numbers from the TT were not designed to work against the FPS/Shooter level of concentration of fire.
So, in response to this, they doubled the armor and internals numbers.
This caused the lower damage weapons to "drop off the map."
In response to the weapons problems caused by the doubled armor and internals fix, they than decided to up the rate of fire on the weapons.
And so on.
This has continued down to where we are at the moment, with ghost heat and comments about possibly desynching gauss weapons in some way. This is the "unintended consequences" effect in action. It's like rabbits in australia.
It's not just me pointing out these problems - the Devs have been too:
Russ Bullock (41:13-42:44) said:
Bryan Ekman said:
A: We don’t have a standard conversion rule of thumb. We ***** each weapon, how it’s being used, what the desired role we want for MWO, and tune it accordingly. With each new `Mech we add, or new feature, we have to reevaluate the performance of every weapon.
These problems in the weapons & damage/armor system wouldn't have happened if they had put the BattleMech's part of the weapons-aiming equation into the game - this BattleMech part of the weapons-aiming was a key part of what balanced out the relatively "high" damage output vs the relatively "low" armor factors in any given location. They could have, instead, picked up the established combat system; with known and predictable outcomes, and saved themselves from this stream of unintended results. This is the third and last part of "the point."
-----
Now for the rest of the post - to start, two basic ideas required to make sense of this post:
In order to see if the conversion from the TT to the real-time first-person human-skill and human-choice based outcomes video game format can work, you need to know a few things before you can even proceed.
First, what's the true definition of the MechWarrior video game genre (what IS a MW video game)? You can't measure your progress towards a goal without knowing your goal!
Second, what things does the definition of the MW genre require? ... so you can actually measure your progress towards your goal.
First, let's define "MechWarrior."
"Mech" - This is shorthand for "BattleMech," an upright walking armed and armored combat unit from the fictional BattleTech setting ("BTU").
"Warrior" A person that "makes war" by doing combat.
So, "MechWarrior" means someone that uses a BattleMech to do combat.
Now for the second part, what does this definition require?
First, a "warrior that does" fictional combat - Thankfully, we can do virtually all of this warrior "gunnery skill" with our computer peripherals... so there is NO NEED to port over the gunnery-skill simulating parts of the TT system. In this case we using our computers ... fill this part of the definition.
Second, a "BattleMech" that operates in this fictional combat as the BTU says it does.
So any video game that wants to live up to the name "MechWarrior" should at least attempt to do these two things.
Now that we have our definition and what it requires, lets start fleshing out the part that has to be converted over - the 'Mech part. To do this, we need to know what defines the BTU, and specifically what parts of the BTU define how BattleMechs work, especially in combat, and how the BattleMech and it's pilot interact to "do combat."
These sorts of questions are commonly referred to in the BT community as "what is canon" or "canonicitiy." Thankfully, this isn't too hard; those who who write, maintain, and define the BT setting have already answered the questions "what is canon" and "what parts of the canon particularly explain the 'Mechs." They even have a forum for asking questions about canonicitiy and how things work in the setting.
For space considerations I'm going to give the conclusion as to what sources further explain these things while putting the original sources in spoiler folds with their source links for those who want to see if the conclusions here are simply opinion, or actually required by the sources quoted.
The short of it; The people who's job it is to define the fictional BT setting have said:
Positively:
The sourcebooks for the BT boardgame/rpg are what defines the BTU in general terms;
The rules in these sourcebooks define how any particular thing actually works in the BTU setting;
The "fluff" text in the source books that specifically talk about what the rules address clarify what the rules mean about those particular things;
And that this process has been in place and operating since the earliest days, right from the start.
So the TT rules about 'Mech combat and operations, as clarified by any "fluff text" about 'Mech combat and operations, are authoritative.
Negatively:
The video games set in the BTU aren't canon. What this means is that they're derivatives of the setting (some more so, some less so). This is not a denigration of the video games. It's just that they're derivative instead of foundational. They are of use as references on how other game developers have implemented things that the canon doesn't address in detail.
About the Novels:
The authors have had to, to the best of their knowledge of the rules and fluff that explains those rules, conform how the BattleMechs "do" combat and how their pilots interact with their BattleMechs in their novels to fit inside of the "box" that the TT 'Mech & Pilot combat & operation rules and the TechManual writeup on BattleMech technology and operation (and the earlier sources that addressed these things) "makes." Obviously, story-line, "cool," and character considerations will at times override this - that's just the nature of the story-format.
So, for those who want the 'Mechs and what it's like to pilot them to be like it is in the novels, following the rules and the fluff on those rules will get you the results you want; because the authors have been following those things too.
So now we know what "MechWarrior" is, and what this requires of any video game using the name... and we know, in general, what sources tell us how the BattleMechs "do" combat and how their Pilots interact with their 'Mechs, let's link the particular sources:
The Plot rules: We thankfully don't need to port these over, for reasons listed above.
The Mech rules: I already have them listed in the post below, under "sorucebook rules" with details in the spoiler fold just below that section.
The TechManual "fluff" knowledge that clarifies these rules: http://mwomercs.com/...gy-an-education
... and specific and very useful information from the sources inside of the spoiler fold just above.
I'm going to go ahead list some of the necessary conclusions from the source book rules (below) and the Tech manual "fluff text" (linked just above) that clarifies those source book rules, along with the information in the first spoiler fold:
We know:
- That the BattleMechs do the "grunt" work of aiming the weapons.
- That the BattleMech physically aims aims each weapon, independently of other weapons and beyond the mobility of any limbs or torso or turret they are mounted to.
- That the BattleMech's Targeting and Tracking computers takes information from the 'Mech's sensor inputs and runs them through software in order to decide where to physically aim the individual weapons.
- That part of a weapon's mass and bulk is taken up by the structures that enable the 'Mech to physically aim it.
- That the advanced Targeting Computer adds more gear that makes this independent actuation more precise.
- That the advanced Targeting Computer's -1 does NOT represent Pilot gunnery skill: "If using a targeting computer to make an aimed shot against an immobile target, apply an additional –1 modifier (representing the targeting computer)" - Total Warfare, Pg 143, left column, Paragraph 4, emphasis added.
- That the AES system allows for more precise motion any limb the system is mounted in, thus making it easier for the 'Mech to physically aim the weapons in an AES equipped limb.
- That the AES -1 to hit for weapons in an AES equipped arm does NOT represent pilot gunnery skill: "The Actuator Enhancement System (AES) is a combination of finely tuned myomer bundles and an enhanced DI computer interface that can improve the workings of a BattleMech’s limbs. In many ways similar to the acuity-enhancing servos and mechanisms tied into enhanced targeting computers, AES components serve to stabilize subtle variances in gross ’Mech movements, which can lead to greater weapon precision or improved balance adjustments. ..." - Tactical Operations, Pg. 279, 1st Paragraph, emphasis added.
- That internal and external conditions affect the BattleMech's ability to concentrate shots under the reticule (to-hit modifiers that don't affect the pilot's aiming ability but DO affect the 'Mech's aiming ability; aimed shots vs mobile targets only possible with an advanced TC - sensor hits, waste heat effects, damage to to the 'Mech's arms, damage to the weapon's individual aiming apparatus, etc).
- That therefore, BattleMechs don't have a god-like ability to get their weapons fire to concentrate against a single armor panel/section.
- That the BattleMech CAN NOT track any target.
- That the BattleMech CAN NOT choose what to target.
- That the BattleMech CAN NOT fire it's weapons.
- That the 'Mech can't do these three things because it's Programming won't allow it to.
- That the 'Mech's pilot, with his cockpit controls, MUST use his weapons joystick to manipulate the cross-hairs on his HUD to do these three things that the 'Mech can't do.
- That this DOES NOT mean that a pilot clicks their desired target, and than doesn't have to track that target.
- That this DOES NOT mean that the pilot has to continue to hold the cross-hairs over their desired target after firing in order to have their shots hit their target.
- That the Pilot AND his BattleMech BOTH participate in the aiming of the weapons.
- That the Pilot (and therefore we, the players) must have all of the same physical skills in manipulating the cross-hairs and hitting the triggers that any FPS/Shooter video game requires.
- That the Pilot, if they wish to be a successful pilot, must ALSO possess knowledge of their 'Mech's ability to carry out it's part of the aiming of the weapons, and how external and internal factors can affect this ability.
- That if the Pilots (and therefore we, the players) do NOT use these skills and knowledge, nothing will get done, because the 'Mech is forbidden from doing these things.
- That the part of the boardgame combat mechanic called the "to-hit" determines if any given overall target gets hit.
- That the to-hit modifier known as the pilot's "GUNNERY SKILL ROLL" describes something that the pilot does, and that the 'Mech does NOT do, and that we, the players, can do with our computer controls.
- That therefore the to-hit GSR modifiers SHOULD NOT BE IN THE GAME, because the game is about letting the players (not the program) "pilot the BattleMech" in any way we can with our computer controls.
We Know:
- That regardless of Mechwharrior gunnery skill, the various NON GSR to-hit modifiers stay the same
- Therefore we know that these non GSR to-hit modifiers represent things beyond Mechwarrior control which they must, by their choices, attempt to account for and overcome.
- That the to-hit modifiers describe things that do not affect a pilot's part of the aiming equation - for example, again, sensor hits, waste heat effects, damage to to the 'Mech's arms, damage to the weapon's individual aiming apparatus, also damage to the 'Mech's T&T computers.
- That the to-hit modifiers describe how easy or hard it is makes any given shot based upon factors outside of the control of the 'Mech's pilot (target movement, environmental factors, etc)
- That therefore these modifiers describe how these conditions affect the BattleMech's ability to do it's part of the aiming.
- That the conditions that change these modifiers are knowable (waste heat, speed, target behavior, how your 'Mech is moving when you pull the triggers, etc).
- That the pilot/player can choose which of these conditions under which they choose to fire under.
- That therefore Player Skill and choices is, again, paramount.
- That which ever of the "hit location" boardgame combat mechanics in use shows exactly what particular part of any given overall target gets hit.
- We know that PLAYER SKILL with their peripherals (mouse/joystick) and PLAYER CHOICES determines WHICH of these hit-location mechanics are used.
- That the hit-location tables mechanic named "called shot" describes a mix of Pilot gunnery skill and 'Mech capability.
- That the "aimed shot" versus mobile targets Hit-location mechanic represents the effects of the Advanced Targeting computer hardware.
- That the OTHER hit-location table mechanics besides these two describe THE BATTLEMECH'S ability to do it's part of the weapons-aiming (this has, in fact, been backed up by Herb, the BT line developer, source and link in the spoiler fold above).
- That the conditions that determine which hit-location tables are used are known, and predictable.
We know
- This means that the complaint that "using the TT combat system in, even in real-time, removes human skill and choices as THE factor" is simply flat-out wrong. There are other reasons as to why this conclusion is wrong, but those are for replies to questions in this thread.
- That in order to master basic BattleMech combat, one need only use their computer peripheral to control the reticule placement, and control their 'Mech's movement to place them in range to make a shot.
- That the pilot/player would be informed of the ease or hardness of any given shot (IE: the total to-hit modifier) by the color-coding of the reticule and audibles.
- That the if the pilot/player wants to have more knowledge and gains this knowledge, this gives a return in gameplay.
- That even if the pilot/player is completely knowledgeable in this and has the best physical skills, if they screw up, the greenest starting player can still beat them.
- That a HIGHLY skilled MechWarrior in the lore can use a SINGLE weapon to make an attack against a specific location versus a mobile targeted mech, WITHOUT using an Advanced Targeting computer:
- "Marksman
- The Marksman Ability enables a MechWarrior ... to potentially hit any desired location on a target. A pilot ... with Marksman can make a special Aimed Shot attack as if using a targeting computer. The pilot’s unit must remain stationary and make no physical attacks during the round in which he uses this ability. In addition, only one of the unit’s weapons may be used; no other weapon may be fired in the same turn. Use of the Marksman Ability is considered a Complex Action.
- The Marksman Ability may be combined with a targeting computer or enhanced-imaging technology; if the warrior’s unit is equipped with such items and they are active when this ability is used, the Aimed Shot attack receives a +2 roll modifier."
- "Battletech, A Time of War - The BattleTech RPG," Pg 220 : http://www.battlecor...roducts_id=2611
- That therefore this results in more depth of gameplay, more reward for skill, while not making the game impossible and unrewarding for new players. Or, in other words, it makes the game more FUN. It also promotes game-replaying.
- The overall conclusion is that a MechWarrior Video game should be attempting to model the to-hit mechanic, attempting to model the to-hit modifiers OTHER than the GSR modifier, that the game should be attempting to model the hit-location mechanic in use in any given condition, in order to be a proper "MechWarrior" video game.
- This would result in a game that gives more reward to player skill than MW video games so far have; that this would give more gameplay depth without running off new players, and that this would make the game more fun...
- This would NOT remove human player skill and choices as THE controlling factor in gameplay results.
Simple - WHICH hit percentages that are used at any time the triggers are pulled are based upon the PLAYER'S skill and choices; and the maths don't allow for nonsense results that have no connection to the player's skill and choices.
I think these are more than enough necessary conclusions from the sources for just one post. Any more that crop up in the thread from replies will be addressed there.
----
I'm keeping this section on the particulars of what human skills and knowledge/choices that a proper MW video game would use/require, but for length's sake, I'm putting it in a spoiler fold. Suffice it to say, that it doing it right by the sources would require MORE than just the human skill that the Shooter/FPS mechanic that MW video games have used so far - without going off the deep end of making the game impossible to play.
----
Now for the Sourcebook rules.
Don't sweat it. They're actually very simple. Do remember that the linked source material "BattleMech technology, an education" and the sources in the first spoiler fold help to explain what these rules mean.
All the boadgame information referenced comes from Either TotalWarfare, TacticalOperations, or TechManual... they're great books, and fun to read even if you aren't going to play the boardgame - buy them if you can:
http://www.battlecor...hp?cPath=27_178
The Tech writeups in TechManual alone are worth the price.
First, there is the "to-hit" combat mechanic.
This mechanic determines if the overall target gets hit. This is "what hits."
It functions like this: When you decide to make a shot, you observe all the conditions occurring in the boardgame that have to-hit "modifiers" attached to them.
These modifiers either make the overall target either easier or harder to hit. Plus modifiers ( + ) indicate conditions that make targets harder to hit. Negative modifiers ( - ) indicate conditions that make targets easier to hit.
You take all of these modifiers and add them up. Yes, simple addition.
You do your to-hit addition for either every weapon fired if you're doing chain fire (this is the normal way of combat in the boardgame) or for group/alpha firing you do the to-hit addition for the least accurate weapon in the group firing in order to determine if the group/alpha hits. Yes, if you've heard group/alpha firing is impossible in the boardgame, you've heard wrong. It's called "linking weapons," page 85 of Tactical Operations.
You than take two six-sided math tools that describe a knowable and predictable range of results ("dice"), roll them, and see if you've rolled equal to or more than the total that the modifiers added up to.
Needless to say, any total to-hit modifier of two (2) or less means it's impossible to miss the overall target; this happens when you perfectly control the cross-hairs in the video game and choose the "perfect conditions" in order to be sure that every weapon hits the overall target." Yes, you can even achieve, if you make the right choices, a NEGATIVE total to-hit modifier. The reticule is color-coded "GOLD" and the audibles for SHOOT! NOW! are playing.
Total to-hit modifiers of seven (7) represent basically a little bit better than 50-50 chances of hitting the overall target. This is a "flip the coin and see if we hit" desperation shot that you otherwise wouldn't try to make, but what the hey, give it a whirl. The cross-hairs are color coded the color exactly between gold and red for this shot. Light orange or yellow, perhaps.
Total to-hit modifiers of eight (8) come up when you make bad choices. Eights are less than 50-50 odds. This would be full-on deep orange reticule country.
Total to-hit modifiers of nine (9) and twelve (12) especially represent conditions that you really shouldn't bother to even try and shoot under, unless you're about to die, eject, or your 'Mech is going to be blown to shreds. Shots in this range that hit are jaw-dropping amazing shots, because shooting on these cumulative modifiers is just plain STUPID. These come up when you really get messed-over by someone else, or you just plain do something DUMB. On a 12, you only have a 2.78% chance of hitting! This is when the reticule is red to DEEP red and the "what are you, a mental midget? DON'T SHOOT! audibles are playing.
As should be OBVIOUS, you can, by your skill and choices, drive your to-hit down to 100% hitting the overall target - this is a human SKILL and human CHOICE based outcome; the difference being that it actually adds the MECH as a factor for human skill and choices to account for.
Second, the basic and advanced hit-location combat mechanics.
These are really simple too.
This combat mechanic determines, for all weapons that surpass their "to hit" totals and "hit," exactly what part gets hit.
First, you determine which hit-location table is proper for the current situation.
If you shot at his front center of mass, you use the front column on the hit-location table. Left uses left, rear uses rear, etc. You than use your math tools (dice) and roll for either each individual weapon you've fired that has hit.
The hit-location tables use your rolls to determine exactly what part gets hit... and you, the player, have determined by your skill with the cross-hairs, and by your choices, exactly which hit-location table is used, by deciding under what conditions to pull the trigger, and where to place the reticule when you pull the trigger. Yes, it's a choice and skill-decided outcome. This is the normal non-advanced hit-location mechanic. The hit-tables are NOT so wide in outcome as to over-ride human skill and choice as THE controlling factor.
The more advanced hit-location mechanics (when using these in the boardgame, you must declare you're using them BEFORE you calculate your to-hit totals, because they can add to the total to-hit modifier).
If you wanted to make your weapons hit a smaller section (high, low, left, right) of a targeted mobile 'Mech, and you don't have an advanced targeting computer, you'd use the appropriate "called shot" hit-location table. Using this adds the to-hit total, representing the 'Mech having a harder time getting all of its weapons aimed at a smaller target, so more of the shots are going to miss; but those that hit do more concentrated damage. To use this, you simply aim at the extremities; there's no mode switch necessary. For example, to aim high, aim at the highest parts of the 'Mech. To aim left, aim at the extreme left parts of the target. Aim at the bottom of the femur joint or lower for "low."
If your target can't move at all, any 'Mech can use the "aimed shot" hit-location table and target a specific location (left leg, ct, left torso, etc) and have a far better chance of hitting that location with multiple weapons. If you're shooting at any section of an immobile 'Mech besides it's cockpit, it's a VERY easy shot (your to-hit total is reduced). Because the cockpit is relatively so small (and for gameplay/fun), if you try and hit the cockpit in this situation, you add to your to-hit total, making the cockpit harder to hit. This mode comes up automatically whenever you target an immobile target.
If you have an advanced targeting computer, you can use the "aimed shot" hit-location table VS a mobile 'Mech, and expect far more of your weapons to-hit the specific location under your reticule. Using this adds to the to-hit total as well, representing the hardness of the shot. Because the cockpit is relatively so small, (and for gameplay/fun) the cockpit can't be targeted this way. To use this, you tap the key to activate the advanced TC, and the more of your weapons fire will concentrate on whatever section of the target you put under your cross-hairs.
If you understand these two combat mechanics, you now have have a functional understanding of the basic combat system in the boardgame.
----
In the spoiler fold below is a list of the various to-hit modifiers, and the actual hit-location tables and their rules in detail, and a "bench performance profile" for a weapon... in other words, the maths that explain the gameplay in concrete terms. If this post has made sense to you so far, reading this section will REALLY fleshes the idea out. If you’ve gotten this far, don't skip it. You'll miss a lot.
For those who disagree with this post, this section gives you the actual maths and the situations they are used under, so you can actually "pick a situation" and see how it would work - pick your conditions, add up your to-hit modifiers, pick your hit-location mechanic, and you have your results.
----
Now for some ideas on how to put this into MWO without having to destroy the basics of what's already been built up and/or do a ton of extra work. For those who are skimming this post, all that would be needed to do the TT combat mechanic would be ... simple addition, and making a choice of a range of numbers, from 1 to 6 and 2 to 12 - things it's possible to do in realtime on a pocket calculator.
From the developers comments, they appear to be using raytracing/raycasting to check for objects between weapons ports and their targets. As I understand this, it basically "traces out" a "ray" of "light" (usually invisibly to the player) and sees if this ray hits something tagged in the game as capable of stopping weapons fire, such as non-destroyable terrain or features. I have been told that this is OBSCENELY expensive in computing power for long-distance real-time traces. I gather you really only want to do long-range raytraces/casts if you absolutely have to. Doing multiple long-range traces is, I gather, killer on computers.
I'm pretty sure they also are using hitboxes. I saw this in MW4 ( Who could forget the Kodiak having an upside down and flipped torso hitbox - you remember shooting through it's gun port, right?); I'm somewhat familiar with it. Basically, there's the visuals you see on the screen, and than there's a much simpler set of visuals (boxes, normally, of differing shape and volume) that "fill out" the 3D volume of what's rendered on the screen, as well as the developers can possibly do without degrading game performance. It's my understanding that when a ray-trace intersects a hit box, the game somehow than "knows" where the trace hit. This is than used to apply weapons damage for direct-fire weapons.
I'm not sure how cluster weapons work (missiles, lbx), but I suspect they use the trace/hitbox and some sort of mechanic that says "when hitbox B is intersected, damage is applied to hitboxes A, B, & C. I suspect there are other ways of doing this.
I have been told that you can do something called a "logic check" that's somehow different than a normal full-distance ray-trace that just checks to see if any of your weapons ports are occluded by anything nearby, and that this is, computing wise, cheaper. This, I am not sure on.
I've also noticed the DEV's making comments about how a large volume of weapons fire generates a lot of network traffic. Not sure why this is; and I don't think they'd be wise to tell us, for reasons of security VS impudent hackers.
This is pretty much the extent of my understanding / suspicions of how the game back-end is set up and forms the basis of what follows.
"Doing" modified weapons recycle times - If you use the TT stats in the TT mechanic in real-time, it should be possible to modify the recycle times and keep the weapons profiles the same if heat is added/subtracted based upon how much slower/faster the weapon fires than once every 10 seconds. This should be viable because heat is actually the one mechanic that controls the "can I fire this turn" and "if I can fire, can I do so successfully" for all weapons on a 'Mech. Even for super-low heat weapons balanced by other factors than their own heat output, they are still affected by heat. This would mean you could set the heatsinks to dump 1 pt heat per ten seconds for a SHS, and 2 pts heat per ten seconds for a DHS. Than, because you'd already have the conditional tools in place, you could implement the heat penalties that overheating has in the waste-heat scale that goes up to 50pts waste heat. If you wanted more, add in the advanced stuff about coolant fluids breaking down.
Balance RE: Target 3D volumes/cockpits - using the TT combat mechanic like this would stab this balance-vampire in the heart with a silver-coated garlic infused redwood.
"Doing" the to-hit - put the to-hit mechanic and modifiers in a database in the server side. I suspect that the server already collects virtually all of the data necessary to determine all the modifiers. Than it's a simple matter of the server doing the addition. Possibly add detection for where a 'Mech is on a map if you add things like the "in heavy woods" or "in EM interference" modifier. If the "logic check" is true and something that can be done, the client can also tell the server if it's in "partial cover," which imparts a +1 to-hit modifier for half to 3/4 cover. If you can't, if it is possible to have the client send facing/orientation + location on the map to the server, it should still be possible to determine partial cover; which would require some more rules in the server-side conditional database.
"Doing" the hit-location - if it's at all possible, code the planes (faces) of the hit-boxes so that when a ray hits it, it also tells the game engine/server/whatever *which face* has been hit. If this isn't possible, you'd want something equivalent. Failing this, you still at least know which hitbox has been intersected, so if the aforementioned facing/orientation data is possible, it with some database rules would probably cover here. This gives you the necessary data to determine which hit-location table to use. The "called shot" hit-location tables are used when extremities are intersected by the trace. The aimed shot hit-location is used when a trace hits a 'Mech that is immobile (CAN NOT move). The aimed shot vs a mobile target using a TC is "known" by the mode switch being set "on" and the trace hitting the desired part. The advanced hit-location mechanics automatically set the to-hit database to add their modifiers.
You'd also want to add a few new hit-location tables for things like 'Mechs minus one/both arms, minus torsos, that sort of thing. I'd say, minus one arm, start out with a table with the same hit percentages and no to-hit modifier. Minus both arms, add +1 to the to-hit. Minus both arms and one torso, test having it either be +1 or +2. Minus both torsos and both arms, definitely use +3. Do similar for legs that have been blasted off. If you wanted to be really evil, you could build a hit-box that sits in the "hole" from where the arm was blasted off which, if targeted, gave, say, a +3, +4, maybe even a +5 to hit, but if you hit it, you do damage directly to the internals of the section the hole is in. You'd probably also want to add a hit-location table for 'Mechs that are "chest to chest."
If you have a way of tracing/checking for port occlusion and LOS that works for ALL ports on a 'Mech, you could possibly do a single trace, pass off the "what weapons fired" data all as a single packet, and the database on the server side could easily and quickly calculate the to-hit and hit-locations for the weapons fired. This just might knock down on your weapons fire network load. I presume the server is already what calculates and hands out damage anyways. I expect that if the server is handing out damage that you have the damage packets and network routines obfuscated out the wazoo for security purposes. (Too bad a VPN would be so hard to setup!)
As for the database that I've mentioned - it would just be a conditional database that does the simple math that whatever switches have popped up from client-side data require. The basic combat system is darned simple and is basically "does it hit" and "if it hits, what does it hit." It would have to do simple addition for the to-hit, and than a 2d6 roll against that result. Than it'd do another 2d6 roll on the appropriate hit-location table, and spit out the result to the client. I imagine it would be so simple that you could even know beforehand how any new conditional or weapon would behave in implementation by doing a simple "run everything, give results" test. A sort of complete I:O on the database, and than look for nonsense or undesired results and the conditions that triggered them. Virtually every single condition is in the four core rules books in the tables; I bet with a minimum of man-hours the basic data could be input. Heck, you could probably just wind David. B. up on a few cups of double-strength cuban coffee and just get out of the way. He might even enjoy it. If you're really insane, you could ask the guys at catalyst if you could borrow their fact checking/testing people for a few hours to double-check the database. They could probably do it in their sleep.
For oddities that crop up caused by the hex-format, some reference to the Miniatures combat rules that don't use hexes would probably be enlightening.
"Doing" lock times - There are the basic outside time parameters. We know that all the things that can happen in a turn must happen in less than ten seconds. The solaris box-set somewhat changed this, but it's been so long since I read it, I've forgotten most of that stuff. I seem to remember a 2.5 second turn. I don't remember what else that ruleset changed. This would fall into the "set some initial parameters and test it" area. IMO, a good weapons lock time would be around 2.25 - 3 seconds, under normal conditions. "careful aim" would be 10 seconds per -1 modifier, up to -3 max. I would say 1 to 1.8 seconds would be the lower limit, this being used to map for "opportunity fire" type snap shots. All in all, this would be sort of like how I bet you guys have decided on torso rotation speeds and accel/decel rates for the 'Mechs.
"Doing" physical combat - it'd be done just like normal weapons fire. I suspect this would kill the physical combat boogeyman.
"Doing" weapons - what's to do? Just stick them in the DB. Results would be known beforehand. No more need to re-assess all of the weapons and the combat mechanic every time you add a new weapon! You'd be working with a known quantity/quality.
"Doing" penetrating/critical hits - if the basic combat system is used, than the critical hits mechanic, along with the advanced critical hits rules, would drop right in, with predictable (and easily tweakable) results.
Yes, there's a good bit of "IF" in this last section, and I'm not sure if the DEV's could reply in any sort of detail without revealing all sorts of things that would be ... bad ... to reveal in public. Still, here it is. Swing, batter batter Swing...
Edited by Pht, 15 September 2013 - 10:22 AM.