bjbest60

Those are both great ideas. I figure I could also add one or two more pickups once the score hits 100 or 1,000. I haven't really tried ensuring the code is as compact as it could be, so I imagine I'd be able to find a bit of room. I'll play with it a bit. Thanks!

235! Not bad. Well, the big exciting change at 100 is the change in the player's color. The points are also doubled once you hit 100 (and tripled plus another color change when you hit 1,000, etc.). There's nothing fundamentally different about the game, though. It lasts for as long as you want it to. But I'm very open to suggestions. I thought about using the switches for something that felt meaningful, but I couldn't really come up with anything. Maybe if you held down the select switch, the player would move faster (and then return to normal once you released the switch)? I don't know if that would add anything. Or maybe some combination of switches increases the drop rate of the items you collect? That feels Easter egg-y and I don't know if it changes the experience in any significant way. I don't have much room left in the ROM, but I'm definitely interested in ideas about things that could make the game more engaging.

Hello, all! I'm excited to release the beta of my next game, High Score Screen Burn Slow Burn. It's an experimental game where you play it by not playing it! I like trying to make games on the VCS that feature designs that are more contemporary or experimental--Space Cactus Canyon had procedurally generated playfields, for example. I also like weird, small Internet games that just do things normal games don't do, such as maybe not being a game at all. So, onward to the details! Objective: Get the high score! Players: One or fewer Controls: Maybe How to play: Start the game. Watch for a minute or two. Walk away. Come back in half an hour and check in. Walk away. Come back the following day, week, month. Check in. Do you have the high score yet? Secret tip: If you'd like to be slightly more active in your play, be sure your sound is on. It might occasionally rouse you to alertness! So, let me know what you think, if you find bugs, etc. As the title and "how to play" suggest, this game is indeed a slow burn--give it time. And, of course, be sure to post your high scores! Extra special fake bonus points if you're playing on a real TV. HighScoreScreenBurnSlowBurn FINAL.bin

So, it turns out the issue occurs only with my Jr. Both my light sixer and Vader have no problems. Thanks so much for talking through this; I'm glad to know I wasn't completely off-target, and of course I'm glad that I can get back to developing. The Jr. has been finicky, but has never shown any obvious malfunctions before. So I don't know if it is indicative of any larger problem or if it's just the unit itself (which came in a dusty box from a garage sale). But if it's of any use, the serial number is A1 79 1401095. Thanks again!

Yes, that's exactly the corruption I'm seeing. Thanks for the info so far. I've got two other systems at home and will check on them as well. The Jr. has been a little finicky for me in general, so who knows what's going on under the hood. I'll report back once I can test the others.

Here's the .bin for the minimal example. Thanks for looking into it! score_weirdness_minimal.bin

I am getting the same issue with the absolute minimum code (also attached): score = 134700 : scorecolor = $08 main if joy0up then score = score + 1 drawscreen goto main I've chosen the weird score to show the problem. The 1 in the hundred thousands and the 4 in the thousands are corrupted. I'm running this on an Atari Jr.; I have no idea if that would impact anything. It never has in the past. score_weirdness_minimal.bas

Yes, everything's up to date. bB version is reveng40. Stella is 5.0.2, where, again, the score is fine. I've tried replacing the score_graphics.asm with a new copy from a fresh download and that hasn't helped, either. Harmony BIOS should be fine, as I got the cart last year. To be sure, I just reinstalled bB, Visual bB, and Stella. I get the same result on the cart.

Hello all, I'm working on my next game, and I'm encountering a very strange score corruption. If the ones digit is 2, 3, 6, or 7, the tens digit will be off by one line, displaying the bottom of the next number in sequence and the top seven lines of the correct number after that. If the tens digit is any number, it won't corrupt the hundreds digit. But if the hundreds digit is 2, 3, 6, or 7, it corrupts the thousands digit. (I imagine this has something to do with how the score is broken into three separate parts?) This only happens on my Harmony cart. On Stella, everything is fine. Is this somehow a Harmony bankswitching issue even if there's one bank? I'm at a loss. I've attached a bare-bones version of the code I'm using. Press up to increase the score. I'm also attaching my score_graphics file; I've been working on a custom font, but in this example I'm using Retroputer and I'm still having the same issue. I don't think I've directly edited score_graphics, but maybe the problem is there? Thanks for any help you can give. I'm baffled. score_weirdness.bas.bin score_weirdness.bas score_graphics.asm

