Jump to content

Weapons Fire Resolution ("convergnce") - A Different Idea.


143 replies to this topic

#1 Pht

    Member

  • PipPipPipPipPipPipPipPipPip
  • 2,299 posts

Posted 29 November 2011 - 04:43 PM

EDITED: 2013-08-30 Edited for orderliness and clarity.

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"
Or
  • "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."
Or
  • "[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."
Or
  • 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, ...
Or
  • "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."
Or
  • "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."
What does he specifically mean by "the spirit" of the rules?

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."
"flavour" - another open-ended ambiguous word - we don't know how this might modify the rest of his statement - this is why people ought to define their central terms.


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:

...but that's also a disadvantage in the sense that we now have to balance every time that we introduce a new 'Mech or a new weapon,...


Bryan Ekman said:

stjobe: Every ballistic weapon has had about a 50% increase in damage per ton of ammo, except for the MG, which got an 80% decrease in damage per ton of ammo. What was the reasoning behind treating the Machine Gun differently from all other weapons in the conversion from BattleTech to MWO?

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.
http://mwomercs.com/...evs-34-answers/

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.

Spoiler


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.
We know that this "grunt" work is:
  • 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.
We know:
  • 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).
We know:
  • That therefore, BattleMechs don't have a god-like ability to get their weapons fire to concentrate against a single armor panel/section.
We Know:
  • 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.
We Know:
  • 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.
We know
  • 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.
We Know:
  • 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.
We Know:
  • 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.
We Know:
  • 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.
We Know:
  • 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.
We Know:
  • 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
We Know:
  • 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.
Therefore:
  • 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.
Why would this not remove human skill (and choices), when obviously, there are hit-percentages used? (the ever evil and heretical idea of "dice" or "random" - Hide the children! :lol: )

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.
Spoiler



----


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. B)


----


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.

Spoiler



----

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... :o

Edited by Pht, 15 September 2013 - 10:22 AM.


#2 Mchawkeye

    Member

  • PipPipPipPipPipPipPip
  • 883 posts

Posted 30 November 2011 - 02:09 AM

Okay...I can really appreciate the depth you have just gone into there.

I understand what you are saying but some things speak to me:

Your use of hexes, amongst other things, suggest that you are more concerned with the TT rule set than a simulator. You seem to be simulating the TT rather than a mech. I have said before, and will happily say again, the TT rules were designed for a TT game, they were not designed for a Video game; appropriating the inherent randomness from that rule set and featuring it into a simulator will make for a very frustrating simulator. The challenges from TT rules and VG rules are very, very different; they came to those conclusions for the sake of the wargame balance; to adhere to those rules in the VG would be to ignore fundamentally what those rules were designed to do in the first instance; that is to say, a VG with those rules would be unbalanced.
While I have no doubt that what you describe would be an accurate representation of piloting a battlemech from a TT point of view, it would make for a deeply annoying game; I think people need to feel in control of their mech, not as you suggest, simply give the mech a decent idea of what you want to achieve and let it sort of the rest. There are places where Mechwarrior will need to move away from the TT and this is one of those things, I think.
Following from your example at the end of your post, if I had six lasers at a paltry 210m, all of them should hit. They are lasers. and I can spit 210m accurately. Now if the ranges were to change between the TT and the VG (which I really hope the do) your example might be resonable (say 800-1000m?) if not I, and I suspect many others, will call it broken and go back to playing with ourselves.

Edited by Mchawkeye, 30 November 2011 - 02:10 AM.


#3 Xhaleon

    Member

  • PipPipPipPipPipPipPip
  • The Money Maker
  • The Money Maker
  • 542 posts

Posted 30 November 2011 - 03:19 AM

Oh god, that one's a bit overboard, Pht. I'll stick to cones of fire, methinks. You can translate the TT rules into real time that well enough if you don't directly take the (calculated) percentage chances to-hit, which are a bit too inaccurate.

I'm not sure how this is supposed to play out by your description of gameplay. Is this based on a designated target system where the game does everything for you after you select a target to fire at (and do so)?

#4 guardiandashi

    Member

  • PipPipPipPipPipPip
  • 255 posts

Posted 30 November 2011 - 07:54 AM

what he was getting at is TRANSLATING the tabletop game stats into their "sim" equivalants

IE short range (not minimum) range band is actually the "optimum" range to hit with the weapon in question its where the sight and aiming controls of the weapon are "good enough" that the "accuracy standards" of the weapon do not override the limits of the aiming systems.

