bjbest60

Thanks for the reports, everyone. I've been out of town for the past week or so, so I wasn't able to get to this promptly. Right now, I've replaced 2.3 with 2.2 on the first post, so it should work on Harmony (albeit with the bug that you can collide with a shooter to move on to the next level). My guess is that the crashes are due to a bankswitching issue, so I'll do some archaeology and test thoroughly on Harmony before the next release. I'll post again when I think everything is set. Thanks!

Ack, uploaded the wrong file. The new one should now be correct. Amazing what changing one number in the code can do.

Ok! I've fixed the collision issue. Turns out I was spending some code trying to figure out which particular shooter was hit when ultimately the game did nothing with that information. So, now it simply sees if it's a collision with anything but water and, if so, routes you to the death sequence. Version 2.3 is uploaded at the top of the post. Any other comments or bugs? Going once, going twice ... Thanks again to everyone. The game is so much better due to all the comments I've gotten.

Good catch! I've been out of town for the past week, and still won't be back for a few days, but I'll dive in upon my return. I think I know what's causing moving to the next level rather than death when you touch a shooter. I think I just need to fine-tune the coordinate checking. That indeed looks unwinnable, but unfortunately there's nothing I can really do about it at this point. The game checks for sufficient horizontal spacing but not vertical spacing. I'm simply out of room in the code. I was happy to see that StanJr never encountered it. So, unfortunately, once in a very rare while this might occur. Yes, these will happen, also unfortunately. There's no efficient way to check that the paths to all six items are clear. I've gotten one or two of these myself. I wish they didn't happen, but for a bonus level, and since they're sufficiently rare, I'm willing to live with them. The struggle all along with this game has been trying to use these random elements while still making the game playable. Thanks for the reports! I'll update a new version that resolves the first issue when I can.

Thank you! I've really enjoyed working on the project. It's been gratifying to see people enjoying it.

I just uploaded a version 2.2 of the beta to the main page. I haven't had a chance to test it thoroughly, but I believe I've solved the issue of rarely getting a slot the width of one pfpixel that you can't fit through. If this suddenly seems buggy, just revert back to 2.1 and I'll delete 2.2. But since you're planning on playing it tonight, I figured you could try the new version and maybe everything will work the way it should. I haven't dealt with the victory screen issue, but that part should be easy.

