Collisions

From WinBolo

(Difference between revisions)
Jump to: navigation, search
Current revision (23:49, 13 May 2009) (view source)
(Physics)
 
Line 26: Line 26:
== Physics ==
== Physics ==
-
There are a few problems with the tank collision as they exist.  Currently, speed and direction of travel (aka, velocity) are not taken into account.  No matter at what angle a player's tank collides with another tank, it's direction is moved in a due direction (north, south, east, or west).
+
There are a few problems with the tank collision as they exist.  Currently, speed and direction of travel (aka, velocity) are not taken into account.  No matter at what angle a player's tank collides with another tank, it's direction is moved in a due direction (north, south, east, or west).  If the game is to be brought into a bit closer line with reality (or perhaps bolo-reality), tanks should bounce away from their impact.
 +
To do this would require knowing where on the tank that the impact has taken place as well as the direction of movement of the tank, not necessarily the direction the tank is pointing.
= Tank on Non-Tank Collisions =
= Tank on Non-Tank Collisions =
This refers to tanks when colliding with pillboxes and buildings.
This refers to tanks when colliding with pillboxes and buildings.

Current revision

This page will deal with collisions and some aspects of physics, as these two topics are intertwined.

Contents

Tank on Tank

The Way They Are

As of 1.16, tank collisions are handled completely on the client side. Depending on if a tank has collided, it's position and speed is adjusted. Thus, through the adjustments in a tank's speed and position does collision become related to the server.

Each game tick a function playersCheckCollision() is called, found in the players.c file.

  • The world x and world y coordinates (via bit-shifting of the tank's map coordinates) of the player's tank are matched up against every other active tank's world x and world y coordinates.
  • If the distance between the axis of the tanks is less than 256 (there are 256 world coordinates in every map tile), then it was denoted which value is larger: the tank's component or the other tank. Using the Pythagorean Theorem, we can see that the furthest distance in which tanks would collide can be about 362 world coordinates (a = 256, b = 256, c = 362). This equates to about 1.4 map squares, which is a problem. More on this below.
  • Going back to the tankCheckGroundClear() function called - found in tank.c - the actual adjustments are made to the tank.
    1. The tank speed is reset to zero.
    2. If the player's tank is south of the tank that it's hitting, we move it's position due south by eight world coordinates. The same thing goes for any other direction. For instance, if the player's tank is east of the tank it's colliding with, the player's tank is moved eight world coordinates east.
    3. If the distance of either component (x or y) was less than half a map square away, a rand() function was called to try and move the tank out of the way. This comes about (mainly) because of starts. If you'll notice when a bunch of players join at once and spawn in the same spot, they seem to "dance" around until they are not colliding anymore. The dancing is a result of the rand() function calls.


Quick Fixes

The initial fix was to first get rid of the component checking and implement the Pythagorean equation. This will represent each tank as a circle. So while it's not a true representation of the in-game object, it comes close enough for our purposes. By using the Pythagorean equation, we can also specify how close tanks should be before they are considered "colliding". Raising this number past 256 will put something to the effect of a buffer-zone around each tank whereby no other tank can enter. Lowering this number to something around 140 will allow tanks to "overlap" one another.

Another quick fix was not to simply stop any tank that was found to be in collision with, but rather, decrement it's speed by one unit. In true physics, the rate of deceleration would depend on both body's mass and speed and elasticity, but those are things we can only hope are included for version 2.0. By slowing down the tank, you still allow it to move along and let the player change his tank's course of direction. This eliminates a lot of the "stickiness" that players complain about.

The function calls to rand() (which generates a random number) work for the moment, but a better spawning algorithm should be looked into. For example, say there is only two spawns on a map where 16 players are active. Sooner or later, two tanks are bound to spawn in the same start. Instead of shuffling them around, a temporary no-clip mode could be given to each player that has spawned at that point until they are found to be greater than some arbitrary distance apart (half a map or full map square). While the no-clip check and enforcement should be contained in the collision-code section, the initial decision to give these tanks no-clip should be made within the starting point code section.

Permanent Fixes

Use a two-dimensional physics library that adjusts for tweaking of many variables. The tweaking of variables will allow for greater customization of mods and control in the future.


Physics

There are a few problems with the tank collision as they exist. Currently, speed and direction of travel (aka, velocity) are not taken into account. No matter at what angle a player's tank collides with another tank, it's direction is moved in a due direction (north, south, east, or west). If the game is to be brought into a bit closer line with reality (or perhaps bolo-reality), tanks should bounce away from their impact.

To do this would require knowing where on the tank that the impact has taken place as well as the direction of movement of the tank, not necessarily the direction the tank is pointing.

Tank on Non-Tank Collisions

This refers to tanks when colliding with pillboxes and buildings.

Personal tools