medium range is where the accuracy standards are starting to affect the accuracy limits of the aiming systems

long range is where the accuracy standards start making the aiming accuracy almost a joke

extreme range the accuracy standards mean aiming is a best guess

los range you almost might as well point the weapon and fire in their general direction (thats effectively what you are doing) hitting is not the rule it is the exception

real life translations of some of the target mods

+1 to hit due to walking/crusing your crosshairs bounce enough that your aimpoint can traverse most of the way across your target with each "stride"

+2 penalty to hit due to running your crosshairs bounce clear across the target IE go from aiming clear of the right arm/leg to clear across the target and past its left arm/leg

+3 penalty to hit due to jumping your crosshairs move enough that even if 2 of your targets were standing shoulder to shoulder (or on top of each other) your crosshairs would STILL traverse clear across them.

explanations of terms

inherant accuracy the "accuracy" limits of a particular weapon system Fact in the real world NO weapon is always 100% accurate with every shot. it may be 100% accurate within a margin of error, but never 100% perfect. IE you take gun X mount it on a fixed mount where the gun cannot/willnot move when fired, and you fire off 10 rounds you WILL get 10 holes in the target not just 1, at say 10 ft the 10 holes will be 1 slightly larger hole, at 50 ft they will all be within a 1 inch circle, at 100 ft they will be within a 4 inch circle etc

accuracy limits, how precisely you can adjust the aim of the weapon ie can you adjust the aim of a weapon at say 50 ft, 1/4 inch at a time, 1/8 inch, 1/2 inch, 1 inch, 1 ft, or whatever

attacker the person firing the weapon

defender the person getting shot at

back to arguement

some of the situational modifiers can be translated as (attacker) gets his sights "jarred or misaligned" due to whats happening

some of the defensive modifiers can be translated as (woods) provides enough "cover" that you are having a harder picking the target out of the background light woods up to 10-30% of the target is obscured, heavy 20-60% of the target is obsured superheavy 30-90% of the target is obscured for instance.

the "cone of fire" represents especially if tied to expanding cone options and individual weapon "tracking" an approximation or a method of taking these variables into account, and representing them,

#5 Mchawkeye

    Member

  • PipPipPipPipPipPipPip
  • 883 posts

Posted 30 November 2011 - 08:58 AM

ok...but +1 what?

on the TT, that's +1 to a dice roll within a very specific set of parameters ie: dice probability.

Dice probability is not appropriate for this game.

Although if someone explains what 'accuracy' means, and how modern weapons are not 100% accurate... well then I don't know what...but something....

We get it. We really do. We understand already. it's just that some people think that that level of inaccuracy wouldn't be good for the game, and other, like me, feel that levels of accuracy should be defined as much by the nature of a simulator (+1 for moving? I already am, aren't I? hasn't that inherently affected my accuracy?) and a sense of what the table top suggests as opposed to running the numbers and stats from total warfare as be all end all.

#6 guardiandashi

    Member

  • PipPipPipPipPipPip
  • 255 posts

Posted 30 November 2011 - 11:56 AM

GAH it ate my post

basically I am thinking of a syatem that assigns a modifier to an equavalant amount of size/measurement on the screen

example you have a mech that is in game 12 meters tall and at 100 m from the unit on screen it looks like it is 12cm tall and 4-6 cm wide

if you say a tabletop modifier of +1 is the equivalant of 1-2 cm then you can use that

example that would mean that your crosshairs (walking) would bounce 1-2 cm on the screen from the movement of your mech

running would have the crosshairs move twice as far more often

jumping would have it move 3x as far as walking in a still more random/abrupt manner

when you are using weapons the "cone of fire" ring etc of the weapons would vary based on the weapon

example short range inaccurate weapons like machine guns and small lasers are going to have a relatively huge ring possibly as much as 8-16 cm at this range because you are actually beyond the long range for this weapon.

on the other hand a medium laser srm launcher or ac20 because you are only into the medium range bands means that the circle in which a shot should fall would have a radius of say 2-4 cm or so

a large laser which is a long range weapon that at ~100 m is at its short range is going to have a ring in which it should hit of only 1-2 cm radius.

the example of the distances is essentually arbitrary, but I hope this makes it make sense

#7 Raeven

    Member

  • PipPipPipPipPipPip
  • Moderate Giver
  • Moderate Giver
  • 324 posts
  • LocationHal's Bar. Middletown, Cathay District, Solaris VII

