Thomas Jentzsch Posted April 28, 2009 Author Share Posted April 28, 2009 Some interesting ideas about scoring. I will definitely think about some of those. But first I need more free bytes (5 currently). And then I also would like to implement at least two ball angles. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 28, 2009 Share Posted April 28, 2009 Multiple ball angles and scoring are necessary. Shrinking paddles is a brilliant idea. Others... use background color? Or paddle/ball color? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 29, 2009 Author Share Posted April 29, 2009 Multiple ball angles and scoring are necessary. I have now 12 bytes free (almost 10%! ). Shrinking paddles is a brilliant idea. Yes, I have thought about that one too and I am pretty sure it is possible within 12 bytes. Others...use background color? Or paddle/ball color? I could do that, but I cannot imagine how to enocde the two scores. Maybe I could do some PF scoring, but I haven't found a good way here too. Which leaves multi-ball angles. Currently I am simply using the collision registers to detect that the ball has to bounce. What would trigger the different angles? Where the ball hits the paddle, I suppose. I doubt that this is possible within a few bytes... Hmm... :ponder: Quote Link to comment Share on other sites More sharing options...
potatohead Posted April 29, 2009 Share Posted April 29, 2009 (edited) I vote for the shrinking paddles. When you don't have any paddle left, you lose, the ball passes by one more time, then the game stops. Could the angles be a cycle? 45, 30, 15, 45, 30, 15, etc.... There would be some strategy in play then. Edited April 29, 2009 by potatohead Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 29, 2009 Share Posted April 29, 2009 Others...use background color? Or paddle/ball color? I could do that, but I cannot imagine how to enocde the two scores. Maybe I could do some PF scoring, but I haven't found a good way here too. Think of a single score, starting at 0. If R player scores, increment. If L player scores, decrement. -10 = L win. +10 = R win. Figure out some way to translate this to colors...$08 = neutral. $00 = left win, $0E = right win. Or color = L score, brightness = R score. Then you can encode all in a single byte and display with a single store. All of these schemes would be hard to interpret, but better in any case than forcing players to count on their fingers while they play. Which leaves multi-ball angles. Currently I am simply using the collision registers to detect that the ball has to bounce. What would trigger the different angles? Where the ball hits the paddle, I suppose. I doubt that this is possible within a few bytes... Hmm... :ponder: How about variable ball speeds instead of variable ball angles? Of course, same problem, I suppose...how to trigger. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 30, 2009 Author Share Posted April 30, 2009 How about variable ball speeds instead of variable ball angles? Of course, same problem, I suppose...how to trigger. That's easy: Fire button Quote Link to comment Share on other sites More sharing options...
iwan-iwanowitsch-goratschin Posted April 30, 2009 Share Posted April 30, 2009 How about variable ball speeds instead of variable ball angles? Of course, same problem, I suppose...how to trigger. That's easy: Fire button Make some carts for the Retrobörse, Thomas...... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 30, 2009 Author Share Posted April 30, 2009 Make some carts for the Retrobörse, Thomas...... I'll put it on my Kroko Cart. Quote Link to comment Share on other sites More sharing options...
BigO Posted April 30, 2009 Share Posted April 30, 2009 (edited) When you don't have any paddle left, you lose, the ball passes by one more time, then the game stops.I was thinking the other way around. As you score higher, your paddle gets smaller to give the opponent a fighting chance. While fighting for the winning point, your paddle would be like the size of the ball. I guess that the winner's paddle disappearing completely would be the "Game Over" indication, leaving the loser standing on the court with the remnants of their paddle to remind them of how soundly they'd been trounced or show how narrowly they'd lost. Edited April 30, 2009 by BigO Quote Link to comment Share on other sites More sharing options...
r_type2600 Posted April 30, 2009 Share Posted April 30, 2009 (edited) Others...use background color? Or paddle/ball color? I could do that, but I cannot imagine how to enocde the two scores. Maybe I could do some PF scoring, but I haven't found a good way here too. What about color coding the paddles this way: both start all green. With every passing ball the losing player's paddle top and lowest lines turn red (he starts "burning"), and so forth, progressing towards the center of the paddle, till one paddle has completely turned red = game over. That should give an intuitive visual gauge of the game's progress and both players performance... Edited April 30, 2009 by r_type2600 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 30, 2009 Author Share Posted April 30, 2009 What about color coding the paddles this way:both start all green. With every passing ball the losing player's paddle top and lowest lines turn red (he starts "burning"), and so forth, progressing towards the center of the paddle, till one paddle has completely turned red = game over. That should give an intuitive visual gauge of the game's progress and both players performance... Good idea, but it will require some more bytes than just shortening the paddle. BTW: 15 bytes free now. Maybe even 17. Quote Link to comment Share on other sites More sharing options...
BigO Posted April 30, 2009 Share Posted April 30, 2009 It's all in RAM, are you putting in self-altering code or something like that to gain those free bytes? Quote Link to comment Share on other sites More sharing options...
potatohead Posted April 30, 2009 Share Posted April 30, 2009 When you don't have any paddle left, you lose, the ball passes by one more time, then the game stops.I was thinking the other way around. As you score higher, your paddle gets smaller to give the opponent a fighting chance. While fighting for the winning point, your paddle would be like the size of the ball. I guess that the winner's paddle disappearing completely would be the "Game Over" indication, leaving the loser standing on the court with the remnants of their paddle to remind them of how soundly they'd been trounced or show how narrowly they'd lost. Yeah, that works too! Might be better actually! There is a better game element in your scheme, IMHO. No easy wins. With each point, comes some additional focus required to close the deal! I like it! Quote Link to comment Share on other sites More sharing options...
iwan-iwanowitsch-goratschin Posted May 1, 2009 Share Posted May 1, 2009 Make some carts for the Retrobörse, Thomas...... I'll put it on my Kroko Cart. Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted May 1, 2009 Share Posted May 1, 2009 This thread led me to 'discover' something interesting: lda $85 ;lda is at $84, $85 is at $85 Loads #$85 to accumulator, but wastes a cycle although, I am sure it is rare to find a situation where this is useful. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 1, 2009 Author Share Posted May 1, 2009 It's all in RAM, are you putting in self-altering code or something like that to gain those free bytes? I haven't used selfmodifying code here yet. But I do something like this: .variable = . + 1 lda #INITIAL_VALUE Which saves one byte of RAM. The space gains are coming from optimizing the existing code for space, e.g. reusing register contents, reducing overhead space (no timer, just simple WSYNCS). And I gained quite some space by optimizing the paddle enabling/disabling code now (which is looping over both players to save even more space): Old, 32 bytes: yPosLst .byte 50, 50 yPos0 = yPosLst yPos1 = yPosLst+1 yPosNewLst ds 2 yPosNew0 = yPosNewLst yPosNew1 = yPosNewLst+1 lda yPosNew0 sta yPos0 lda yPosNew1 sta yPos1 ... ; draw player: tya ; 2 sbc yPosLst-1,x ; 4 C = 1 adc #PADDLE_H ; 3 lda #0 ; 2 bcc .skipDrawPaddle ; 2/3 lda #$c0 ; 2 .skipDrawPaddle: sec sta GRP0-1,x ; 4 = 18/19 ; check paddle: lda INPT0-1,x ; 4 bmi .skipPos ; 2/3 sty yPosNewLst-1,x ; 4 New, 20 bytes: yPosLst ds 2 yPos0 = yPosLst yPos1 = yPosLst+1 sty yPosLst ; 3 y = -1, avoids disabling paddles at top sty yPosLst+1 ; 3 ... ; check paddles: lda INPT0,x ; 4 paddle pos reached? bpl .skipPos ; 2/3 no, skip inc yPosLst,x ; 6 .skipPos: ; = 7/12 ; draw paddles: lda #PADDLE_H ; 2 cmp yPosLst,x ; 4 txa ; 2 x = 0/1 ror ; 2 a = $00/$80 sta GRP0,x ; 4 = 14 12 bytes gained! Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 1, 2009 Author Share Posted May 1, 2009 Another update, now with (4) variable angles. 7 bytes free... RAM_Pong__2_player_v0.3_.bin RAM_Pong_11.zip Quote Link to comment Share on other sites More sharing options...
doctorclu Posted May 2, 2009 Share Posted May 2, 2009 Another update, now with (4) variable angles. 7 bytes free... To play a game in ram... just too cool! Quote Link to comment Share on other sites More sharing options...
Mord Posted May 2, 2009 Share Posted May 2, 2009 For the record, I was only kidding when I said this. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2009 Author Share Posted May 2, 2009 For the record, I was only kidding when I said this. Really? Knowing that before, would have saved me a lot of time. BTW: I got an idea for displaying the score, which doesn't require much space: I could move the center line a few pixels left or right, if a player misses the ball. Good idea? Quote Link to comment Share on other sites More sharing options...
LS_Dracon Posted May 2, 2009 Share Posted May 2, 2009 And how about changes the player color? Starting in white, then every ball loses turn a bit dark, when the player turn in darkest color, this case black, the game is over. BallOut Lda COLUP0,x beq GameOver sbc #2 sta COLUP0,x If COLUPX is 0, game over. Assuming it's possible to read the colors registers... Quote Link to comment Share on other sites More sharing options...
Devin Posted May 2, 2009 Share Posted May 2, 2009 This is simply amazing work you have done. Getting any game to work in 128 bytes is challenging beyond description - and then to make that game fun... I'm shocked. Anyway, I thought of something you can do after a game is over and you have a winner. Since the cartridge can be removed, why not let the winner put a cartridge in the slot. Then, your game would boot the cartridge. This could be the Pong Chooser - and could be used to decide which game two warring kids play: Kid 1: I want to play Star Fire. Kid 2: No, i want to play Thrust! Kid 1: No, no. Star Fire! Kid 2: I want Thrust! Kid 1: Star Fire! Kid 2: Thrust! Kid 1: Star Fire! Kid 2: Thrust! Kid 1: Let's Pong over it! Kid 2: Ya, you are going down! Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2009 Author Share Posted May 2, 2009 If COLUPX is 0, game over. Assuming it's possible to read the colors registers... Unfortunately it is not. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2009 Author Share Posted May 2, 2009 This is simply amazing work you have done. Getting any game to work in 128 bytes is challenging beyond description - and then to make that game fun... I'm shocked. Thanks for the compliment. Actually I am surprised myself how far I got. Anyway, I thought of something you can do after a game is over and you have a winner... LOL, I like that idea. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 3, 2009 Author Share Posted May 3, 2009 Another update. Now the game "counts" the score by moving the net. The game is over, when the net reaches one border. Also the net is dotted now, which did cost me the last two free bytes. Unless someone reports bugs I consider the RAM kernel part done. Working on a title screen now... RAM_Pong__2_player_v0.4_.bin Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.