DaveM

I think you showed the wrong game today. You played Swordquest Fireworld instead of Swordquest Earthworld. They both suck. ?

Back to working on the game after another few months away from it. There is progress, but I'm not going to share any files, as things are far too gitchy at the moment. I do, however, have a screenshot: This is the first screenshot of actual gameplay. That said, you really can't play the game as such, the game just starts up, you can move the players, and that's about it. I haven't yet figured out a way to display the blocks in the space between where the block is in the screenshot and where the players are. I have a few ideas, but haven't yet completely worked it out. I also need to figure out how to display the blocks in the players' area, as well as add jumping ability for the players. I also want to get rid of that blank space between the bird's claws and the block, but I may leave that until much later. So, still a long way to go, and not much time to work on it. I'm giving up on trying to finish the game by October, that just isn't going to happen. But I'll keep plugging away at it, and get this thing done eventually.

I should've posted this a week ago right after the broadcast, but things happen, and at least I'm finally getting around to this... Thanks so much to James and Tanya for having me on the show! I had a lot fun, and it was great to finally talk to you live. Naturally, about a minute after I left, I realized that I did forget to mention something about the game, and that is the Easter Eggs. I've mentioned it in this thread, but I'll go ahead and repeat it anyway. The cartridge version contains 2 Easter Eggs that do not appear in the downloadable ROM. I mention how to find one of these Easter Eggs earlier in this thread, but the other one you'll have to find yourself. It's a bit tricky. If anyone finds either of the Easter Eggs, I'd love to know about it! Post a pic of it if you can here in this thread, and how you think you got it, and I'll confirm and explain exactly how they can be found. And if you were kind enough to purchase a copy of the game, or if you just downloaded it and enjoy it, please consider leaving a review of the game in the AA Store. Thanks!

I've got tickets for Saturday. Looking forward to it!

Not much of an update, other than to say I'm finally back to working on the game after 2.5 months away. After taking that much time off, it took me numerous attempts to get back into things, and trying to figure out my previous logic was a lot tougher than I anticipated. So with that in mind, this update is kinda small. I fixed a few logic bugs, slightly changed the colors on the bird, and you can now push the button on "Start!" to start the game. This will reset the players, the bird will lower into view, and you'll be able to move the players around. Regardless of the game type selected, it will assume a two-player game. The title logo will reappear in place of the menu, but this will change with the next update. Still no real game yet, but at least I'm back to making progress. KickIce_20220402.bin KickIce_20220402.a

Menu Completed. Once the title logo comes into view, you can press the button to go to the menu. Players can be 1 player, 2 player Co-Op, or 2 player vs. The scoreboard will adjust based on the game type. For 1 player, the blue portion will not be visible. In Co-Op play, the two players share a common score, but have separate life counts and power-ups, so the score will disappear from the blue bar, while the rest of the stuff remains visible. 2 player vs. shows the scoreboard just as you've seen so far. Difficulty can be Easy, Normal, or Hard. Pretty self-explanatory there. No code yet for pushing the button on "Start!", so you can't go past the menu. At this point, I have to set the game aside for just a little bit while I take care of a few things. I need to build a website for our wedding and get our invites organized and sent out. Once I get that taken care of, then I'll get back to the game and start working on the actual "game" part of it. KickIce_20220125.a KickIce_20220125.bin

Yes, the bird will fly in from the top of the screen to his position, then just move right and left much like the mad bomber in Kaboom. When the level's over, he'll fly off the top of the screen. The bird can't get to the players, and vice-versa. If a block lands on another block, it'll slide off to one side, then drop to the platform. Players can jump, but if they land on a block, they'll slide off. If a player lands on another player, I think I'll have them bounce back up a bit. That's about the solution I think I've come up with as well. The lowest section with the players and the blocks worries me a bit, as there could be blocks at various heights, not only sitting on the platform, but still falling into place, and also falling off the sides into the water. So that may get a bit sticky. Yes, after thinking things through, that's what I've ended up with as well. I'll also put something in there so the blocks don't overlap between two PF objects as they fall, just to keep things simple. Not quite sure I understand this point, so I'll have to do a bit of research. I'm wrapping up work on the menu now, then I'll start from the top of the screen and work down. I'm abandoning the idea of different-shaped blocks for power-ups. Just seems like that would be complicating things a bit too much. I think I'll have different colored blocks as they fall for the power-ups, and when they get to the bottom section, they'll transition to white and lose their power-up abilities.