Posted 30 November 2011 - 12:15 PM

Coding the innaccuracy of the weapons takes away one key feature that made all Mechwarrior games what they are. Your ability to aim a weapons is directly reflected in the game. It's your skill, not some arbitrary die roll, that determines whether you hit or not.

Does it have problems? Sure. Armor values are a little weak for pin point accuracy, especially regarding headshots and legs. Alpha strikes allows the combination of a bunch of otherwise weaker weapons to suddenly be as powerful as the almighty AC20.

These things can be mitigated.

Add armor. I particularly like the subsection armor idea that breaks down each to hit location and gives them all the same armor value as the single to hit location originally had.

Cones of Innaccuracy. Personaly, not my favorite, but I could live with it if they gave you the ability to slow down and focus your aim to pin point accuracy.

Weapon spread in alpha strikes. Where otherwise they would converge on the same point of aim, they would be spread slightly based on their location on the firing 'Mech.

Whatever method the devs come up with, if it is as awesome as their demo video, I'm sure we will all enjoy it (except for the engine explosion.. bleh).

#8 MacKenzie Wolf

    Member

  • PipPip
  • 22 posts

Posted 02 December 2011 - 08:29 PM

View PostRaeven, on 30 November 2011 - 12:15 PM, said:

Coding the innaccuracy of the weapons takes away one key feature that made all Mechwarrior games what they are. Your ability to aim a weapons is directly reflected in the game. It's your skill, not some arbitrary die roll, that determines whether you hit or not.

Does it have problems? Sure. Armor values are a little weak for pin point accuracy, especially regarding headshots and legs. Alpha strikes allows the combination of a bunch of otherwise weaker weapons to suddenly be as powerful as the almighty AC20.

These things can be mitigated.

Add armor. I particularly like the subsection armor idea that breaks down each to hit location and gives them all the same armor value as the single to hit location originally had.

Cones of Innaccuracy. Personaly, not my favorite, but I could live with it if they gave you the ability to slow down and focus your aim to pin point accuracy.

Weapon spread in alpha strikes. Where otherwise they would converge on the same point of aim, they would be spread slightly based on their location on the firing 'Mech.

I think what the TTBT supporters above are saying is that the cone of fire, or inherent inaccuracy of every real weapon system should be supported in MWO. Moreover, they are saying that this inaccuracy is represented in TTBT by applying modifiers to die rolls. Plain and simple.

#9 MacKenzie Wolf

    Member

  • PipPip
  • 22 posts

Posted 02 December 2011 - 08:31 PM

Also, for a more technical explanation of real "convergence," read my post here:

http://mwomercs.com/...dpost__p__50801

Edited by MacKenzie Wolf, 02 December 2011 - 08:33 PM.


#10 Pht

    Member

  • PipPipPipPipPipPipPipPipPip
  • 2,299 posts

Posted 04 December 2011 - 11:02 AM

View PostMchawkeye, on 30 November 2011 - 02:09 AM, said:

Your use of hexes, amongst other things, suggest that you are more concerned with the TT rule set than a simulator. You seem to be simulating the TT rather than a mech.


There are no real 'Mechs that we can simulate; and this is (as I hope was obvious from my repeated mentions) a BTU simulation.

Why use the TT for a baseline? Because it's non-arbitrary, it has over 20 years of work on balancing it, and where it does "break" (ALL gaming systems break!) the problems are well known (meaning they can be worked against); they would produce (IMO) enough of a suspension of disbelief (realism) for us to engage in some escapism and fun, all the while being easily controlled on the dev end.

As far as suspension of disbelief; there's plenty already there in the TT rules as they would be translated into a Video game format; and the VG allows for what would really, really, not be feasible in a pen and paper format.

Quote

I have said before, and will happily say again, the TT rules were designed for a TT game, they were not designed for a Video game; appropriating the inherent randomness from that rule set and featuring it into a simulator will make for a very frustrating simulator.


I've seen this claim tossed out time and again - can you gave an example so that it can be hashed over?

Quote

The challenges from TT rules and VG rules are very, very different; they came to those conclusions for the sake of the wargame balance; to adhere to those rules in the VG would be to ignore fundamentally what those rules were designed to do in the first instance; that is to say, a VG with those rules would be unbalanced.


Which "different challenges" and unbalanced how?

Quote

While I have no doubt that what you describe would be an accurate representation of piloting a battlemech from a TT point of view, it would make for a deeply annoying game; I think people need to feel in control of their mech, not as you suggest, simply give the mech a decent idea of what you want to achieve and let it sort of the rest.


