Quick BASIC Question

[+atari2600land]

How would I make player0 not go through the walls here? I think the wall is about x=58-130 y=42-60 (at least so player0 can't hit his head against it.)

301 for b=0 to 10 : pfhline 0 b 31 off : next
302 pfhline 9 5 21 on : x=25 : y=80
303 w=150 : z=10 : COLUP1=6 : COLUP0=42
308 player1:
 %01100110
 %00100100
 %00100100
 %10111101
 %10111101
 %11111111
 %01100110
 %00111100
end
322 player0:
 %1100011
 %0100010
 %0010100
 %0001000
 %0001000
 %0111110
 %0001000
 %0001000
 %0011100
 %0100010
 %0100010
 %0100010
 %0011100
end
335 drawscreen
340 player1x=w : player1y=z : player0x=x : player0y=y
350 if joy0left then x=x-1
355 if joy0right then x=x+1
360 if joy0up then y=y-1
365 if joy0down then y=y+1

[CPFace]

Well, it depends on what you're trying to accomplish. If it's just that you're using the playfield to draw a wall that you never want the player0 sprite to go through, then here's how I got it to work in melbourne tatty using collision detection.

301 for b=0 to 10 : pfhline 0 b 31 off : next
 rem I directly initialize the coordinates of the player0 sprite and use x and y to store the sprite's
 rem previous position.
302 pfhline 9 5 21 on : player0x=25 : player0y=80
303 w=150 : z=10 : COLUP1=6 : COLUP0=42
308 player1:
 %01100110
 %00100100
 %00100100
 %10111101
 %10111101
 %11111111
 %01100110
 %00111100
end
322 player0:
 %1100011
 %0100010
 %0010100
 %0001000
 %0001000
 %0111110
 %0001000
 %0001000
 %0011100
 %0100010
 %0100010
 %0100010
 %0011100
end
 rem First, we save the player sprite's current position in case we have to go back to it.
335 x = player0x: y = player0y
 rem Next, we poll the joystick and move the player0 sprite.
350 if joy0left then player0x=player0x-1
355 if joy0right then player0x=player0x+1
360 if joy0up then player0y=player0y-1
365 if joy0down then player0y=player0y+1
 rem You may need to add some code here to make sure that the player is staying within the
 rem screen bounds.
 rem Then we refresh the screen.
370 player1x=w : player1y=z
375 drawscreen
 rem Now we check to see if there's a collision between the player0 sprite and the playfield.
 rem If there is, we return the sprite to the position it was in before the player moved the joystick.
380 if collision(player0, playfield) then player0x=x: player0y=y
 rem And after conducting any other game logic that you need to do between frames, we'd loop
 rem back to line 335.

 

Visually, it'll look like the player0 sprite can press one pixel into the wall as long as the player holds the joystick against it, but when the joystick is released, the sprite will return to where it's supposed to be. This scheme also prevents the player from "hugging" the wall and sliding across it by holding the joystick diagonally.

 

Hope that's a little help.

[SeaGtGruff]

How would I make player0 not go through the walls here? I think the wall is about x=58-130 y=42-60 (at least so player0 can't hit his head against it.)

I think it depends on what you want to have happen when the player hits the wall.

 

For example, if you want the player to get electrocuted (as in Berzerk), then just check for player0 colliding with the playfield, and if that happens, go to a "player electrocuted" routine, like this:

 

electrocuted.bas

electrocuted.bas.bin

 

Or, if you want the player to rebound off the wall (as in Adventure), then it will be more complicated. What I did in my unfinished Reventure WIP was to read the joystick and store the player's motion as x and y difference values-- i.e., x = -1 if moving left, x = 1 of moving right, x = 0 if not moving left or right, y = -1 if moving up, y = 1 if moving down, and y = 0 if not moving up or down. After I read the joystick and set the difference values, I applied them to the player's position, drew the screen, checked for a collision, and if player0 was colliding with the playfield, I subtracted the difference values to restore player0's original position before checking the joystick again, like this:

 

rebound.bas

rebound.bas.bin

 

Michael Rideout

[+atari2600land]

The code was cut from a game I was working on, that's why the playfield wasn't viewable. I went and added some animation on the Bezerk-like robot, and I went and added in the second code (Adventure-like), and my guy started way low off the screen. I had to press up just to view him. Actually, I just wanted him to not bump back at all (and not be electrocuted). I suppose making him freeze once he hit the playfield would be easier? Here's the whole thing, the problem I'm having starts at line 300. (By the way, if anyone remembers my last Mr. Flanksteak game, this one is gonna be way better and be 8 or even 16k, because I've learned so much from the couple months I made the last one.)

flanksteak2.bas

[CPFace]

There's just one small problem with the rebound.bas code -- it doesn't set the sprite's coordinates to a "sane" value before it enters the loop. You can probably solve the problem by changing one line:

 

302 pfhline 9 5 21 on : x=25 : y=80 : player0x=0 : player0y=0

 

That way, when it gets down to line 340, the sprite coordinates will be:

 

player0x = player0x + x = 0 + 25 = 25

player0y = player0y + y = 0 + 80 = 80

 

Actually, I just wanted him to not bump back at all (and not be electrocuted).

 

What did you want to have happen when the player touches the wall then? The way I read it, I thought you wanted the playfield to act like a brick wall so that the player0 sprite can't go through it. The whole "bump back" idea is just something to readjust the player's coordinates so that he can't go further than one pixel into the wall. What effect are you looking for if not that?

[+atari2600land]

What did you want to have happen when the player touches the wall then? The way I read it, I thought you wanted the playfield to act like a brick wall so that the player0 sprite can't go through it. The whole "bump back" idea is just something to readjust the player's coordinates so that he can't go further than one pixel into the wall. What effect are you looking for if not that?

I do want the wall to be so player0 can't go through it. I just figured there would be a way that player0 couldn't even go one pixel into the wall. If there isn't, then I guess I'll use the rebound thing.

 

EDIT: I applied the rebound code to screen 1 and noticed something: There's no part of the code that tells player0 to not go off the screen. (i.e. if x>160 then x=160). I think since Reventure had walls on that part of the screen, I think I'll add walls, too. This game is sorta like Adventure, so that should work.

Edited August 14, 2006 by atari2600land

[+atari2600land]

Here's what I have so far. Basically, I want to have you move to a new screen once you touch the items. It's not really a game per se, just an experiment to see how much stuff I can cram into 4K, so forget about it being 8 or 16K for Mr. Flanksteak 2. I could make Mr. Flanksteak 3 once I've learned more new stuff. Screen 1 is the key from Adventure, screen 2 is the enemy robot from Berzerk. Maybe I should have an alphabet thing going. Screen 3 could be the tank from Combat.

flanksteak2b.bin

Edited August 14, 2006 by atari2600land

[SeaGtGruff]

There's just one small problem with the rebound.bas code -- it doesn't set the sprite's coordinates to a "sane" value before it enters the loop. You can probably solve the problem by changing one line:

 

302 pfhline 9 5 21 on : x=25 : y=80 : player0x=0 : player0y=0

 

That way, when it gets down to line 340, the sprite coordinates will be:

 

player0x = player0x + x = 0 + 25 = 25

player0y = player0y + y = 0 + 80 = 80

I didn't think of that when I changed the code; I'm glad you caught it! But it worked anyway, since batari BASIC clears everything when it starts up, hence player0x and player0y start at 0, and then later on the initial values of x and y get added to them. Given that x and y are now being used as difference values in that code, the way I should have coded it was like this:

 

302 pfhline 9 5 21 on : player0x=25 : player0y=80

Michael Rideout

[CPFace]

I didn't think of that when I changed the code; I'm glad you caught it! But it worked anyway, since batari BASIC clears everything when it starts up, hence player0x and player0y start at 0, and then later on the initial values of x and y get added to them.

 

Huh, true. I wonder where his "starting off the screen" problem was coming from then. O_o

[+atari2600land]

Well, here's the final thing, with all the bugs taken care of, and all the code cleaned up. I wanted to see how much stuff I could cram into 4K, and boy did I cram:

Can't get more crammed than that!

flanksteak2c.bin