Very honored to announce that Mr. Yo-Yo was nominated for TWO Atari Homebrew Awards! Be sure to head over to the Awards section of the forum, download the binaries for the nominees, and vote for your favorites! Big thanks to ZeroPage Homebrew for all their work putting on the Awards this year! I enjoyed watching the nomination show earlier today. I was able to watch it live at the start, but unfortunately, something came up and I had to jump off before they got to play Mr. Yo-Yo. I watched the rest of the show later in the evening. It's really too bad I had to miss the segment with Mr. Yo-Yo, as James and Darcy were having more trouble than usual with the game. If I were in the live chat, I could've told them they had the difficulty switch set to 'A', which is why the enemies were moving so fast! Oh well. It's a true honor to be nominated, so a big thanks to everyone in the nomination committee who voted for the game, a big thanks to everyone that helped along the way with the development of the game, and of course, a big thanks to the AA community in general for the support and encouragement you've shown from the beginning!

Yes. I want them to be big Pengo-sized blocks. They have to be wider than the players, which are 8 pixels, so the next size up is 12 pixels. Here's a mock-up screenshot on how it would look: Understood. Here's the plan... The ice blocks have only two areas where they could move horizontally - when the bird is holding them, or on the platform. In the scanlines which draw the blocks the bird would be holding, the blocks would actually be drawn by the Ball and Missile1 objects. That eliminates the choppiness there. I would then also use those scanlines to reposition the two player objects. So the highest up the screen the players would be able to reach is the bottom of the block that the bird is holding. As the blocks drop, using the playfield is no problem, as there will be no horizontal movement. If the player comes in contact with a falling block, it's goodbye player. When the blocks are on the platform, of course, the PF will still be used, however, the blocks would slide VERY quickly horizontally. 4 pixels/frame was the speed I was thinking of using, making the Ball object unnecessary, but I'll have to see how it plays when I get there. If the game proves too difficult at that speed and I need to slow them down, then I'll start thinking about adding the Ball object in there. The problem is, there will be times when multiple blocks are sliding around there. One player could kick a block one direction, and the other could kick another the other direction, and there's only one Ball to use to smooth all that out. I guess I'll cross that bridge when I come to it. It all depends on how the thing plays and whatever tweaks I need to make to it.

Good info everyone! Thanks! I'm hoping to have some progress later this week.

It's not obvious to a newbie... or an idiot. I'm sure I'm in at least one of those two categories. Good info. I was actually a bit confused on all that. I don't like using the extra cycle to access that RAM, but if I need it, I was thinking I could store the ice block data in the zero page RAM, and then use the extra RAM to store everything else. I've got a few ideas, so over the next few weeks, I'll try them out and see if anything works. Thanks!

Seems like a great idea. Until some jerk says something like, "Hey Dave, got any better games to play?" Then it becomes a "my foot kicking his ass" themed wedding! ?

Used F8 bankswitching to expand to 8k. No other changes yet, just needed to give myself more room as the original 4k was almost full. Been thinking a lot about the previous couple posts and I think there is a path forward for the game. Haven't quite figured it all out yet, but my next step will be to add the menu, then start on the gameplay. I think it can be done without extra RAM, but any additional suggestions and/or assistance would be greatly appreciated. Now to the TMI portion of this post... So my goal with this game is to be done (or at least almost done and very playable) by October 8. Why Oct 8? That's when I'm getting married! Why would that have anything to do with this game? Because the reception hall we have rented has a couple TV's hanging on the wall. The manager there suggested we just have them run a slide show of pics of ourselves, but we just don't take a lot of pictures. So on the drive back from our appointment there a few months back, I suggested that we get a couple Atari 2600s, hook them up to the TVs, and have Mr. Yo-Yo playing on one TV, and Kick Ice playing on the other TV, all ready for any of our guests to go over and play anytime during the reception. As proof that my fiancee is the coolest, she actually said yes to that idea. Now, I have double- and triple-checked with her on that idea since, and she's still ok with it, albeit with much less enthusiasm than she originally showed, but with less than 300 days now until the ceremony, I think I'll hold her to it. But of course, the game is far from finished (it's barely even started), and my time to work on it is rather limited: I have a wedding to plan, which is taking up more time as we get closer. Sadly, my fiancee's cancer has come back, so I've been spending time with her running her back and forth to doctors and hospitals. Now the good news there is that they caught the recurrence early, and her new chemo drugs have slowed the spread down to very manageable levels in some areas, and have stopped the spread in others (and she gets to keep her hair ). The doctor is very encouraged by the progress made so far and thinks we'll be successful in defeating it in the long run. I'm also manager of a vintage baseball team, which is attempting to restart after having the last couple seasons cancelled due to COVID. The entire league shut down for 2 seasons, which caused most of the teams to fold. We had 9 teams, only 3 were interested in continuing, but after a lot of work by us three teams, we managed to revive a 4th team for a game this Saturday. Trying to bring that whole thing back up to speed when most have given up and moved on is a lot of work. Not to mention getting my guys in game shape, which is very easy to lose and hard to get back at our age. Our butts have been kicked pretty bad so far this season. Then of course, there's work. Anyway, the time I have to work on Kick Ice is quite limited, but I'm still shooting for October. KickIce_20220112.a KickIce_20220112.bin

