Quadrophobia: Simple addition – complex options

I think I hit upon the one key ingredient I need to make this game work in a unique way, that’s still similar enough to the classic grid based puzzle games that it’s not too weird.

Initially I was thinking I would have portals (which I might) and rotation/flipping of the piece (also, a might), but keys seems to be stretching it and adding more than I want.

I thought of having breakable walls, but some of the idea I had just didn’t fit (using “damage” of the player’s move and reverse damage of the wall against the player).

I didn’t want to have a “crate” style movement game, because then, why not just make Sokoban.

But, watching a clip of Link pushing a block for some reason, even though it’s similar to a crate puzzle, made me think of moving the walls.  Instead of breaking them.  The beauty of this is that I can make walls have values.  The values of the walls are their “strength/resistance”.  If they are equal to the players move points of a side the player collides with a wall on that side, then the wall does not move, and the player stops moving.  If the wall has less points than the player, the difference between the two is how much the wall moves.  So if the player has a “4” move and the wall has a “2”, the wall moves 2 more spaces in the direction of the player.

Conversely, if the player has a 2 and the wall a 4, and the player hits the wall, the player would be pushed back 2.  This only counts if the player hits a wall and would normally have more moves PAST the wall.  If the player runs out directly on the space where the wall is, it will already stop where it needs to be, regardless of the wall value.

I could also add the ability to rotate a wall (this might be more than necessary and more than I really want to deal with, especially if I add rotating playing piece).  But I’m excited by the concept here.  I think this opens up a lot of possibilities – it forces layers to use math to figure out where the pieces are going to go, and gets them to place pieces/walls in particular spots so they can hit them in the future from a different direction, or push the player back a space where they couldn’t reach if they just used the default move options, etc…

Yes, I quite like it, and I think this is the route I’m going to take for my first addition in play rules/features.

When code you thought was done is broke

So I got my wall blocking code finished, or so I thought.  It took some work, but I was able to, basically do the following:

1) After player lands (or upon initial start of level), scan each direction (up, down, left, right).  If there is a wall, take the value of the corresponding wall position along the movement direction (for up/down that would be Y, for left/right, that would be X), then obtain a movement vector by subtracting the players current position from the wall position.  (there’s a bunch more crap in there regarding offsets (the wall isn’t in the *center* of the square, so I have to subtract half the square size to get the center of the square vs the wall location (edge))

2) Once I move, I scan again. And do this repeatedly.

3) Did you notice something missing?  Once I hit a wall, and move away, I never reset the piece to the “base” value (if no other wall is in the way).

4) I did, and I fixed that.

I thought it was all moving smoothly, but now going back to it after the holidays, I find that I have a weird bug where if I move to the left and hit the edge of the board, it’s changing the value for moving AWAY from the wall, but only once I move to that position adjacent to the wall.  This should never be happening, as the direction one moves is the direction that should be affected.  It should never affect a move in the opposite direction.

So I’ll have to look at the code tonight.  My initial glance was to check whether the array of directions were properly being set.  My directions and values are in a length-4 array.  Each index in the array corresponds to a move direction (0=up, 1=down, 2=left, 3= right).

Each value at a location refers to the number of spaces the piece can move in the appropriate direction.

The piece has a “baseMove” array and a “realMove” array.  The baseMove basically is the default move options for the piece.  The realMove is altered based upon things like hitting a wall (the only modifier right now, but I can imagine other things modifying that value — temporary powerups, etc…)

So when I actually move the piece, I call “realMove”.

In the code where I scan for walls, I check to see if the wall is hit, and if so, set it to that value (as noted above), however, if there is no other wall, it should revert to the default value.

What’s happening in my code is strange, because not only is it not reverting to the “default” value, the value being changed is not even the direction of the movement that it should be.

One would think that it was attributable to the indices being wrong (that is, I scan direction 1, but modify array index 2).  However, that’s not the case.  It only seems to be when I move leftward, so I’ll have to see what it is, exactly, that’s causing this.  I am debugging the move values to make sure that what I’m seeing in the move is actually what is happening (that is – if my base move is 2, and my “real” move is 1, and my piece moves 1, that’s “correct” – whereas if my base move is two, my “real” move is also 2, but the piece is moving 1, then I’d be in bigger trouble, because it would appear that my math for the starting/ending point is wrong.  But I think that math is correct, especially since it appears to work for the others.  It’s possible that I have to change a positive to a negative in some place in terms of modifying the move direction.

I guess I’ll find out tonight.