tschak909 Posted September 21, 2016 Author Share Posted September 21, 2016 Some improvements in the firing control have been checked in... It's no longer possible to just drop a ball...because...well...that would be silly, wouldn't it? Instead, if the fire button is pressed by itself, with no direction, the ball will go in the last joystick direction pressed. Also, firing has been improved by adding an additional check for carry if decay is >=0. I want to add the ability to pick up an opponent's dead ball, before issuing another play test. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 21, 2016 Author Share Posted September 21, 2016 Status update: Ok, so, doing the ability to pick up two balls, is going to be a bit of a challenge.. I'm already on my first rewrite of the routine For normal ball pickup, I am using the collision latches in their natural order to determine if a ball is being picked up, and to reset the ball to the player (RESMP0), this works beautifully. For picking up the opposing ball, doing this when that ball is still and not moving is also working, in this case, it RESMP0's to the opposing player (to complete the illusion, even though the opposing player won't really "have it" I also, of course, have the BIHx variables which count the # of balls in hand (no more than 2), which gets incremented... But to this, I've also added an opposing ball register for each player, which gets bit 7 set if player has the other player's ball.. This is where logic gets a little funky.. I basically use the pattern: STX TEMP TXA CLC ADC #$01 AND #$01 TAX STX TEMP1 So that I have the current player in the collision routine in TEMP, and the opposing player in TEMP1. The plan is then to load the appropriate var into X in the collision routine when OPBALLx's bit 7 is set, and use it to e.g. set the appropriate player X and Y positions, set the appropriate direction based on the joystick vector, etc... As you can see, this involves a LOT of juggling and it suddenly turns my collision routines into a big bowl of fusili... but it is doable... I just have to carefully map out the swapping points and make sure they're taken care of appropriately.... ...but the end result is that if the opposing player leaves their ball vulnerable, you can pick it up, and throw it for twice the pummeling power! ...This also means, that the collision routines will have to become somewhat symmetrical.... but this is perhaps a good thing! because maybe when it's all said and done, this means I can consolidate the same routine across multiple collision latches and save 50-60 bytes. But I won't know until all the cases are taken care of...optimize last! This is really where the rubber meets the road, it seems... lots of playing and tweaking..but even at this moment with the few small tweaks in the firing routine, the gameplay feels so much better! I like being able to instinctively fire if I've already picked a direction to run in. Also, I've started the process of tagging deliberate releases that I make, starting with playtest0, on github. They will be posted on the first thread post, so that newcomers can quickly get up to speed. I am also preparing a little website for this thing. -Thom 1 Quote Link to comment Share on other sites More sharing options...
adam242 Posted September 22, 2016 Share Posted September 22, 2016 Finally had a chance to try this out with my girlfriend tonight.. we both love simple, old-school head-to-head games like this, so it won us over easily. It's a great start and we're looking forward to seeing it refined further. Two suggestions: Would it be possible to eliminate the 'bouncing' of the players against the obstacles by doing some sort of valid new position check before moving the players? She was annoyed by the jittering a little. Also, perhaps add an option to turn off the computer ball, or at least make it deduct ONE point and reflect direction? I assume you plan on adding a 'first person to reach x points wins' feature. Gotta have a winner! Very nice so far! 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 22, 2016 Author Share Posted September 22, 2016 Thanks adam242! ... The bouncing of the players has to do with the fact that I am moving the players by a certain amount each frame, and have to back it out if a collision occurs (Due to the way the collision latches work, I can only register a collision AFTER the fact... otherwise I would have to keep a bitmap of the playfield in memory, and I'd rather not do that, if I can avoid it, as it takes up a lot of RAM and CPU cycles to reconcile against it). I am not sure of what I can do... if I think of something, will try it. As for the computer ball, YES there will be game variations which turn it off. As for the collision detection, once it subtracts, it's supposed to reflect (this is what the code specifies)... As for the winner portion, Dodgeball will follow the launch titles (e.g. Combat, Air-Sea Battle, Star Ship, etc.) which use a timer of 2 minutes and 16 seconds before the end of game, with the score flashing for 16 seconds before game ending, and color cycling. This will be implemented once I get the main game mechanics ironed out. Trust me, I have the mechanics completely thought out (see the very first post), but it will take me time to implement and debug everything. If you notice, even the B/W switch is implemented... the Difficulty switches will also be used to change the size of the player, to create a handicap. -Thom (the goal is to completely finish; polish the game, and make complete manual and box art, with a completely published cartridge hopefully via AtariAge, and for those who want it, the source code for all parts of the project, game, and artwork, is and will be available via github for others to learn and study.) 1 Quote Link to comment Share on other sites More sharing options...
adam242 Posted September 22, 2016 Share Posted September 22, 2016 (edited) Thanks adam242! ... The bouncing of the players has to do with the fact that I am moving the players by a certain amount each frame, and have to back it out if a collision occurs (Due to the way the collision latches work, I can only register a collision AFTER the fact... otherwise I would have to keep a bitmap of the playfield in memory, and I'd rather not do that, if I can avoid it, as it takes up a lot of RAM and CPU cycles to reconcile against it). I am not sure of what I can do... if I think of something, will try it. I see.. I've been following the thread a bit and I understand the 2600 is a fair b*tch to program compared to the 8-bit computers I'm more familiar with.This was a minor quibble anyway. As for the computer ball, YES there will be game variations which turn it off. As for the collision detection, once it subtracts, it's supposed to reflect (this is what the code specifies)... I like the extra challenge of the computer ball, but it's always nice to have options. (I think 2600 Asteroids offers 66 different 'games'!) I could have sworn that at least once the computer ball passed right through my player and deducted 8-10 points, but I was very close to an obstacle and it may have just bounced several times in a confined space and I perceived it wrong. As for the winner portion, Dodgeball will follow the launch titles (e.g. Combat, Air-Sea Battle, Star Ship, etc.) which use a timer of 2 minutes and 16 seconds before the end of game, with the score flashing for 16 seconds before game ending, and color cycling. Nice, very old-school, We play a lot of Outlaw and Freeway so that's intuitive for us. I've always preferred the 'flashing score countdown' over playing to a set number of points. Adds a little more dramatic tension to the end of the game. (the goal is to completely finish; polish the game, and make complete manual and box art, with a completely published cartridge hopefully via AtariAge, and for those who want it, the source code for all parts of the project, game, and artwork, is and will be available via github for others to learn and study.) Looking forward to it. Throw an early text-style label (or find someone who can reproduce the art style of the early picture labels) and you've got a sale. And I'll enjoy studying the source code. Edited September 22, 2016 by adam242 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 22, 2016 Author Share Posted September 22, 2016 I have typography experience, and yeah, I'm using the Dessau font (and its close cousins that Atari mixed with it) to create the title. I would like to find an illustrator who could make something similar to the original Atari covers... A quick pass (well, quick, it took 2 and a half hours of matching fonts), below for the cartridge: -Thom 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 23, 2016 Share Posted September 23, 2016 You should also check out the 2600 label maker: 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 23, 2016 Author Share Posted September 23, 2016 I used it to build the frame and get the label dimensions, but the choices that it makes for the fonts for text labels are completely wrong, so I did all of that and the text kerning, myself, as one of my backgrounds is in typography. -Thom 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 24, 2016 Author Share Posted September 24, 2016 Rewriting the opposing ball collision code, for the fourth time. It never fails, VCS collision detection code will _ALWAYS_ become a bowl of pasta. Period. No matter what. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 24, 2016 Author Share Posted September 24, 2016 And I just realized that my player swap, which was using ADC and AND #$01, could be replaced with a single EOR #$01. derp. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 25, 2016 Author Share Posted September 25, 2016 Still working on other ball pickup. I was able to drastically simplify choosing which ball to throw depending on whether a player has the opponent's ball, by utilizing the X index to handle reads, and Y to handle the write index...normally in this routine, the X and Y indexes are the same, but when holding an opponent's ball, Y points to the other missile for the write (thereby making the opponent's missile appear to be thrown from the player. There's still quite a bit of code to work through (making sure that score doesn't increment accidentally when thrown by opponent player, etc...etc...etc..) not to mention, I still need to realign some code after I get all this working, as occasionally I will hit a page boundary in the wrong spot, and my players and missiles will mysteriously go askew. ahhh, fun times.... I need to pass out...but I'll get this feature done this weekend, I can feel it. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 26, 2016 Author Share Posted September 26, 2016 Opponent ball catch... Still working on it... now on my sixth attempt of the joystick and collision routines. I am seriously suspecting that I may have to completely rewrite my collision routines...god, I don't want to. but then again..it's only 2K of code for the whole game... This is the last major play feature that must be in the game... the other major bit will be handling motion acceleration/decay, but that can wait a bit until after we all work through the first round of real playtesting... -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 27, 2016 Author Share Posted September 27, 2016 Ok fellas, playtest1 is here: https://github.com/tschak909/dodgeball/releases/tag/playtest1 Two game variations, which right now just select color palette Attract mode with proper color cycling Game timer implemented, 2 minutes 16 seconds, aka old-school Combat/Star Ship/Air Sea Battle mode. Much improved firing controls. Remembers last firing direction now too. Initial pass of sound. more to come in the next playtest release! But please, download, test, give feedback! -Thom dodgeball.bin dodgeball.asm 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 27, 2016 Author Share Posted September 27, 2016 Yes, there is a bug where the game state does not completely reset, most noticeable, scores.. I will do another build later today, after sleep. ugh. whoops. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 27, 2016 Author Share Posted September 27, 2016 Ok, corrected build now posted here: https://github.com/tschak909/dodgeball/releases/tag/playtest1a -Thom dodgeball.bin dodgeball.asm 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2016 Author Share Posted September 28, 2016 I am now attempting to implement the difficulty switches, which will for each switch * Change size of player * Change throwing distance of player I've implemented the state setting based on difficulty switch, and now am trying to flip the registers in my main kernel, so that I can load the player graphics (ind),Y, as this part currently uses X. This is turning out to be a pain in the butt. -Thom 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted September 28, 2016 Share Posted September 28, 2016 I like your game idea. It's original. Creating a game had the Atari 2600 just continued on as a pong/tank Console, or as a game that was planned... I think it is too early to report bugs, but people will. Don't get overwhelmed or let bad comments take you away from learning and moving the game code forward. So here's my bug I was just to the left of player 2 or maybe overlapping. I threw and the dodge ball and it got stuck in player 2 and spun in a tight circle while my score kept going up to 99, and rolling to 0, over and over. Even made a capture, because it was funny, then decided not to post the capture because it might appear negative. It is nice of you to share so others can play now and to watch the game progress! 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2016 Author Share Posted September 28, 2016 Thanks, it's not entirely altruistic, I don't have anyone here to play test with, so I need everyone's help to playtest. I want this game to be as best as it can be. As for the bug you found, Can you reproduce it consistently? I can understand why it's happening, I think ultimately it will require the players to be scooted from their original positions. Was the firing mechanism ok? Does it make sense? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2016 Author Share Posted September 28, 2016 By the way, if anyone wantss to make playfields, please feel free to submit a playfield using this editor: http://www.tolberts.net/pf.html cut and paste the code in this thread, and I will try them out. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2016 Author Share Posted September 28, 2016 Ok, I think this will be playfield #1, what do you guys think? -Thom 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 30, 2016 Author Share Posted September 30, 2016 Status update So basically, I am trying to get player catch opponent ball implemented, at the moment. This is proving to be a bigger pain in the butt, than it first seemed, and it needs to do the following * Player 0 picks up P0 ball, DONE * Player 0 picks up P1 ball, DONE * Player 0 fires, which causes P1 ball to fire, DONE * Player 0 fires again, which causes P0 to fire (not firing) Right now, the BIH counter is somehow getting set to 0, from 2, even though, when I trace and trap, I only see it getting set to 1, so I have some sort of awesome race condition happening (I don't see how, there are no fucking interrupts!)... argh. I wanted to get at least THIS implemented, before the next playtest, and then I can pretty much call the game core implemented (with only debugging and optimizing left)... If I manage to get computer ball catching done, that would be a nice bonus...but I do want to get this to the point where all I have to do is add some small features (player scoot, ice floors, etc.), and then I can actually start tuning the game to make it razor sharp and shiny. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 1, 2016 Author Share Posted October 1, 2016 Well guys, it's here! another Playtest release: Playtest2! Github release page is here: https://github.com/tschak909/dodgeball/releases/tag/playtest2 * Implement the ability to catch other player's ball! (big strategy plus!) * Tweak ball reset positions a bit more * Add 4 distinct playfields, to start. Will expand to 4K cart for more. Still so much to do, but I wanted to roll out another release for you guys. Known bugs: * Kernel glitches due to now using indirect fetches for playfield. Need to fix. * after reset, Sometimes balls can either get stuck, or can start in such a way as to not stop bouncing, just reset again. * the ability for two balls to collide and cause havoc is still possible, this one will be a hard one to fix, it seems. As always, please test and give feedback! -Thom dodgeball-playtest2.bin dodgeball.asm 1 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted October 1, 2016 Share Posted October 1, 2016 Cool game. I think it's a great fit for the VCS. If you put P0 on top of P1 and throw the ball at closest wall it will unlock super score mode. Once the score exceeds 99 it crashes. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 2, 2016 Author Share Posted October 2, 2016 Yup, I've noted it in the github issues page, if anyone notices anything, you can also put it there, or mention it here on this thread: https://github.com/tschak909/dodgeball/issues In other news, I've decided, at least for now, to increase the ROM address space to 4K, as I'm finally hitting the edge of my available ROM space, and I still have actual functionality to put in. If I get enough playfield data, I may consider keeping it at 4K, if not, I'll try my damndest to squeeze it down to 2K. Now the serious grind begins, in earnest... squeezing in the last bits of functionality, while also debugging everything. I wish more people would try out and comment, I really need the input. -Thom Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 3, 2016 Share Posted October 3, 2016 Microsoft Xbox gets Kickball, er it's Soccer, or Fútbol for 2017. Atari 2600 gets Dodgeball! Boba Fett says, "In a world where 1977 never ended, Atari plans Dodgeball as its next release." 1 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.