You're taking the fact that BTU 'Mechs sweat over the small details and exploding it beyond sensible proportions into a monstrosity where all the pilot does is point-click and otherwise sit there eating twinkies and talking on the radio to his girlfriend, which is unwarranted and uniformed.

Quote

Following from your example at the end of your post, if I had six lasers at a paltry 210m, all of them should hit. They are lasers. and I can spit 210m accurately. Now if the ranges were to change between the TT and the VG (which I really hope the do) your example might be resonable (say 800-1000m?) if not I, and I suspect many others, will call it broken and go back to playing with ourselves.


You can spit *anything* 688.8 feet, much less accurately, at a target going 60 mph? :)

On the ranges - the TT rules were truncated in range due to the space of ... table tops.

As long as the ranges all stay equal in ratio to each other, they can be changed to suit the format and "fun" concerns.

#11 Pht

    Member

  • PipPipPipPipPipPipPipPipPip
  • 2,299 posts

Posted 04 December 2011 - 11:02 AM

View PostXhaleon, on 30 November 2011 - 03:19 AM, said:

Oh god, that one's a bit overboard, Pht. I'll stick to cones of fire, methinks. You can translate the TT rules into real time that well enough if you don't directly take the (calculated) percentage chances to-hit, which are a bit too inaccurate.

I'm not sure how this is supposed to play out by your description of gameplay. Is this based on a designated target system where the game does everything for you after you select a target to fire at (and do so)?


No, you don't "fire and than ignore" your target - 'Mechs aren't allowed to choose their targets, they're simply too destructive to be allowed to do that.

The pilot has to track his target with the crosshairs, the pilot has to choose when and what to fire.

View Postguardiandashi, on 30 November 2011 - 07:54 AM, said:

what he was getting at is TRANSLATING the tabletop game stats into their "sim" equivalants


Thank you! Someone gets it!

Quote

los range you almost might as well point the weapon and fire in their general direction (thats effectively what you are doing) hitting is not the rule it is the exception


Actually, if you spend about thirty seconds (three turns) tracking your weapon with the reticule and you're using a weapon in an arm which is braced up on a structure (allowing the myomer muscle "slop" to be removed from the equation) You can knock enough of the variables (+modifiers) out of the equation to have a fighting chance of making a shot at LOS Range versus slower moving targets.

View PostMchawkeye, on 30 November 2011 - 08:58 AM, said:

ok...but +1 what?

on the TT, that's +1 to a dice roll within a very specific set of parameters ie: dice probability.

Dice probability is not appropriate for this game.


The dice simply map out the ability of a 'Mech; the probability can be dropped in, graphed and smoothed out and dropped in, whatever. It's a baseline that gives real, hard, useful paramaters on how capable a 'Mech is.

I do wonder why you think dice probability isn't appropriate...

Quote

We get it. We really do. We understand already. it's just that some people think that that level of inaccuracy wouldn't be good for the game, and other, like me, feel that levels of accuracy should be defined as much by the nature of a simulator (+1 for moving? I already am, aren't I? hasn't that inherently affected my accuracy?) and a sense of what the table top suggests as opposed to running the numbers and stats from total warfare as be all end all.


What the TT rules describe as to how accurate BTU weapons are does not make them "inaccurate" - the weapons are bloody terrifyingly accurate, as should have been obvious from my first post. What keeps BTU 'Mech combat from being insta-gib UT style headshot fests and allows for a bit of fun combat is that the 'Mechs, while being darned capable, can't get all of their weapons to hit with "pixel accuracy."

There could be pages and pages of explaining why this is, in BTU terms, but this is one of the things that makes a BT 'Mech... a BT 'Mech. We don't want a gundam game where your mecha blasts things in the eye halfway across a solar system with thirty-six weapons!

#12 Pht

    Member

  • PipPipPipPipPipPipPipPipPip
  • 2,299 posts

Posted 04 December 2011 - 11:03 AM

View Postguardiandashi, on 30 November 2011 - 11:56 AM, said:

GAH it ate my post

basically I am thinking of a syatem that assigns a modifier to an equavalant amount of size/measurement on the screen


It doesn't even have to be that complex. :)

Quote

example that would mean that your crosshairs (walking) would bounce 1-2 cm on the screen from the movement of your mech

running would have the crosshairs move twice as far more often


