BerryBots forums

It is currently Fri Jul 19, 2019 11:28 pm

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Wed Sep 23, 2015 1:42 pm 
Offline

Joined: Wed Sep 23, 2015 12:17 pm
Posts: 22
In the specs it is given that ships loose energy when colliding wit walls depending on impact angle:

Quote:
If it just grazes the wall, this is only a small percentage of its speed; if it slams directly into a wall, it will lose half of its speed. It doesn't take any damage.


How is the actual calculation formula? Does it loose just the normal (reflected) component of the velocity or the magnitude of the velocity (speed)?


Last edited by sadd on Thu Jun 20, 2019 7:38 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Wall game physics
PostPosted: Wed Sep 23, 2015 6:12 pm 
Offline
Site Admin
User avatar

Joined: Sat Nov 17, 2012 5:03 am
Posts: 88
It's based on the normal of the velocity against the wall - it loses 50% of that component of its velocity (and it's reversed, since you bounce off). Here's the actual code, which applies a force of 1.5x the normal in the opposite direction (WALL_BOUNCE = 0.5): stage.cpp#L879


Top
 Profile  
 
 Post subject: Re: Wall game physics
PostPosted: Wed Sep 23, 2015 7:35 pm 
Offline

Joined: Wed Sep 23, 2015 12:17 pm
Posts: 22
That's what I thought. But my targeting system including wall bounces predictor is still somewhat off... I guess the error lies elsewhere :). Thank you.


Top
 Profile  
 
 Post subject: Re: Wall game physics
PostPosted: Mon Nov 16, 2015 6:44 am 
Offline
User avatar

Joined: Mon Nov 16, 2015 6:04 am
Posts: 6
If this is to defeat sanic, if I remember correctly I had it add a decent component of perpendicular force to its path between wall bounces so as to throw of linear leads somewhat (even though at the speed it is travelling, such a tiny adjustment shouldn't effect much). I'd recommend testing against an even simpler bot which bounces off of walls without any other actions.


Top
 Profile  
 
 Post subject: Re: Wall game physics
PostPosted: Tue Nov 17, 2015 1:17 pm 
Offline
User avatar

Joined: Mon Nov 16, 2015 6:04 am
Posts: 6
Not sure if I've got to edit posts, or if they're merged automagically, but another point of note is that in addition to the partially inelastic collision, you can't treat the ships as infinitesimally small points -- they've got a radius.

Here's a quick test I've been putting together, and this is about as close as I can get it:
https://gfycat.com/WanSmartGorilla

(The ship randomises its velocity, then puffs every 20 ticks in its current heading, to maintain speed)


Top
 Profile  
 
 Post subject: Re: Wall game physics
PostPosted: Thu Jun 20, 2019 6:49 pm 
Offline

Joined: Wed Sep 23, 2015 12:17 pm
Posts: 22
I know it has been forever, but in case anyone else is interested in the future... I pretty much forgot about berrybots (unfortunately) and just picked it up again a couple of days ago.

You guessed right, my errors were due to the finite radius of the bots (it's 8 in the game's units if anyone else wonders). Unfortunately I don't have your Sanic, so I can't test it against that (maybe anyone has still a copy?).


Top
 Profile  
 
PostPosted: Mon Jun 24, 2019 11:58 am 
Offline

Joined: Wed Sep 23, 2015 12:17 pm
Posts: 22
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 :).


Top
 Profile  
 
PostPosted: Wed Jun 26, 2019 1:31 pm 
Offline

Joined: Wed Sep 23, 2015 12:17 pm
Posts: 22
So I just quickly implemented my idea with the "continuous time collisions", and it seems to work fairly well. I feared that it would slow down berrybot quite a bit, e.g. because one has to solve quartic equations fairly often with complex numbers, but it doesn't really make a dent as of now. Wall and ship-ship are continuous, but laser and torpedos are still discrete/integer time.

I actually neither can't upload the files here (stage.cpp, stage.h are modified), nor put them directly in the post. So I will only upload them at github or something when I've cleaned them up more.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group