Jump to content
IGNORED

WIP: Dodgeball


tschak909

Recommended Posts

Currently working on the following code snippet:

 
BLtoPF:
        LDA CXP0FB,X
        BPL nextBLtoPF
BLtoPFCollide:
        JSR RecallPlayerPosition
        LDA BALLD0
        ADC #$08
        AND #$0F
noJigger:
        STA BALLD0
nextBLtoPF:
        JSR SavePlayerPosition

Oddly enough, if I apply an additional step after AND #$0F of masking off against #$03 (and #$03) to find the N, S, E, W directions), The ball gets stuck in the wall going back and forth...

 

 

BLtoPF:
        LDA CXP0FB,X
        BPL nextBLtoPF
BLtoPFCollide:
        JSR RecallPlayerPosition
        LDA BALLD0
        ADC #$08
        AND #$0F
 
        ;
        ; added this
        ;
        STA BALLD0
        LDA BALLD0
        AND #$03
        BNE noJigger
        LDA BALLD0
        ADC #$01
noJigger:
        STA BALLD0
nextBLtoPF:
        JSR SavePlayerPosition

Link to comment
Share on other sites

Ok, here's the fully working PONG bounce routine, once I refactor the ball motion code, I'll switch this to deal with all of the balls.

BLtoPF:
        LDA CXP0FB,X
        BPL nextBLtoPF
BLtoPFCollide:
        JSR RecallPlayerPosition
        LDA BALLD0
        ADC #$08
        AND #$0F
        STA BALLD0
        LDA BALLD0
        AND #$03
        BNE nextBLtoPF
        INC BALLD0
nextBLtoPF:
        JSR SavePlayerPosition

Funny how the carry serendipitously helps to pick a direction vector that DOESN'T EVER loop (I checked, I left this thing running, all night.)... whew.

 

Can anyone explain _WHY_ this little accident worked?

 

-Thom

 

(edited to attach current bin and asm)

 

dodgeball.bin

dodgeball.asm

Link to comment
Share on other sites

Thom,

	LDX #$04
BLtoPF:
	LDA CXP0FB,X
	BPL nextBLtoPF
BLtoPFCollide:
	JSR RecallPlayerPosition
	LDA BALLD0
	ADC #$08       <----- The carry is always set at this point. It's been set since "BCC .mainLoop" was not taken.
	AND #$0F              (so you are adding 9 instead of .
	STA BALLD0
	LDA BALLD0     <----- The accumulator already has the value of BALLD0, see "STA BALLD0" instruction right above.
	AND #$03
	BNE nextBLtoPF
	INC BALLD0
nextBLtoPF:
	JSR SavePlayerPosition
Link to comment
Share on other sites

Noted, I've made note in that routine, and have removed the spurious load. Thanks :)

 

Meanwhile:

 

...a day later, that very long ball direction to X Y coordinate routine that had 16 separate hard-coded compares, has been shortened into a single routine which looks up the requested vector, looks up the requested X and Y values, and adds them. I am using the fact that I am only doing 8-bit adds, and throwing away the carry to make the addition wrap around to the final number, for dealing with a negative number (the $FE, and $FF values are two's compliment negative numbers, which can be added to the current X and Y values to get a value -1, or -2), simplifies and gets rid of a need for a compare. I gained back over 200 bytes of ROM space, in the process, and was able to work through the algorithm in the process. Am happy.

 

-Thom

l8Jwu6H.png

Link to comment
Share on other sites

And now that the ball motion code is refactored, I can add direction vectors for the two missiles, and get them bouncing. Attached is current code, with binary, showing everything working.

 

Now, it's time to start trying to add in rudimentary ball/missile to player collision for scoring.

 

-Thom

 

p.s. (I'm so happy that I'm actually progressing now, after months of writing, restarting, debugging, figuring out why my original approaches were wrong, practicing writing better kernels, and finally coming back to this...) It's actually starting to come together, and you guys have been a huge help.

 

 

dodgeball.asm

dodgeball.bin

Link to comment
Share on other sites

Currently implementing enough collision detection for a play test.

 

There won't be a timer, or start/stop of game, so you can just pummel each other, but I am getting enough ready so that people can mess with it.

 

Am implementing the collision logic and debugging, as fast as I can, and I will need lots of input, even if that feedback is that it truly sucks. :) I _will_ make it un-suck. :)

 

-Thom

  • Like 1
Link to comment
Share on other sites

Well guys, after three very long months, some 14 rewrites, a major stop to work on the Atari Manual Database, a restart after doing a whole smattering of kernel exercises...

 

I've managed to hit the first playable test milestone!

 

This is a two player game, get somebody to play with you!

 

Here's what works so far:

 

* Players can pick up their own ball. This must happen in order to throw it (potential game option)

* Players can throw ball in one of any 8 directions corresponding to joystick by pressing fire while holding the joystick in the desired direction. Player will stop during a throw.