Bouncy reticules have been tried and they are CRAZY making ingame. Thus the color coding of the reticule for "quality" of weapons lock.

View PostRaeven, on 30 November 2011 - 12:15 PM, said:

Coding the innaccuracy of the weapons takes away one key feature that made all Mechwarrior games what they are. Your ability to aim a weapons is directly reflected in the game. It's your skill, not some arbitrary die roll, that determines whether you hit or not.


Did you read where I posted what the pilot directly and indirectly does to control his weapons fire?

If you did, why aren't you interacting with that?



Quote

Does it have problems? Sure. Armor values are a little weak for pin point accuracy, especially regarding headshots and legs. Alpha strikes allows the combination of a bunch of otherwise weaker weapons to suddenly be as powerful as the almighty AC20.

These things can be mitigated.


MW4 tried this and it failed horribly. You have to toss the entire parent system on the trashheap and you wind up with an entirely new system of quite possibly arbitrary decisions with untold amounts of unintended consequences.

I'm not trying to pick on the MWO devs, but I don't think they're up to this level of mental work in the time they have allotted - I dont' think *anyone* is.

View PostMacKenzie Wolf, on 02 December 2011 - 08:29 PM, said:

I think what the TTBT supporters above are saying is that the cone of fire, or inherent inaccuracy of every real weapon system should be supported in MWO. Moreover, they are saying that this inaccuracy is represented in TTBT by applying modifiers to die rolls. Plain and simple.


That's only a tiny part of it - what I'm trying to say is that when you say "I want to simulate what it's like to pilot a battlemech in the BTU" than you go to the TT for the baseline. Otherwise, you're not making an MW game; you're making a Frankensteins monstrosity with some visual and name similarities to the BTU

---

Multi-post insanity due to low limit on quoted blocks allowed per post.

Edited by Pht, 01 January 2012 - 11:48 AM.


#13 plodder

    Member

  • PipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 998 posts
  • Locationbetwixt the seen and heard, underneath the upperhanded, above the underhanded. Sunlit with a cloudy background.

Posted 03 February 2012 - 05:44 PM

LOL.Sight is not for the blind, bind not the free, accept the force which propels, dispel the truths that lie.

I hope that the game has complexity in its simplest forms. That the best fire and aim solutions include guesswork on the fly, that strategy of multi tasking in heightened, and that a pilot with weaker innate talent (like me) can overcome this weakness with strategy and determination.

To twist a wrist into any position takes a fair amount of computation. To track with the eye, to do that twist, to estimate when to release, etc. is more than a developer can hope to generate, so hopefully they can make a tool that will allow our brains computing to fill in the gaps where programming meets fantasy, where story meets meets our hopes, and that even a halo first person shooter elite will feel inspired and challenged.
I just hope that there will be given latitude for major advanced play built into the system for those that want it, and that the most advanced or basic style of play has it's advantages, and faults, but it basically fair.
I really appreciate TT folk, they are the reason mechwarrior is alive and kicking. So thank you Table Top fanatics, we wouldn't be here without you.

I read most all of this topic and feel a bit enlightened, thanks, uncle danno

#14 Kenyon Burguess

    Member

  • PipPipPipPipPipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 2,619 posts
  • LocationNE PA USA

Posted 03 February 2012 - 06:13 PM

very nice write up. however, the minute you used the word "hex" i fear you lost half your readers. nothing scares gamers worse than reading how applying enviromental numbers behind the scene could ruin their alpha strike. my personal view is that i would like to see parts of what you said in the game but not the convergence circles. modern computers should be able to track each weapon and converge them automatically to your crosshairs. movement, shaking, bouncing arms, heat, and alot of the other issues you mention shouldnt be seen untill the trigger is pulled and they should never miss. the lasers should just hit off center a bit. that way some hit left t, some right t, and some center. if the weapons fired down the list 1 at a time, would also help the alpha strike issues. thanks for writing all that too. i enjoy well thought out ideas.

#15 TheRulesLawyer

    Member

  • PipPipPipPipPipPipPipPip
  • 1,415 posts
  • LocationChicagoland

Posted 03 February 2012 - 09:41 PM

Wow. Wall of text. As a TT player I totally appreciate you, and understand what you're getting at, but you probably lost 90%+ of the MW only players there. Mechs are piloted more as if you were playing them in a RTS game or something according to the books, however I don't know that the MW crowd will ever accept that. They want a FPS with robots and damn canon. Heck, damn learning what the TT system is most of the time and it must be horrible just because its a TT system.