Ouch. I did not know that. The timing on my kernel is pretty dang tight as it is, so using extra RAM probably won't work, at least how it's currently set up. When I was planning out this game, I had a very similar idea, but I couldn't quite wrap my head around it, and thought it would just be simpler to take advantage of some extra RAM and go with that. So this may be the solution I'm looking for! Yes, at least while they're falling (with the understanding that the speed will increase from level to level). When a block hits the platform, it'll stop there, and the players could then kick the block horizontally. The block will then slide, and when it clears the edge of the platform, it will drop into the water and sink off screen. At least, that's the plan. The players will be able to jump to get out of the way of a block kicked towards them, but they won't be able to kick a block while they're in the air. Yes. In playing around with it, it looks like a block size of 3 PF blocks wide by 10 double-scanlines tall will be ideal. I'd like to do power-ups as well. The plan is for a plain square block to be just a block, while the power-ups would take various shapes, while still fitting within the 3 PF x 10 square. For example, a block shaped like an "S" would give the player spiky shoes so they wouldn't slide around on the ice. Now, if different-shaped blocks causes too much of a headache, I have other ideas on how to trigger power-ups. Let's say 2, with one of them being on the platform, probably while sliding horizontally. Too keep block-on-block collisions simple, the plan is to not drop one block while another is directly below it. However, there wouldn't be anything preventing a player from kicking a block so that it slides below the path of another block.

OK, how do I go about using each of these? I'm only familiar with what I used for Mr. Yo-Yo, which was the F8 method, and I'm having trouble tracking down a "How-To" on these other methods. And this is sort of my other question. Is there a better way to do this? Maybe I don't need all that RAM after all, and there may be a better way to store the data I need?

With the new kernel written, I now need some advice on how to continue. In the game, the bird will drop ice blocks onto the players, who must dodge them, then kick them off the platform. I'll be using the playfield to render the ice blocks. It's a 2-line kernel, and there will be 47 double-lines between the bird and the water. I'm using 5 of the 6 available playfield objects (I had to sacrifice the left PF0 in order to get the kernel timing to work), so that means I'll need 5 * 47 = 235 bytes of RAM to store the PF values for the ice block locations. In the files I've attached above, I have these stored in ROM, but that's just temporary. For what it's worth, the blocks will be 3 playfield blocks wide, by 10 double scanlines tall. The platform is 26 pf blocks wide, so that should give me plenty of room. The plan is once too many ice blocks (3-5, I'll have to play with it once the game is coded) accumulate on the platform, it will cause the platform to sink and the player(s) will lose a life. So what would be the best way of handling the ice blocks and all the RAM it looks like I'll need? I've done some very basic research on some bank switching schemes, and it looks like the E7 scheme may be the way to go. Of course, I know nothing about how to do any of this, so I'm not sure where to start. Is there a better way of handling all the possible playfield data I'll need? Maybe there's a solution I haven't thought of or don't know about. I keep thinking of Pengo and all the blocks on the screen there, so I'm guessing there's a way of doing all this. Any advice or suggestions would be greatly appreciated! Thanks!

Thanks Karl! I'm not sure what the problem is you're seeing when the players run off the screen. It seems to be working as planned for me. But there's always tweaking to be done, especially after I start working on the gameplay, so edge detection is likely to change anyway. KickIce_20220102.bin KickIce_20220102.a

Need a bit of assistance here. I wrote a new kernel for the play arena area (currently the area between the logo and the water), and I thought I had the new kernel all figured out and working perfectly. Then I opened up the ROM in Stella, and the players' movements are all jittery. It's working just fine in the 8bit workshop/Javatari editor. I can't figure out why there's a difference. Would someone mind taking a look to see where the problem is? Thanks in advance! KickIce_20220101.a KickIce_20220101.bin KickIce_20210101.zip

