The discussion has moved over to Discord

Home Forums Overload Development Thoughts on triple-chording and balance

RSS Feed
Viewing 12 posts - 121 through 132 (of 132 total)
  • Author
    Posts
  • #9272
    Haunted ParraspHaunted Parrasp
    Kickstarter Backer
    Topics: 31
    Replies: 428

    Coming from your thread, I have to ask… is that pun intended? 🙂

    Ship’s cat, MPSV Iberia
    Check out his original music @ http://vertigofox.bandcamp.com/

    #9273
    rapturraptur
    Kickstarter Backer
    Topics: 29
    Replies: 134

    I just hate it when I switch from a diagonal to a non-diagonal and have the ship slow down, it’s a real drag. Both mechanics could be satisfied by having 2 kinds of ships sharing the same bi-chord speed.

    It sounds like there’s just a difference of opinion about what’s frustrating. I don’t like it when pushing the slide right key moves me rightward at different speeds depending on what else I’m doing, and slows me down in the other directions. It also introduces a very counter-intuitive mechanic: if I’m moving forward, for example, I have to push the reverse key for a period of time to get to the maximum slide right speed as quickly as possible.

    I think that, for old and new players alike, it’s far more natural to have one key affect each direction, rather than have weird combinations of keys affect each direction depending on how they counterbalance the current vector.

    #9276
    hypersonic
    Kickstarter Backer
    Topics: 18
    Replies: 220

    “If I’m moving forward, for example, I have to push the reverse key for a period of time to get to the maximum slide right speed as quickly as possible.”

    I’m not sure I quite follow. Speed isn’t chord-boosted, but acceleration/thrust is with D1/D2/D3. By right, do you mean ship relative (like in the direction the right wing), or level relative (like to the East?)

    “I think that, for old and new players alike, it’s far more natural to have one key affect each direction, rather than have weird combinations of keys affect each direction depending on how they counterbalance the current vector.”

    Depends on how you want to look at it:

    -Why should I need to do certain axis combinations to achieve different ‘resultant thrusts’? (chord-boost)
    or
    -Why should I need to do certain axis combinations to achieve different ‘ship relative component thrusts’? (no chord boost)

    I suppose there’s no right or wrong answer to this question, hence no ending to this thread. Though it would be awesome if players could choose their preferred mechanic via different ships.

    #9278
    rapturraptur
    Kickstarter Backer
    Topics: 29
    Replies: 134

    “If I’m moving forward, for example, I have to push the reverse key for a period of time to get to the maximum slide right speed as quickly as possible.”

    I’m not sure I quite follow. Speed isn’t chord-boosted, but acceleration/thrust is with D1/D2/D3. By right, do you mean ship relative (like in the direction the right wing), or level relative (like to the East?)

    I mean ship relative. Maximum speed is chord-boosted with D1 and D2, and D3 as far as I understand (my computer couldn’t handle D3’s graphics). Your current speed in 3-space is a 3-dimensional vector. With “full” trichording, the 3-dimensional vector is obtained by adding the forward vector (the forward component) to the horizontal vector (the horizontal component) to the vertical vector (the vertical component):

    3-space components

    These perpendicular (or “orthogonal”) components define a rectangular prism, and the actual velocity is along the diagonal:

    full trichording

    You get a speed boost because the diagonal (the dashed line) is longer than any of the components. This is a consequence of the Pythagorean theorem.

    To maintain a consistent speed regardless of which directions are being used, we can visualize a sphere whose radius is the maximum consistent speed:

    trichording with sphere

    The consistent speed is then enforced by scaling the diagonal so it never goes outside of the sphere:

    normalized trichording

    However, notice that this scaling results in each of our original components being smaller. If we are merely bichording, however, we have the same total speed (the diagonal is the same length) but the two active components are larger:

    Scaled Bichording

    And if I am unichording to the right, the rightward component is largest of all:

    Scaled unichording

    If I am bichording forward and to the right, and I suddenly want to move as quickly as possible to the right, I need to zero-out my forward component as quickly as possible. To do this, I should not only stop moving forwards, but actually accelerate backwards. Even more counterintuitively, if I am unichording forward, I can unichord to the right most quickly by accelerating backwards and to the right.

    If you don’t do this kind of active zeroing-out (i.e. you just release the forward key rather than also pushing backwards), then your acceleration to the right is initially very slow because you are waiting for the drag model to zero out your forward acceleration in addition to waiting for the rightward acceleration to build up. This kind of slow component-wise acceleration that is sensitive to your previous trajectory makes the ship feel sluggish and inconsistent.

    Does that make sense?

    EDIT — I should say that this is not exactly what Overload has done. They are not enforcing a consistent speed regardless of trichording, effectively allowing the sphere to become slightly larger if more buttons are being pushed. However, it still has the counterintuitive effect that each individual component changes depending on the size of the other components.

    #9279
    hypersonic
    Kickstarter Backer
    Topics: 18
    Replies: 220

    (regarding the graphs)
    I realize that the resultant hypotenuse is longer than the components opposite and adjacent in both 2D and 3D space. After that I believe you are describing vector normalizing, which causes the resultant to be the same length regardless of direction.

    (regarding this sentence)
    “To do this, I should not only stop moving forwards, but actually accelerate backwards.”
    This should probably be re-worded. Instead of ‘stop moving forward” I think you mean ‘stop thrusting forward’. As for ‘actually accelerate backwards’ don’t forget that drag will accelerate backwards all by itself, albeit more slowly. You can add to the drag acceleration by thrusting backward, which I’m guessing is what you meant. Deceleration is a special case of acceleration, meaning acceleration in the direction opposite of the velocity vector. People might scoff at the notion that braking is acceleration, but it’s true, it’s an acceleration opposite the direction of travel.

    (as for the rest, I’ll assume that you’re talking in the context of normalized thrusting)
    Your thrust would be normalized, not your speed, hence no need to stop your forward speed to add more to your right-dir speed. Your thrust to the right wouldn’t care what your forward speed is.

    (drag factor)
    Drag scales the velocity vector, it shaves off a certain percentage of speed (magnitude of velocity) each time slice. Interesting question on how drag might play a part in what you mention. I’d have to give that some more thought.

    EDIT
    Giving it a bit more thought, I’d say that like thrust, drag wouldn’t be a factor either. While the component speed to the right is still low the component of drag to the right would also be low regardless of the forward speed. So the only reason you’d want to thrust backward would be to simply reduce your forward speed faster, but it would have no affect on your right movement.

    #9281
    rapturraptur
    Kickstarter Backer
    Topics: 29
    Replies: 134

    As for ‘actually accelerate backwards’ don’t forget that drag will accelerate backwards all by itself, albeit more slowly.

    Yes, more slowly, and that is the point.

    Your thrust would be normalized, not your speed, hence no need to stop your forward speed to add more to your right-dir speed. Your thrust to the right wouldn’t care what your forward speed is.

    I think there is just a misunderstanding here. The speed is normalized. There is a maximum speed that is less than what results from straightforward vector addition, which means that the velocity vector is normalized, which means that my actual speed to the right at time t depends on my actual speed forward at time t. Whether my forward speed at time t is obtained through forward acceleration, backward acceleration, or even yawing to the right while sliding to the right (due to inertia) is immaterial — it affects my speed to the right. Since velocity changes smoothly, my achieved acceleration to the right is slower as long as I have any forward (or backward, and/or vertical) speed, regardless of exactly how they implement drag and thrust.

    –EDIT I realized this misunderstanding might have come from Luke Schneider’s opening post, where he says that he’s added a speed-drag system. I can see how one might conclude that the normalization somehow only affects thrust from that. However, he’s clear that this imposes a maximum speed, and the analysis above relies only on the presence of a maximum speed. Implementing a maximum speed via a speed-sensitive drag system will affect how and how quickly the velocity vector “spins” around the sphere, and deform the sphere so that it’s not exactly a sphere (their “sphere” is 20% longer along bichording axes and 30% longer along trichording axes), but as long as the length of this vector is shorter than the result of vector addition the above analysis goes through.

    #9284
    hypersonic
    Kickstarter Backer
    Topics: 18
    Replies: 220

    I don’t know what the physics code is like in Overload, I assume it’s similar to Descent with some chording modifications. The below is using the D1/D2 model, with a hypothetical normalized thrust scenario for comparison, where full speed is reached when accel from thrust = decel from drag.

    You’ve pressed forward for awhile and you’re moving full speed forward
    Scenario A: you continue pressing forward thrust and immediately press right thrust
    Scenario B: you let go of pressing forward thrust and immediately press right thrust
    Scenario C: you switch to backward thrust and immediately press right thrust

    If normalized thrust:
    -With A the right component of both your speed and acceleration would end up being about 70% of your resultant.
    -With B the right component of both your speed and acceleration would end up being about 100% of your resultant.
    -C is the same as A as far as the right component is concerned. The entire time right thrust is about 70% of the resultant thrust.

    If un-normilized thrust:
    With all 3 scenarios your right thrust is the same and your resultant thrust with B (unichord) is less than with A or C (bichord.) Your speed and acceleration to the right is always the same.

    #9285
    LotharBot
    Kickstarter Backer
    Topics: 1
    Replies: 133

    It also introduces a very counter-intuitive mechanic: if I’m moving forward, for example, I have to push the reverse key for a period of time to get to the maximum slide right speed as quickly as possible.

    I think that, for old and new players alike, it’s far more natural to have one key affect each direction, rather than have weird combinations of keys affect each direction

    I realized this when writing on the D:U forums the other day: people sometimes say that they want to remove or nerf trichording because of the skill curve. But doing any sort of vector renormalization doesn’t remove the skill curve, it just replaces it with a different (and IMO worse) skill curve that has a more negative effect for inexperienced pilots and isn’t as interesting for experienced ones.

    With full trichording, at a low level, you just mash the key that does what you want and you get that effect, and might accidentally trichord sometimes, but not understand the relative speed boost you get — it just feels like your ship is doing all three things you told it to. With nerfed or no trichording, you mash the key that does what you want and you sometimes get different effects in the directions you’re trying to move, depending on what’s going on in other directions. You get a speed nerf that you don’t understand but have to learn to compensate for.

    With full trichording, at a high level, you have a constant tradeoff between speed and view / direction, which you always have to manage. With nerfed or no trichording, you instead have a tradeoff between speed in the direction you want and speed in other directions, which you still always have to manage. The skill curve doesn’t go away, you just have a different and less fun skill curve, which a lot of other 6dof games have had and which has never been particularly fun.

    #9286
    rapturraptur
    Kickstarter Backer
    Topics: 29
    Replies: 134

    You’ve pressed forward for awhile and you’re moving full speed forward

    Scenario B: you let go of pressing forward thrust and immediately press right thrust

    If normalized thrust:

    -With B the right component of both your speed and acceleration would end up being about 100% of your resultant.

    No, this is not right. Even after you let go of forward, you still move forward until drag or active reverse thrust cancels your forward movement. This means that you do *not* get 100% of your speed and acceleration to the right in the initial movement: there is a feeling of lag that I find irritating. Just try it 🙂 Launch Overload and start the training mission, and compare how the ship moves if you simply release forward and strafe right to how the ship moves if you also hold reverse for the first half second or so of strafing right. There’s a big difference.

    #9287
    hypersonic
    Kickstarter Backer
    Topics: 18
    Replies: 220

    With D1/D2 you can look at the source code, but not so with Overload. I’m not sure about the nitty gritty details of Overload’s current flight mechanic, plus it’s still in development so it can change at any time.

    With all ‘ship relative directions’ having the same max accel/speed you have the freedom to simultaneously and independently aim and dodge in any direction at all times without sacrificing accel/speed, allowing for more possibilities. You can circle strafe while simultaneously leading your aim in any direction from a target and not lose any circle strafing speed, as demonstrated in https://playoverload.com/forums/topic/normalized-speeds-and-circle-strafing/

    To spice things up a little maybe add an omni-directional boosting system with a cooldown allowing one to briefly circle strafe at a faster rate at the same radius via faster translation/rotation accel/speed.

    Both chord-boosting ships and non-chord-boosting ships could have omni-direction boosting w/cooldown capability to really spice things up. With both chord-boosting ships and non-chord-boosting ships no compromise would have to be made.

    #9293
    rapturraptur
    Kickstarter Backer
    Topics: 29
    Replies: 134

    With D1/D2 you can look at the source code, but not so with Overload. I’m not sure about the nitty gritty details of Overload’s current flight mechanic, plus it’s still in development so it can change at any time.

    The above analysis relies only on 1) a maximum speed that is less than what is obtained from straightforward vector addition and 2) finite acceleration/deceleration from drag and thrust (so the diagonal moves around smoothly). The nitty gritty details of the flight mechanic and looking at the source code are not important.

    #9295
    SigmaSigma
    Kickstarter Backer
    Topics: 4
    Replies: 122

    Most of all, I want it to be a powerful, precise and ergonomic control of ships. As BMW.

Next Unread Topic:
Viewing 12 posts - 121 through 132 (of 132 total)

Forums are currently locked.


Previous Topic: Music for Overload Next Topic: Do you hate the huge emoticons in Quotes? Here's how to avoid them.