Deactivate keyboard input on collision

Question

I'm creating an online-canvas-game with a tank as player object.

Now I have several structures in my canvas, that shouldn't be able to be overdriven by the tank...
My solution is to detect the collision like that:

if(hero.x > reactor[i]['x'] - 32 && hero.x <= reactor[i]['x'] + 32
   && hero.y > reactor[i]['y'] - 32 && hero.y <= reactor[i]['y']){
    collidetop = true;
}

if(hero.x > reactor[i]['x'] - 32 && hero.x <= reactor[i]['x'] + 32
   && hero.y >= reactor[i]['y'] && hero.y < reactor[i]['y'] + 32){
    collidebottom = true;
}

if(hero.x > reactor[i]['x'] - 32 && hero.x <= reactor[i]['x']
   && hero.y > reactor[i]['y'] - 32 && hero.y <= reactor[i]['y'] + 32){
    collideleft = true;
}

if(hero.x > reactor[i]['x'] && hero.x <= reactor[i]['x'] + 32
   && hero.y > reactor[i]['y'] - 32 && hero.y <= reactor[i]['y'] + 32){
    collideright = true;
}

The hero object is the tank, hero.x the x-coordinate, and so on...
Now I'd like to deactivate the keyboard input for the direction key, if the objects collide...
For this reason I have the variables wok, aok, sok and dok - they all contain booleans.
If wok = false, then the key "w" is deactivated...
I've connected the collide variables to the keyboard inputs:

if(collidetop == true){
    sok = false;
}
if(collidetop == false){
    sok = true;
}
if(collidebottom == true){
    wok = false;
}
if(collidebottom == false){
    wok = true;
}
if(collideright == true){
    aok = false;
}
if(collideright == false){
    aok = true;
}
if(collideleft == true){
    dok = false;
}
if(collideleft == false){
    dok = true;
} 

My problem is: if the tank doesn't collide the other object any more, the keys stay blocked... Could you help me with that?

Answer 1

Say your tanks has driven into a wall. It shouldn't be able to move forward anymore. In this case you disable the key that gives the 'move forward' command however I think this is the wrong way of looking at it. You can still give the tank the move forward command, that shouldn't be a problem, what really is stopping it from moving forward is the wall.

I would take the following approach:

A tank/users should always be able to request to move however the physics system should decided if the tank moves. This means that you would have the following setup:

1: Tank wants to move forward
2: The physics system stores the old position of the tank
3: The physics system moves the tank forward
4: The physics system checks if the tank now collides with something
5: If the tank collides with something move it back to old position, if it didn't collide with something everything is good, keep it where it is.

Having the physics system do all the movements also has the added benefit that other things than user input can move the tank, for example explosions, as long as they request the physics system to move it everything should be OK and you only have to write the code once.

Answer 2

Deactivating input isn't the usual way to react to environment collisions. In a nutshell, it's probably a better idea to affect your tank position when a collision is detected. Roy T. just gave you one proper solution.

You could also do as follows without modifying too much code, just stick the tank to one of the reactor's edges when a collision is detected:

if(hero.x > reactor[i]['x'] - 32 && hero.x <= reactor[i]['x'] + 32 &&
   hero.y > reactor[i]['y'] - 32 && hero.y <= reactor[i]['y'] - 28){
    hero.y = reactor[i]['y'] -33;
}

if(hero.x > reactor[i]['x'] - 32 && hero.x <= reactor[i]['x'] + 32 &&
   hero.y >= reactor[i]['y'] + 28 && hero.y < reactor[i]['y'] + 32){
    hero.y = reactor[i]['y'] +33;
}

if(hero.x > reactor[i]['x'] - 32 && hero.x <= reactor[i]['x'] - 28 &&
   hero.y > reactor[i]['y'] - 32 && hero.y <= reactor[i]['y'] + 32){
    hero.x = reactor[i]['x'] -33;
}

if(hero.x > reactor[i]['x'] + 28 && hero.x <= reactor[i]['x'] + 32 &&
   hero.y > reactor[i]['y'] - 32 && hero.y <= reactor[i]['y'] + 32){
    hero.x = reactor[i]['x'] +33;
}

This glitches easily if your tank moves fast compared to the reactor's size, but it should at least give you the satisfaction of quickly seeing something that works.

The topic of game collisions and physics in general is huge, so I recommend you find a good resource to learn the basics. Or if you just want collisions but don't want to learn the details, you could try out an existing library, such as Box3DJS (I've not tested it personally so I don't know if it's a good one).