So glad everything is working well. Yes, I agree completely. I've actually been meaning to take those points out, but now I'll actually do it. It's the same drawing routine, but there's no check to make sure the paths make sense, as there's no end goal to get to. Once in playtesting I got one of those double canyons which aren't connected (and sadly most things I wanted were in the other canyon). It's a bummer when that happens, but since it's a bonus round, I don't feel quite as worried about it--luck of the draw, I guess. I'm still struggling with this conceptually. In theory, a game is supposed to kick back to the title screen after twenty or so seconds once it's over, and I imagine some people might want to just relish in their victory. I can definitely lengthen the time, but I also think I want it to kick back at some point. I'm thinking about how Super Mario Bros. handles this, which is you get the winning message, credits, and then the title screen with the opportunity to play at the harder level. I definitely want people to be able to continue if they so choose, but I'm not sure I want to force that path. This is going to irk me just enough where I want to fix it, even though it's rare. The good news is I think I know where the issue lies (I don't have the code with me at the moment). I'll try to fix this, as it's a show-stopper in my opinion. Thanks, as always, for your thoughts! I'm excited to get this finalized soon!

After some thorough playtesting on real hardware, I've released beta version 2.1 as an addition to my original post. I've added the functionality where the player can choose to continue the game upon its completion, automatically moving to the harder difficulty (if not already there). I'm viewing this as a release candidate. I'm still interested in people's opinions and feedback, though at this point I don't really have room for any new features. There are still a few niggling bugs that have happened basically once, so it's really hard to trace them. But I'm curious if anyone has had a similar experience. StanJr, as noted above, got an instance of the game kicking back to the title screen instead of the "game over" screen in Difficulty A. Once I got a sound that hung until I completed the level. Once--out of easily a thousand times--I got trapped in a canyon with no path to the water. (There was a path, but it was too narrow for my poor cactus to fit.) I can't hunt any of these down in the code, so alas they might remain. But they seem pretty rare and ultimately I don't think they detract from the game in any appreciable way. So, try playing version 2.1, and let me know what you think! In the meantime, in anticipation of nearly completing the coding on this project, I crafted a 3-D version of Space Cactus, shown below.

After some very careful juggling, I think I've got this coded in now. I'll need to do some more playtesting of various options just to make sure all the switches are correctly flipped, but I believe it's all in the code. I've added the "press fire, pardner" to the winning screen (it appears after two seconds) to more clearly suggest how to keep playing. I'll release a new version once I think everything is set. Hmm ... I wish I knew what caused that. It sounds like it's calling a gosub without an appropriate bankswitch, but I can't replicate it. I followed the game-over code and it looks like everything's okay. I'll keep trying to hunt that down. Yes, it's intentional. I wanted him to be really fast but the problem with having him super-fast and also having a shooter is that the screen would roll--not enough time to run the move routine and the shoot routine. So I just cut out the shooter. Yes, that one point is entirely a reward for starting on Expert. I figured it'd make it easier for people to compare scores if they wished--Diff B scores always end in 0/5, Diff A scores end in 1/6. It's not impossible! That makes me so happy. I figured a +500000 bonus for completing it seemed fair. I'm so glad you like how it's turning out, and thanks again the detailed comments.

Thanks for the feedback! Glad to hear things feel more balanced, and that Difficulty A is maxed on challenge without necessarily being impossible. The score is a little variable in the sense that you get additional points for finishing a level faster. They're not much, but they do give a bit of distinction. The ending screen throws some heavy bonuses in. If you make it to the end, any lives you have remaining are +20000 each, and each needle is +10000. So there isn't one perfect score, though ultimately the scores get a bit same-y, especially if you don't reach the end. It probably wouldn't take too much to have the game start again, though. It seems like it would be flipping a few variables and changing an if/then or two. Space is extremely tight in the code, but I might be able to squeeze that in. Do you think the game should restart at the same difficulty level, or should it automatically migrate to Expert? Should you retain the same number of lives you finish with, or should it more or less be a reset of the game? I'm inclined to move to Expert but keep whatever you finish with, but I'm definitely open to suggestions. My other concern with continuing is the game flow. There's a clear ending screen, so I wonder how a player should continue on. Press the fire button? And either hitting the reset switch or letting the end screen lapse back to the title screen completely resets everything? I feel like both fire and reset completely reset everything in most other games, so I just would want the choices to be logical here. This could also be explained in the instructions. Thanks again for all of your comments! Let me know what you think a good continue sequence would be, and I can see what's possible.

I'm happy to release the second beta version of the game! It's available in my first post. I've really appreciated all of the feedback I've received; it's helped make the game much better. Most importantly, I've changed the kneeling shooter levels so they're more satisfying. I've ensured about four pfpixels of empty space on each side of them. I've found through testing that's juuuust enough room to get off a shot and get out of the way if you're precise and/or lucky. So no more getting dealt an immediately unwinnable canyon! I decreased the speed of the shot a bit, too, to make things more fair (your shots and the enemies' are now the same speed). I also increased the size of missile1 and darkened the shooter sprites a bit, so I think their bullets are a lot more visible. Another concern was that some of the shooter levels could be completed simply by going left. The game now places the water a minimum of two rows above or below the player. This makes it much, much more likely that you'll have to contend with at least one shooter along the way. I think this change has made the other levels more interesting, too. The canyons now draw much faster. This is purely aesthetic; I didn't save any code space. But it makes the player have to wait less in case a canyon needs to be redrawn. One consequence of moving the water two or more rows away from the player is that sometimes there simply aren't two rows either above or below. The game checks for this, and creates a new canyon if that's the case. Originally, the game redrew a canyon if it couldn't find a clear path to the water; in worst-case scenarios there are two separate canyons, one above the other. By forcing certain positions for the water, the game now redraws canyons more frequently. The instruction text that I wrote tries to explain that in terms of the story: "Every so often, you’ll enter a dead-end canyon that has no clear path between you and the water. If that happens, you’ll automatically back up and find a new canyon with a better trail." Admittedly, it's not a strong explanation, but I think for the canyons to provide the most fun / challenge, a couple per game will have to be redrawn. I wish I could avoid it, but unfortunately I think other solutions (such as putting the player at the beginning of the first path and the water at the end of the first path, thereby always guaranteeing the player can reach the water) make the game less fun. I feel like I'm getting pretty close to completion. But I'd love to hear more feedback. I'm still interested in the balance of the rules--speed, needles, score, lives, etc. I have <10 bytes free in each of my banks now, so adding new features is unlikely (though there's so much more I'd like to do!), but numbers that already exist can easily be changed. I'd be especially interested in hearing from anyone who tries the Expert difficulty--I worry it makes the game unwinnable (I haven't beaten it yet), but I'm not sure what I should change. Again, I'm really grateful for the comments so far. The game feels much more complete to me now.

Well, I just sat down to start looking at things, and to everyone who thought the game started out way too fast: you're right! I inadvertently left a line in the code that starts you at level 21 rather than level 1. I've uploaded the new version that properly starts on level 1 where things will hopefully be a lot less lethal.

Yes, it's DPC+, so it looks like that won't be a possibility. That's too bad, but I likely wouldn't have room for more code anyway. Hope to have a revised version up by Friday or Saturday.

The black and white levels are basically a bonus round. The most important thing is to collect the needle so you have a few more. Beyond that, with the whole game but especially those bonus levels, I was trying to go for the surreal feel of early video games. We kind of take Pac-Man for granted, but the whole premise--eat dots while being chased by ghosts and then sometimes eating fruit--is bizarre. I think Megamania is a great example of this (Shoot tires! Shoot hamburgers!). So I've got cats and shoes and whatnot. Interesting thought about the cactus being able to shoot out the wall. My concept is that a needle wouldn't be able to destroy a canyon while a 26th-century weapon might, but I'll experiment with that mechanic. Right now the main reason the shooters can destroy the walls in later levels is that I wanted to give each set of levels a slightly different feel, even when the enemies and their general behaviors get recycled. Bummer about the AFP. I don't have one, so I wasn't able to test there. (I fought with screen jitters with a Harmony cart, but I think those are all solved now.) Thanks for the comments! I'm looking forward to digging back in.

Cool. Thanks so much for the feedback! I'm glad you think it's going well so far. For #1, currently the cactus needle moves at 2 px / frame, and the enemy bullet moves at about 2 1/2 px / frame. (It's a random choice between 2 and 3.) I wanted their shots to be slightly faster than yours, at least where if the player and the gunman shot at the same time, the player would lose. But I'll play with those speeds a bit. They do shoot awfully fast. For #2, yes. The shots should be a bit wider (they're currently 1 px), but I was having trouble successfully changing the size of missile1. I'll figure it out and make it work. For #3, I agree--it's where I die the most when I'm playing--and for me it's kind of an unsolvable problem, unfortunately. There's a ton of code to make sure each canyon has enough paths. The placement of the shooters within those paths is more or less random (they need to have a small amount of space in front and behind them). Sometimes the water is literally straight across from you, and you just march across the screen. Sometimes you're just dealt an unsolvable maze. Slowing down their shots will give a bit more leeway, so I'll keep this in mind when changing that speed. The real issue is that I'm full at 32k, but I might be able to move some code around to at least guarantee slightly more space to the left of the shooters. Thanks again! I'll work on this and put up a revised version when I get one, perhaps this weekend.

The year is 2583, and you are the last cactus on Earth. You live in the scorching deserts of the Rocky Mountains in what used to be Alberta, Canada. The rest of your fellow cacti have moved to a more temperate climate on Mars. They have sent a final spaceship to take you home. Reaching it won’t be easy. Water has become Earth’s most precious resource, and although you are a cactus, you need every drop. Collect the water as you move through the canyons. Every so often, you’ll even find a bucket of it, and you’ll be able rest for the night. But watch out for the humans—the few that are left after World War XII. They think they need the water even more than you, and they’ll do anything to protect it. The shredders carry hidden machetes, and if they get close to you, they’ll cut you to pieces. The shooters don’t move, but take careful aim with their fully automatic plasma rifles. And the shredder-shooters are the most dangerous of all. Armed with their ion revolvers, they’ll track you and shoot you where you stand. As a cactus, you have only your needles for your defense. But life has been brutal, and you have few that remain. Aim carefully and only shoot when you must. Every so often, you’ll enter a dead-end canyon that has no clear path between you and the water. If that happens, you’ll automatically back up and find a new canyon with a better trail. You reckon there are about thirty canyons between you and your spaceship. Good luck. It will be a hard fight, but we know you’ll be home soon, Space Cactus! And if you find the first journey is too easy, why not move the left difficulty switch to Expert, pardner.

Hello everyone, Im happy to present the beta release of my first bB game, Space Cactus Canyon. Ill post the full story of the game below, but heres the short version: You are the last cactus on Earth. You need to collect water. Avoid the enemies and their bullets. Save your needles (bullets) until you really need them. Travel through thirty canyons and make it to your spaceship to take you to Mars! The game rewards reflexes as well as strategy. The thing Im most excited about is the procedurally generated playfieldsomething I havent seen in many other Atari games. From a programming perspective, Im also pleased I crammed four screens into the title screen kernel (with RevEng's help). The game also has an expert difficulty that makes the game markedly harder while still being playable. Id love any and all feedback. Ive played the game so much and know how it works, its optimal strategies, etc., that its hard to be objective. Is the balance of rules effective? Are there things that could make the gameplay more compelling? Most importantly, I just wanted to thank everyone in the community for helping me to get here. Ive really appreciated all the responses Ive gotten to questions Ive posted in the forums. (Searching the forums is also a treasure trove.) And of course, Random Terrains bB guide is indispensable. Hope you enjoy. Good luck, Space Cactus! Space_Cactus_Canyon_Beta_3.bin Space Cactus Canyon FINAL.bin

Cool. Thanks for the ideas. I'm in a phase where I'm trying to limit both code size and cycles, so I'll play around a bit and see what's most efficient.

The subroutine is called in every bank. But I just quickly tried thisbank with bank 2, and all the code within that bank seems to be executing properly. With some judicious pruning, I think I'll be able to get enough room to copy that gosub routine into the other banks and adjust the calls accordingly. I think this might work! I'll give an update once I'm able to go through all the code, but thank you so much! UPDATE: That's exactly what I did, and everything works again! This completely rescued my game. Should be able to go to beta now pretty soon. Thanks again!

Hello everyone, I'm trying to finalize a game with the DPC+ kernel. It's got a procedurally generated playfield (among other things), which means I need to call drawscreen a lot to prevent the screen from rolling. To minimize code space, I set up a gosub that looks like this: screenrefresh DF6FRACINC = 32 DF4FRACINC = 32 DF0FRACINC = 16 DF1FRACINC = 16 DF2FRACINC = 16 DF3FRACINC = 16 drawscreen return This code works perfectly as a gosub in Stella. But when I put it on my Harmony cart, the game crashes once its reaches it. I'm baffled by the difference. I really, really need this code to work as I'm down to < 100 bytes in each of my banks (many are < 30), and according to my tests, each new drawscreen call takes up 24 bytes. I know I could instead do this with a labyrinthine system of gotos, but that won't be as efficient as I need it to be, either. I'd really appreciate any advice. Thanks.