Critical Radius, Emergency Breaks and the Merging of Forces

(A) Implemented unit collision and break algorithm using critical distance calculation; If two unit’s critical radius collide with each other, the emergency velocity diversion function is performed. The function will remove all velocity from direct collision course between the two units. It does this by projects each unit’s velocity onto a vector drawn between the two units. This projected collision velocity will then be removed from the unit’s velocity itself. Which force the unit to either divert away (if original velocity is not in direct collision) or stop moving entirely.

(B) Refactoring forces result from the difference functions to work better together, by treating the force as the targeting velocity itself rather than just velocity’s direction. Obstacle repulsion and target attraction are now both clamped to the same size, so that the only way for there to be a “sinkhole” would be if there is an obstacle directly between the target and the unit. After which, the unit’s attraction and repulsion is layered on top of the balanced equation, ensuring the push from movable units take priority.

This equation however seem to result in another “sinkhole” at the entrance of a balanced “tunnel” with obstacles on both side. Perhaps the targeting force should get a booster to always be higher than obstacle avoidance?

(C) Obstacle repulsion calculation is now performed as part of the background loop function in GameNavigator rather than calculated individually every frame by all units. As obstacles are near constants, delay of a fraction of a second should have little to no impact.


2 comments on “Critical Radius, Emergency Breaks and the Merging of Forces

  1. Your “image” is partly “off”… Your black object (by your colored line indicators), would have a “new velocity” that is impossibly in opposition to its combined velocity/force-impact. EG, you have it with a new direction south, after being hit from the south.

    You also have to take into account… mass with force, since I assume that not all masses you intend to use are equal. (Possibly also transference and dampening. Since only pure-solids, which do not exist, would transfer 100% of energy. Most solids only transfer a majority and loose the rest as heat. Semi-solids, plastic and rubber and flesh, tend to transfer only dampened energy. Deforms capture energy, and re-direct it or expel it as heat.)

    EG, think of the 5-bearing pendulum. (Though I have NEVER encountered any program/code that correctly calculates all the actions of that simple device.) Swing one ball, most energy transfers through every connected bearing, and all releases on the last ball, which is of equal mass. If the last two balls were half-mass, two balls would release as one hit, on the other side. The code I never see correct, is raising three of the five balls, they swing down and hit the two stationary balls, yet, three rise up, with transferred energy. Programs simply make those two balls move faster, which is NOT what happens. Because all energy is transferred from ball 1 to ball 2, on impact, and all energy from ball 2 is transferred to ball 1… thus, they swap energy. “if solid”. Also, depending on the “force variation”, the “new angle of velocity”, will be altered. EG, it is not always just half-way between impact-angle and original-velocity-angle. If the impact is low, the adjustment is going to be low, compared to the original-impact-angle. Thus, not half-way if originally traveling 100mph north, and hit from the west at 10mph… the new direction will be about 93% north, and offset by about 7% to the east… but at the original velocity minus 7% of the impacting objects velocity, relative to mass. The other object will now be moving about 80mph, in the opposite direction (formulated new angle), while this object will be moving about 93mph. (Also, the impact-angle has a curve, which alters the transfer also. Direct impacts are 100%, side impacts are about 33%, due to spin/slip/stick/momentum/echo-mirror-retransfer.)

    Get an air-hockey table. That will give you TONS of insight into the motion you are looking to obtain. Which removes the interfering “other” stuff, if you use pool-balls and other surface contact stuff that misleads you into “fake” formulas that just fail.

    Love the info. Great setup, except for the miscolored black-triangle-directions in this one example.

    • Wow. Thanks for the response. I see that me writing down such details is useful! I must admit that I did not look too much into the physics of it, as I was looking at the pathfinding and movements itself. I’ll have to keep that post in my log to look into it again when I managed to fix my current dilemma of the unit’s movement algorithm. The movement prediction itself is so much harder than the AI part!

      Have you seen the latest video we have yet? I believe I have a much newer one on my website, with a more game-like looks and everything. Though it’s slow going, what with half our forces working full time now, but it is going nonetheless. So thanks for the detailed explaination!

      On the color though…well…I didn’t really intent to have it conform to any color code really…and was just swapping color when I need to make one stand out…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s