Thanks for the video; I hadn't seen that one before. He's using an existing board (I'd like to use a new board made for homebrew purposes) and not dealing with 4k; I imagine the process is similar. But I know from these types of projects that similar isn't always the same. There are several posts on the forum about this topic (searching for "EPROM" is very helpful), but nothing seems to verify the exact steps or requirements, and some of the info is outdated in terms of suppliers. I figured a complete list would benefit others interested as well. (Maybe this seems more obvious to people who know programming / engineering / hardware well, but that isn't me, alas.) I don't own any of the hardware beyond soldering stuff, so I want to make sure I'm getting everything right the first time. So, I'd appreciate it if someone could verify my equipment list and general steps. I'd also appreciate any advice for overall success. Thanks!

Hello everyone, I'm looking for a complete list of components needed to make my own cartridge, as well as the procedure to make that happen. I feel like I've got a lot of snippets of understanding from searching through various things, but not a single, complete answer to create a final product. (Apologies if this has been answered elsewhere; if so, I'd appreciate the redirect.) I know I can have other people make a cart for me. Part of this is a "because it's there" challenge. But I'm also making a few experimental games where I'd like to create a few copies and give them away or sell them, and I kind of like the idea of being an indie game publisher of a very, very limited sort. Anyway, below is my (probably incomplete) understanding of the parts required and the process. Please correct / add / clarify! What are the common pitfalls here? Also, if you have preferred brands / suppliers for any of this stuff, I'd appreciate that info, too. Thanks! Required: .bin Premade PCB EPROM that matches the PCB and .bin requirements EPROM programmer Soldering supplies Cart shell Label Steps: 1.) Make final .bin. 2.) Program EPROM with .bin. 3.) Solder EPROM to board. 4.) Put board in shell. 5.) Assemble shell and add label.

Yes! I'm really pleased with how they turned out.

A draft of the notice that will go inside the box ... Will you be cactus enough?

This is a really interesting question. I think fundamentally you're right, most games (especially for the Atari) are predicated on whether or not things are colliding. But I can think of a few examples where it isn't collision that drives some elements of game play, at least with sprites. One goal rather than dealing with enemy sprites would be to simply move a player or object to a certain location. All racing games eventually have this--you cross the finish line. Sports games, too. For Pong, your goal is to make the ball not collide with the other player, and you only score a point when it goes off the screen. A maze game is probably the purest example of this. If you get from point A to point B, you win, no other sprites required. But the pits in platformer games are lethal for precisely the same reason--you cross a certain location. And you can only win Adventure by dragging the amulet to a particular location--inside the yellow castle. (Of course, all of these games do have collision aspects, too.) There are also ways a player might indirectly destroy a sprite without colliding. Some shmups offer a sort of magic bomb that can destroy all enemies on a screen, for example. I'm sure there other examples I'm not thinking of. (Dark Mage comes to mind. It's a text adventure, which offers a completely different conception of graphics and their usage.) Other icon-based games (such as simulations) or puzzle games might conceive of sprites differently than standard player/enemy usage. There are a lot of good books out there that cover all aspects of game design. One I'd recommend is Level Up!: The Guide to Great Video Game Design by Scott Rogers. It's skewed to more contemporary games, as you might expect, but he has a whole chapter on enemies. The various types that he lists are chasers, shooters, guards, flyers (i.e., they can fly), bombers (they don't directly touch the player, but the bombs can), burrowers (they can hide and reappear), teleporters, and blockers (resistant to player attacks, either temporarily or permanently). Beyond behavior, he says enemies are also defined by their size, speed, movement, and attacks. I'm sure there's much more to say on this, but those are some thoughts for now.

Thanks all! I'm really excited by how the design is coming together. Unfortunately, since this game uses the DPC+ kernel, it isn't compatible with the AFP. However, there might be a reward for those who master the game on original hardware ...

I'm excited to share the design of the box for the upcoming release! The cacti are coming soon ...

I haven't heard any additional feedback, so I'm pretty close to calling the game as complete. (I'm still happy to hear others' reports, of course.) Several people have been interested in seeing this on a cart. What are the options for making that a reality? Thanks again, everyone.

Hello, everyone! After a lengthy delay, I'm happy to release the third and possibly final beta version of the game. The file is attached to the first post. In this version, I've tried to hunt down every bug that I could catch. (Some took a painfully long time to solve.) I've also tested thoroughly on two different systems with two different TVs via the Harmony cart. Some major fixes: Fixed the bankswitching issue that caused the game to crash on Harmony. Ensured there's always sufficient width in the rows for the cactus to have a path to the water. Cured (hopefully) some weird sound glitches Fixed an issue where, when two shooters were in the same vertical column and one horizontal row away from each other (i.e., one was directly on top of the other), if you shot the top shooter, the bottom one would disappear instead. There are two known remaining issues, and unfortunately aren't solvable given the space limitations of the code: Sometimes in the bonus round, there isn't a path between you and the replenishing needles. In rare instances (I haven't had this happen yet in my testing), there will be a narrow vertical chute that you'll have to cross, directly into the path of a shooter without sufficient space to get off a shot (i.e., it's a guaranteed death). I'm also proud to report that I finally beat the game on the Expert difficulty! Thanks to everyone who has commented here; the game is so much better than the first playable beta. Please check out this near-final version, and let me know of any bugs or weirdness. It was actually good to get away from the project for a bit because upon returning to it, I could evaluate it with fresh eyes. I'm looking forward to getting a final version done soon!