So I looked a little bit further into it, and as far as I can understand from the berrybots src collisions in general are handled a little bit unintuitively.

If I understand everything correctly I would argue it's actually a little bit buggy as well, and optimal gun strategies to defeat my bots who often collide with walls (and I guess Frohman's Sanic as well), would need to copy the somewhat flawed berrybots collision logic instead of an intuitive somewhat physical one.

But maybe I understand the code wrong, so here my understanding:

The relevant code is in

*stage.cpp* in

*Stage::moveAndCheckCollisions()*. This method wants basically time evolve the movement of ships while checking for collisions with walls, laser, torpedos and ships. Laser and torpedo collision are only checked at the discrete times (which I'm happy with, at least it's consistent logic).

For wall (and ship) collisions each time step is divided in smaller "sub-ticks" and several smaller time stepping is done, i.e.

**Code:**

int moveIntervals = ceil(moveDistance / COLLISION_FRAME);

intervals = std::max(intervals, moveIntervals);

// @ohaas: COLLISION_FRAME = 4 from bbconst.h

If a bot would hit a wall when pushed in a sub-tick it is instead stopped (!) at the location before the collision. Stopped means the rest of the sub-tick evolution is not done, so only the next full time step moves the ship again. The nice thing about this approach is that it is fairly simple and I can't see how it completely messes up (i.e. crashes or whatever). But it introduces some fairly random aspect to the collisions.

Let's think about a somewhat realistic worst case: We have a stage of about ~1000 width, so maximum velocity is ~50 when moving only in +-x-direction. intervals is then 13, our sub-tick is then 1/13. We hit the wall at the worst possible moment at timestep n+dtSubTick-eps, where eps is as small as possible. This means our ship might stop a distance of 4 away from the wall, "sticks" there (or stopped as the code calls it) for the remaining 12 sub-ticks, and then the collision force is applied and only in the next full time step the ship moves again. The final maximum error in position is then ~27 (4+12/13*50/2, first offset plus relative remaining subticks times the halfed velocity from the bounce), compared to one would expect for continuous time. So the error depends on COLLISION_FRAME (which could be reduced), the impact speed of the ship (which can be fairly large), and when the ship hits the wall during the sub-ticks and how long it is stopped/sticks at the wall for the remaining subticks.

Of course if one would use (integer) discrete time (and no sub-ticks) the error would be up to ~75 compared to continuous time, but to some extent it would be simpler to understand without looking at the code.

Compared to RoboCode it's obvious that they don't have the problem, since the robos stop when colliding with the wall anyway.

In general it's an unintuitive mixture of discrete and (almost due to sub-ticks) continuous time stepping.

Personally I would prefer if the underlying physics would be (approximately) continuous time, so players/bots can use analytic or algebraic calculations to predict movement, instead of basically copying the time stepping schema of berrybots in their own code... I'm not sure exactly how I would deal with it, but probably extend the sub-ticks idea to almost everything of the game physics (to make it approximately continuous) and only the bot/user is working and inputting commands in the discrete domain so to say.

Another much simpler solution would be to argue that collisions just have this random component, but make them less viable as a strategy by introducing collision damage as discussed in other threads

.