* Players can throw ball at opposing player for a single point

 

Other features:

 

* Player balls have a limited decay time, they will not make it all the way across the screen, and will die after 64 frames.

* If a player's ball collides with other player's ball, the two balls will bounce away from each other, and die within 8 frames

* If a player's ball collides with another player, the ball will bounce away from player, and die within 8 frames (TBD: Make player scoot slightly)

* If a player collides with the computer ball, at least one point will be subtracted (unpredictable, and it's gonna ($#@( stay that way)

* If the computer ball collides with anything, it will reflect direction. (this means, you can, for example, shoot the computer ball with your ball to change its direction)

* If you throw the ball, you must pick it back up, to throw it again. (as mentioned before, but I thought i'd mention it again..potential select feature)

 

Note: Since lots of things, many of which can be done by a player, cause a change in computer ball direction, this can be a potential strategy.

 

Known bug:

 

* Once a ball is thrown, you can hold down the fire button, and the ball will keep travelling (because the decay keeps getting reset).

 

Still TBD:

 

* way too much. About half of my anticipated feature set is implemented.

 

Enjoy, fellas. Please provide feedback.

 

-Thom

dodgeball.bin

dodgeball.asm

  • Like 1
Link to comment
Share on other sites

I'd love for everybody who downloaded, to say something, anything about the play test. The more data I have, the better. :) it's all I have, since I have nobody else here at my house to play test it with. :)

 

(I'm even resorting to use MAMEhub to play it with a friend in Maryland, just so I can get some feedback)

 

-Thom

Link to comment
Share on other sites

I found a bug which I presume has to do with the way the Pong reflections are computed. It shows up when either player throws their ball in a direction that has an upward or leftward component (that is: up-right, up, up-left, left, down-left) while the player is also butting up against a wall, so that the ball has no room to move before a collision happens. The screenshot below was taken after the green player had thrown its ball due left normally (with room for the ball to travel for a few frames) against the far left wall, and the ball was at rest. However, if the player had instead thrown the ball in the same direction while butted up against the wall, the ball's position seen in the screenshot would be where it would *start* flying from. It's as if the game short-circuited through 64 frames' worth of collision detection before rendering the ball, and then did it again normally for another 64 frames. Perhaps it's related to the decay-reset bug?

 

The bug does not happen when the ball is thrown right, down-right, or down. I also replicated it on real hardware.

 

post-6010-0-61051000-1474340618_thumb.png

 

 

Changing topic, it feels weird that after dropping your ball ("throwing" with no direction) you can't pick it up again until the throw decay ends. Is that on purpose?

Link to comment
Share on other sites

Thanks! Although, I can't figure out a workable robot algorithm for a computer player. At least in Video Olympics, the correlation between Y and BALL can not only be done, but the simple act of not updating in intermittent twitches creates a potentially winnable space.

 

The problem is coming up with something that doesn't involve just banging up against the wall, going towards the ball... If there were no obstacles, it would be a no brainer...

 

-Thom

  • Like 1
Link to comment
Share on other sites

Thanks! Although, I can't figure out a workable robot algorithm for a computer player. At least in Video Olympics, the correlation between Y and BALL can not only be done, but the simple act of not updating in intermittent twitches creates a potentially winnable space.

 

The problem is coming up with something that doesn't involve just banging up against the wall, going towards the ball... If there were no obstacles, it would be a no brainer...

 

-Thom

You're welcome! :) Agree it's more complex; maybe you could split it up and combine that kind of AI algorithm with a branch that handles trying to circumvent the objects that pop up in the way - changing direction for a short duration when that happens (long enough to get clear of the object) and then attempt to run towards the ball again.

Link to comment
Share on other sites

I found a bug which I presume has to do with the way the Pong reflections are computed. It shows up when either player throws their ball in a direction that has an upward or leftward component (that is: up-right, up, up-left, left, down-left) while the player is also butting up against a wall, so that the ball has no room to move before a collision happens. The screenshot below was taken after the green player had thrown its ball due left normally (with room for the ball to travel for a few frames) against the far left wall, and the ball was at rest. However, if the player had instead thrown the ball in the same direction while butted up against the wall, the ball's position seen in the screenshot would be where it would *start* flying from. It's as if the game short-circuited through 64 frames' worth of collision detection before rendering the ball, and then did it again normally for another 64 frames. Perhaps it's related to the decay-reset bug?

 

The bug does not happen when the ball is thrown right, down-right, or down. I also replicated it on real hardware.

 

attachicon.gifdodgeball.png

 

 

Changing topic, it feels weird that after dropping your ball ("throwing" with no direction) you can't pick it up again until the throw decay ends. Is that on purpose?

 

wow, that's a nifty bug!

 

As for the other bug, I will fix this one by having fire button fire in the last thrown direction (or right if not previously set).

 

Thanks!

 

-Thom

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...