Navid A1, on 22 November 2015 - 10:43 PM, said:
---> The info on game mechanics that i'm using is very old, so this whole thread might be incorrect <---
Source for current game mechanics: http://mwomercs.com/...ement-behavior/
Alright, so now everyone is aware of the changes in PTS4 that are going to go live early December.
The changes mostly include reductions to mech skill tree boosts to a mech's agility such as turn rate, acceleration and deceleration, etc.
One of the things that is going to be indirectly affected by these changes is how hill climb mechanic currently affects mechs in the game. The large number of clutter and small details on the ground with collision meshes slow down larger mechs to a nearly halt speed. With the agility nerfs, assaults (which were already hit by the nerfs) will have an even harder time recovering from those halts.
The current system only works by measuring the slope of the terrain mesh at every given time.
As an example, comparison between a locust and a direwolf in the current hill climb mechanics is shown here:
As you can see, the mechs speed reduction is affected by the terrain slope the mech is walking on. Lots of small and tiny clutter with collision boxes on maps can cause alot of sharp slopes, which combined with the usual rubber-banding in the game can cause a situation like this:
The problem here is that the system assumes the mech to be a rigid box, over-simplifying this mechanic, disregarding the mech stride length and height!, Hitting assault mechs hard in the movement department (assaults are already slow and clumsy... because they are assaults).
a 100 ton mech should be able to step over anything smaller than a small building:
Suggestion:
in order to take the stride length and height into account, one can define a stride boundary limit for each mech, which defines an allowable area a mech can step on things. if the terrain collision box crosses this boundary, then you can apply the current mechanic in order to calculate speed reduction, and possibly halt.
However, if the terrain collision meshes all reside in the boundary, then there should not be any speed reduction in any situation as demonstrated below:
Some examples:
Obviously, a dire wolf should have higher stride boundary than that of the locust, because of its size... so it should be able to clear out most of the obstacles!
Also, an atlas should have the largest boundary between the 100 ton mechs.. because its a humanoid.
Note that the locust in the above picture will halt to a full stop on the 80 degree slope, while the dire does not even see it.
Meanwhile, an atlas as a humanoid plantigrade should be able to step over all!
I like to hear you opinion regarding this suggestion!
I say again, the current mechanics may be different from what i assumed... so please correct me if i'm wrong!
Okay I lied. I want to talk about it now.
I understand where the OP is coming from with this post, but I have to point out the problems in the description of the problem and solution.
Again, I don't know the whole story. I'm just making an educated guess based on my own experience making games.
Based on all the evidence I have seen ingame, the mech's collision isn't based on a box - it's based on a capsule-shaped collider (kind of pill shaped, like a cylinder with rounded ends). This is how a lot of FPS games deal with terrain collision, and it's the reason you can overcome some obstacles by increasing your speed. As an aside, it's also why you get stuck on things sometimes. Remember when light mechs would get stuck on the edges of objects like the cap points? That was probably because PGI uses a really simple method of detecting when the mech is on the ground, such as raycasting straight downward and measuring the distance of the impact point.
Anyway, the OP speaks of strides, but you have to understand that all the movements mechs make in the game IS A LIE. That's not what actually is going on - your mech isn't walking. It's a capsule-shaped collider that is sliding on the terrain's collision mesh. The animations are only visual, and have nothing to do with how the mechs move. Now, you may be wondering about the collision meshes for weapons to hit. That's an entirely different set of colliders that reside on a different layer and only interact with weapons fire.
This is a limited, but efficient system. FPS games have always been designed for efficiency because performance is everything. However, the game HAS TO BE DESIGNED AROUND THIS LIMITATION. MWO is not.
The level design in MWO is the worst I have ever seen. The collider placement is terrible, and whoever is doing it likely has no education in how it is supposed to be done. Even basic mapping tutorials for the original Half-Life covered this.
Collision meshes have to be placed carefully. Nobody likes getting caught up on things, but it happens constantly in MWO. Not only that, but the collision meshes don't match the visual meshes. The biggest offender is probably the cap-point on assault. It's a weirdly shaped trailer thing with lots of empty space, but you can't shoot through any of it. Either they are using a single box-collider on that thing, or they are using automatically generated convex mesh-based colliders. I'm leaning toward the latter.
Guys, you have to place your collision meshes manually. Automatic generation is the enemy here.
In MWO there are TONS of invisible collision meshes that occlude your shooting, but not your sight. This is such an amateur mistake that I'm in disbelief it exists in a game this mature.
As for the terrain obstacles, there are some other mistakes that PGI has made in their level design that adds to the problem. There are three basic collision problems I can see in this game. We've covered the capsule-collider and the convex mesh colliders. That leaves the third major problem - mixing heightmaps with meshes.
PGI has taken a shortcut in map design. They base their terrain on the highly efficient heightmaps, but then sink 3d assets into the terrain to spice it up. This seems like a good idea to an artist, but what you actually get is colliders that are intersecting, which leads to strange behaviors. Ever get stuck on nothing? Or inexplicably fall through the world?
So, to sum it up, if you ever want to see this problem go away, PGI needs to educate themselves on how collision-meshes should be placed in a video game, and acknowledge that there are limitations to the methods they have chosen.
It's really a very easy problem to address, and really highlights where PGI has blindspots in their team.
Edit: Oh yeah, I forgot. The OP has some good ideas, but very high-level. The problem is this isn't a 2d problem, and working backwards as one must do with collision detection isn't as easy as basic geometry (at least not in 3d space).
Still, I appreciate the effort the OP made and thank him for bringing the issue to everyone's attention.
Now, back to watching the Super Ball
Edit: Corrected some terminology
Edited by Product9, 23 February 2016 - 05:08 PM.
6