Anyhow, yes. The TT defines the general performance envelope of a mech and its weapon systems. As long as you represent that same performance envelope in the sim you're doing well. The mechanics of how it happens are obviously going to be different.

#16 Eddrick

    Member

  • PipPipPipPipPipPipPipPip
  • Storm
  • Storm
  • 1,493 posts
  • Facebook: Link
  • LocationCanyon Lake, TX.

Posted 08 January 2013 - 06:17 PM

Steel Batalion had somthing like this. The game even came with a special controler with two joysticks. One for controling the Mechs movment and the other to aim. The crosshair would move across the HUD when moving the joystick that controles aim. However, the Mechs in Steel Batalion (Vertical Tanks or VT for short) couldn't twist thier torso like BattleMechs in Battletech/Mechwarrior can.

#17 Solis Obscuri

    Don't Care How I Want It Now!

  • PipPipPipPipPipPipPipPipPip
  • The DeathRain
  • The DeathRain
  • 4,751 posts
  • LocationPomme de Terre

Posted 08 January 2013 - 08:02 PM

Posted Image

#18 Stingz

    Member

  • PipPipPipPipPipPipPipPip
  • 1,159 posts
  • Location*SIGNAL LOST*

Posted 08 January 2013 - 08:55 PM

Give every TT mech a free Targeting Computer and C3i, then you see why changes needed to be made in MW:O. All mechs in MWO basically have C3i and targeting computers built-in, and player skill only makes for even better accuracy.

Leave random spread to LBX and Missiles. Luck isn't a fun factor, especially when it's random spread .

Edited by Stingz, 08 January 2013 - 09:00 PM.


#19 _Rorschach_

    Member

  • PipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 128 posts

Posted 09 January 2013 - 01:15 AM

View PostPht, on 29 November 2011 - 04:43 PM, said:

*lots of text*


Imo a terrible idea. Sorry to tell you this after you went through all the trouble of writing this post, but that's my opinion.

Why? Several reasons. But the main one is this:
It introduces luck as a big factor. If there is anything people playing competitive multiplayer games hate, it's luck based games. And I'm not only talking players that play competitively in a league or sth, but also pretty much every casual player that plays a game that pits them against other players.

Basically it would turn MWO into an autoaim MMO game that you could easily also play from a third person or isometric perspective with a clickable skill bar at the bottom of the screen.

edit: dang, just noticed how old that thing is :)

Edited by pack wolf, 09 January 2013 - 01:17 AM.


#20 Pht

    Member

  • PipPipPipPipPipPipPipPipPip
  • 2,299 posts

Posted 10 January 2013 - 05:03 PM

View PostStingz, on 08 January 2013 - 08:55 PM, said:

Leave random spread to LBX and Missiles. Luck isn't a fun factor, especially when it's random spread .


So, in other words, you don't want a 'Mech combat sim game in wich ... 'Mech combat is simulated.

Why are you here?

.. and do you realize that instead of skill in handling a weapon, in an MW video game, you have to have skill at handling the 'Mech, and you still have to have aiming and tracking skill with the reticule on the HUD, so the accusation that it removes skill from the equation is a false accusation?

View Postpack wolf, on 09 January 2013 - 01:15 AM, said:

Imo a terrible idea. Sorry to tell you this after you went through all the trouble of writing this post, but that's my opinion.

Why? Several reasons. But the main one is this: It introduces luck as a big factor.


No, it does not introduce luck as a big factor.

It changes the player skill factor from "direct control of weapons aiming" to "direct control of your armored combat unit."

Quote

Basically it would turn MWO into an autoaim MMO game that you could easily also play from a third person or isometric perspective with a clickable skill bar at the bottom of the screen. edit: dang, just noticed how old that thing is :)


There is absolutely zero in any of my post here or in any of my posts anywhere in these forums (or others) that validifies your conclusion here.

There's zilch auto-aiming anywhere in this or the TT. You, the player, have to indicate the aimpoint to the 'Mech, you, the player, have to track what you want to hit with the reticule, and you, the player, have to decide when to fire your weapons and what you want to fire.

You also have to know how well or poorly your 'Mech can cope with/overcome the conditions it's experiencing when you pull the triggers.

There's very little "luck" about it.

I have a sneaking suspicion you're posting these things based upon your presumptions instead of based upon even a mildly thorough comprehension of the OP in this thread.

Edited by Pht, 10 January 2013 - 05:03 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users