BigSteel, on 03 August 2012 - 06:18 PM, said:
This is a big part thatis missing from the people who talk about SIM implemetation in this game. Its stings when it becomes a very unresposive World of Tanks like event.
Well I did respond to that earlier, but the neurohelmet's primary job is to relay balance information to the mech, it's not thought control, as the vast majority of the inputs come from the cockpit controls. It can convey some intent but that's it. I'll try to explain. Mech's are robots, they have there own level of intelligence, so the pilot tells the mech what they want to do and the mech handles the details.
For example to pick up an improvise weapon, the pilot would put the crosshairs on whatever it is, then issue a "grab command"(whether you wish to see this as hitting a button or as the mech understanding the intent of the pilot through the helmet is not clearly defined in my source material, so it's up to you) and the mech will lower itself and pick up the item, then barring further pilot input, stand back up and ready the weapon all by itself. If you wanted to pick up a person without hurting them, the proceedure is the same, as the mech understands through the helmet that you don't want to hurt the person and takes care when applying pressure as it pick's the person up.
Punching something is simply target with the crosshairs hit the punch button and pull the punch trigger, but since a phyiscal attack like this means shifting it's weight out of balance, it checks with the pilot on an unconcious level to make sure that the pilot does want the mech to get itself off balance. In a sim all of this could just be assumed, but I would prefer that some of it be simply modelled so that the person playing has to actually pilot the mech from time to time, instead of just driving it around. I won't get into an explaination, as there is a thread here: Add a gyro compensation meter (now with better pic!)
that has an idea by another memeber, as well as my own thoughts on the subject, for those who wish to know.
Pht, on 03 August 2012 - 05:35 PM, said:
I think the locked reticule is due more to our controller setup's capabilities vs how the lore functions, and btw, MW3 did allow for a "free" reticule. It's simply not easy to have control of a 'mech's movement AND it's reticule at the same time with a mouse/kbd or mouse/joystick. Thus most of the 'mech games have had the reticule locked into the center of the hud.
I think your misunderstanding the movement I'm talking about here, though I'm not opposed to what you seem to be referring to. The movement I'm speaking about is the cockpit movement caused by the motion of the moving mech should be moving the crosshairs, that is they should bounce and sway with the mech as it moves, because not only is it unrealistic for them not to do so, but also the TT rules say that it's harder to shoot while your mech is moving than when your standing still, even against a stationary target.
Actually, most of the time, the reticule is on the main cockpit hud and not in the neurohelmet viewscreen.
This would just introduce the possibility of the pilots head being slightly missaligned causing the aimpoint to be off down range. Being out of alignment by .5 dergrees at 600m would mean the aimpoint is off by 3m.
You want to know what's neat? We already know how long it takes for a 'mech t&t setup to get a ridiculously good fix - about thirty seconds, if you're really, REALLY taking your time and say, want to shoot something MILES away. Normal operation takes less than ten seconds. Quality of lock is indicated by color-codes on the Hud around the reticule and lock tones.
Interesting, I'm curious as to the source of your times. Your specifiying of range for the first example makes me need to point out that the TT ranges are abstractions that allowed the game to fit on a table, but you probably know this, so it's mostly for the benifit of others, and that actual ranges would be longer, most likely considerably longer than the ones we know from this game, which I believe are the same as the TT.
Do it like the lore does it. The pilot manipulates the reticule on the hud and puts it where he wants things shot at, and the mech takes in sensory data, crunches it, and uses those results to determine how to align the individual weapons to best try and hit what the pilot is indicating with the reticule. Use color coding and tones to indicate quality of lock instead of cluttering the hud with things that are impossible to track easily in combat...
I would be happy with that, my 'complicated' version allows you to snap shoot weapons that might already be over the target, without targeting a mech, is the main reason for my preference.
So you have the pilot tracking the target, choosing when to shoot, and where to shoot... with the 'mech doing all the rest.
As it should be.
As far as the back end game mechanic? ... we already have the data on how well a 'mech in the BTUniverse can hit an overall mech sized target and how well it can get multiple weapons to concentrate "under the reticule."
Right but a lot of people just refuse to beleive that mechs are less than perfect in their ability to target things, which is why I approched this from an actual weapons system point of view.
All we have to do is convince people that in an MechWarrior video game you should have the player directly controlling the 'mech and the 'mech directly controlling the weapons, instead of having the player directly controlling both.
You know, actually have people playing a game that simulates what it's like to pilot a battlemech, instead of quake version (whatever).
Now your talking what I would like to see, as piloting has been missing from all MW games. Mechs need to be able to fall down, but it needs to be done in a way that a player can learn to pilot his mech without really worrying about falling as long as they pay attention to the terrain and their movement in relation to it.