Array Handling

I now have the code to test weither a block is walkible or not on one tile what im wanting to do is test it for all the tiles by using the following:



else if ((keyboardState.IsKeyDown(Keys.Up) || (gamepad1State.ThumbSticks.Left.Y > 0f)) && (Sblock == false))
{
for(int x = 0; x <= 65; x++)
{
if ((charBounds.Intersects(mBlock[x])) && (Nblock == false) && (Wblock == false) && (Eblock == false))
{
Sblock = true;
}
}



This in theory would check all the rectangles ive made in the 'mblock' array for a collition then stop the movement of the direction but it doesn't work.. for it to work id have to do:



if (((charBounds.Intersects(mBlock[0])) || ((charBounds.Intersects(mBlock[1])) || ............. || ............) && (Nblock == false) && (Wblock == false) && (Eblock == false))



something im doing wrong or something or going about it the wrong way?

You don't say what Wblock, Sblock, Eblock, etc are.

I think you should read up on Pathfinding algorithms before moving any further into passability implementation, you might not need them right now, but they are likely to give you quite a few ideas on how to handle this issue.

WBlock etc is irrelivant. But basically they are used to disable the direction key if the certain side of the block is collided (WBlock = WestBlockFace).

In the reply to the A* path finding isn't this just for AI? or can I use it to configure when my controllible charcter can or cant move?

Im really finding this hard, didn't realise there was so much code just to make a tile immpassible. Im basically tring to make a bomberman type clone so there are going to be lots of blocks which I need to set to unwalkible and using that code is all I have come up with.. If instead of making tiles unwalkible and force the character to move only on walkible tiles it might make it easier.

wish I could find another bomberman type game with the xna/c# source code to give me ideas but cant find any in that laungage that work.

Think for example in Diablo, the player just points a target and the avatar finds a way to reach it much on its own, Its not just for AI, also, since pathfinding (and A* is not the only method) needs to know about passability, you might do well in establishing a system that works for pathfinding algorithms as well as simple direct control collision, like I said, they might give you ideas

Well, maybe I misunderstood, but pathfinding seems to be totally irrelevant to the issue. As I can see, the OP wants do decide if he can walk on the next block or not. But it's not really clear what the OP wants. MAybe he wants to check walkable tiles in a row/column?

One thing I see is that Sblock is not initialized to false before the loop.

Why are you checking the whole board to check for movement? If I understand what you doing correctly your going to be looking at all tiles to see if movement is possible there; therefore if on any square movement would be blocked then you cannot move at all, or if on any square movement would be possible then you can move regardless. But it sounds like you want it to be if on a certain square you cant move in a direction then movement is blocked. So why not just get the square to be moved into from the avatar's location and direction and check only that one?

Anyway I think the problem is that since your checking the whole board the loop essentially does nothing. ie if in any case I can go north, then right now i can go north means I can always move.

The code above works for all directions with the exception of the way Nblock etc are called. At the end of the directional componants I have a bit that says if 'not' colliding set all the Nblocks etc to false. allowing all directional keys to work again.

What it basically does is disable the key in question when collition happens but allows the other keys to remain active till the collition is cleared then all is reset back to false. It is a crude way of testing for collition I know but is the only way I have come up with that works.

so if the character was moving across the screen to the left and hit the block Eblock would be set to true disabling the use of the left directional key till the collition was cleared but because Nblcok, Sblock and Wblock are still false the other keys would work. ie. the user can move away from collition. (as left key is useless anyways at collition as there is a block in the way.

I have found another toutorial which deals with collition and other aspects of my bomberman type clone which I am going to follow and implement today although it does use classes and other complex tasks which im unfamiliar with. By first glance what they do to test for collition is test for the intended move instead of the move it's self then say if the charatcer can move there or not.

Ive spent weeks trying to draw a working map with block collition etc. with no avail so hopefully if I can get my head around this toutorial Ill boost progress drastically.

Sorry I didn't get back to you earlier been one of those weeks.

You really need to change the way you are doing your tests.

What you want to do is in your movement method test to see if they can move in that direction and if they can, let them move, if they can't, don't let them move. This would take care of the problem you are having because you would never be disabling the ability to move. You just ignore the movement if it is not allowed.

Sorry I didn't get back to you earlier been one of those weeks.

You really need to change the way you are doing your tests.

What you want to do is in your movement method test to see if they can move in that direction and if they can, let them move, if they can't, don't let them move. This would take care of the problem you are having because you would never be disabling the ability to move. You just ignore the movement if it is not allowed.

It would also work to move them regardless, and if there is an intersection then move them back to outside whatever is blocking them.

Your current loop I'm guessing is something like this:
-Check possible intersections
-Block input accordingly
-take input
-react (everything else that happens)
-draw
-repeat

It's much easier to do it like this:
-take input
-check for intersections
-resolve intersections (move dude outside of whatever he is intersecting with)
-react
-draw
-repeat
@Nexus. That is still AI. You are just removing direct character control and replacing that with a layer of AI. This won't work for all games.

edit: this is pretty dependent on how your world is set up. If it's set up like a grid, then you can check whether a move is valid in real time, so you can just do something like


key = getInputKey();
if(checkMoveValid(key.direction))
Move(key.direction);


then checkMoveValid would look like:

CheckMoveValid(Direction dir){
if(worldGrid[currentLocation.x + dir.x][currentLocation.y + dir.y] == NON_TRAVERSABLE_BLOCK)
return false;
return true;
}


The code above works for all directions with the exception of the way Nblock etc are called. At the end of the directional componants I have a bit that says if 'not' colliding set all the Nblocks etc to false. allowing all directional keys to work again.

What it basically does is disable the key in question when collition happens but allows the other keys to remain active till the collition is cleared then all is reset back to false. It is a crude way of testing for collition I know but is the only way I have come up with that works.

so if the character was moving across the screen to the left and hit the block Eblock would be set to true disabling the use of the left directional key till the collition was cleared but because Nblcok, Sblock and Wblock are still false the other keys would work. ie. the user can move away from collition. (as left key is useless anyways at collition as there is a block in the way.

I have found another toutorial which deals with collition and other aspects of my bomberman type clone which I am going to follow and implement today although it does use classes and other complex tasks which im unfamiliar with. By first glance what they do to test for collition is test for the intended move instead of the move it's self then say if the charatcer can move there or not.

Ive spent weeks trying to draw a working map with block collition etc. with no avail so hopefully if I can get my head around this toutorial Ill boost progress drastically.

may not be important now, but doing this means that if two directions are blocked the collision will not be set. So you would need extra loops to check for multiple collisions.