So I'm having two major problems when working on this game. Here's the first - The main play area (below the bird and above the scoreboard) will need a new kernel. I need the two player objects, multi-colored, as well as an asymmetrical playfield (i.e., 6 PF segments). I don't need the ball or missile objects. I'm just getting started on attempting this, but not having any luck so far. I've been trying a 2 line kernel. The timing is very close, but just not working for me. Does anyone know of an existing kernel template out there that I can use for this? As for the other problem, I'll cross that bridge a bit later. EDIT: I went back to working on this late last night. I'm still over, but now, I'm over by just 1 lousy cycle on lines when both players are being drawn. However, if I sacrifice my lovely vertical black bar of sta HMOVEs on the left side, then the timing works out. Of course, I don't want to sacrifice the HMOVEs, but I may have to. Anyway, it'll be a few days before I can get back to it to see if that works. I'll share my code when I do, and maybe there will be a way I can get rid of that one extra cycle and keep the HMOVEs.

Short video of the opening title screen animation. Still a bit of tweaking to be done, and a kernel to be rewritten, but the basic stuff is there.

It's been a while, so I wanted to provide an update. Here's the first little sampling of partial playability. Basically, you can move the guys back and forth and have them bump each other around, and that's it so far. The button makes the player kick, but that really doesn't do anything at the moment. They automatically kick each other when they come into contact (I still need to work on the kick animation holding for more than one frame when that happens). The plan is for the kick action to be automatic, and the button will be used to jump (not implemented yet). The player could also switch the difficulty switch to "A", which would then have the button used to kick and the player would push the joystick up to jump. The player that's moving faster when they make contact will "win the contest" and kick the other player. The longer you hold the joystick in one direction, the faster you'll go. If you're moving slowly and reach the end of the ice floe, you'll stick there and not fall off. But if you keep pushing, or if you reach the edge and you're moving fast, you'll fall off. Eventually, I'll add a splash graphic effect when they fall in, but for now, they just fall off, and the only way to get them back is to push reset. No real gameplay yet. You can't trigger the seal to come on the screen, the bird does nothing other than swoop in when you start up, no scoring, the title screen logo stays there the whole time, and of course, no falling ice blocks, so no gameplay yet. Just a sample of how the players will slide around and kick each other. KickIce_20211214.bin

Very slowly making progress, mostly due to lack of time, but some progress is being made! Here's a look at the game's other enemy, "Slammy the Seal!" In one player games (or if one player gets knocked off in a two-player game), Slammy will jump on board from time to time to try to knock you off. Most of the past few weeks though, I've been working on player movement. Since the game is played on an ice floe, I wanted the players to slide around a bit as if they were running on ice. It took quite a while to figure out a formula that worked how I wanted it to. I'll probably tweak it a bit before I release a playable ROM, but with what I have right now, the players will start out slow, gain some speed, then skid as you try to come to a halt or turn around. I've also completed the running animation for the player characters. With the animation complete, I'm going to try to put together a little title screen animation sequence as my next step. After that, it's the menu screen, then finally starting on the actual gameplay.

Better. I fixed the bad temporary kernel, and replaced it with a better temporary kernel. Screenshot is no longer slightly mocked up, as I got rid of the graphics garbage that was showing up previously. I added the blue underneath the white platform so it looked more like an ice floe floating on water. I'm playing around with having that blue band cycle through various shades of blue, but I haven't come up with an effect that I like quite yet. I also slightly changed the player sprites and colors. In the previous screenshot, I thought the red guy looked too much like a Devo band member wearing diapers. ? Eventually, the players will rest flush against the ice floe block, as it'll all be part of the same kernel. But for now, I'm still playing around with stuff, so I've kept it separate.

Progress has been much, much slower than I had hoped. I just haven't had the time to work on the game, and honestly, it's getting quite frustrating. But, there's still just a little progress. Here's a slightly mocked up screenshot: I'm starting to get concerned though that what I'm trying to do isn't actually possible. So during the game, between the bird and the scoreboard, I'd like to build a kernel that allows for two multi-colored player objects, plus an asynchronous playfield. I'm going to use the playfield to draw blocks of ice (just large white squares, not the pseudo-3D ice block in the logo above), which will be dropped by the bird onto the players below. The players will kick the blocks off the platform they're on. Anyway, 2 multi-color player objects plus an asynchronous playfield. Is it possible? I was also thinking of using the ball object to create a blizzard effect on some levels, but that may be too much.

Sure! Anything helps!