Batari Basic game possibly for sale?

[+atari2600land]

If I put this new game in a cartridge and started selling it, #1: Would it be the first time a batari Basic game would be for sale, and #2: Would anyone buy it? I just finished a game called "Ants!" and I don't know whether I should release the bin file for fear of people not buying the game when they could have it for free. If this game were to be released, it would probably be during the holiday season cuz my birthday is in early November and I usually get at least $130 from my grandpa. Last year my dad gave me an additional $100, but I don't know how much he's planning on giving me. What it all boils down to is how much it costs for AtariAge to put together carts and labels. I can handle the instruction manual printing cuz it's only gonna be a sheet worth of instructions. If I do have the money to make at least 20 carts, I'll price it for $17.17 U.S. and I'll have a label making contest.

[vdub_bobby]

AA has prices for that stuff, just look around the site a little. EDIT: Look here: http://www.atariage.com/store/index.php?main_page=homebrews

 

And at least one bB game is for sale right now: Solar Plexus, for $20.

 

EDIT: To answer your questions more specifically:

 

#1 A bB game is already on sale in the AA store.

#2 I dunno. Depends on the quality of the game, label, cart, and manual. And relatedly, if you want to sell carts, release the binary image. Especially for bB games, which are generally not as high quality as an assembly game, people are going to want to know what they are buying before they buy it.

Edited June 15, 2006 by vdub_bobby

[+atari2600land]

Here's the binary image. The question now is would you people buy this?

ants.bin

[SeaGtGruff]

Here's the binary image. The question now is would you people buy this?

To be honest, not in its present form. For one thing, the joystick controls have some problems (e.g., try to move diagonally up and to the left), but those sorts of things are easy to fix. And I think the game would be more interesting if there were some kind of "obstacle course" that the player had to navigate through to reach the ants before they disappeared-- not necessarily a maze, but maybe at least some objects of some kind (e.g., plants, pebbles-- which would of course look like boulders from a bug's perspective-- or anything else the player has to move around). And you could have increasing difficulty levels, like at first the ants could be stationary, then they start moving around a little bit, then as the levels get higher they get a little faster each time. Also, the low levels could have no obstacles, then as the levels get higher, you could gradually add more obstacles, and even have some moving obstacles (like a slow-moving avalanche of pebbles, or something-- one pebble at first, then two, then three, etc., as the levels get higher and higher). Or you could have some other critter (e.g., a wasp?) that comes out every so often and tries to get you before you can get the ant. As far as the graphics, you could animate the ants and the player to make them more interesting. And you could change the colors every level or so to make things more interesting, or have different colored ants with different numbers of points based on their colors. Or maybe the ants could change color as the timer counts down (or up), to give the player a visual cue about how much time is left before the current ant disappears (or maybe it starts flashing a second or two before it disappears?). Also, the ants might be more interesting if they popped up out of the ground and then popped back down into the ground, instead of just appearing and disappearing all of a sudden. Maybe you could have several ant holes that are scattered around the screen-- they would stay in the same place during a given level, but they could change locations-- and maybe increase in number-- as you clear each level. And if the ants get to where they move around a bit, maybe they could pop up out of one hole, then move to another hole and crawl down into it, or something like that. Another idea is to maybe have some kind of "bonus round" every so many levels, like every fifth level or whatever.

 

Anyway, the basic game idea-- catch the ants before they disappear-- definitely has potential, and you can do a lot with it if you let your imagination go wild, so don't think of your current version as a finished product. In the game industry (which I have never worked in, by the way, so I guess I don't really know what I'm talking about!), an important part of producing a game is to give it to play testers so they can find and report any problems that they run into (like the problem with moving diagonally), and to get feedback from people about what they like most about the game, what they don't like, what they think could be done to make the game more fun to play, etc. So I gave you some of my ideas, and hopefully other people will share their thoughts, then you can consider any ideas that people suggest, decide which ones (if any) you like, decide how to add them into your game, etc. After all, it's your game, and you have creative control over it!

 

Best of luck with your game-- and most importantly, have fun making it!

 

Michael Rideout

[+atari2600land]

I got the ant to change color when it's close, but I can't get the background color changing commands to work. Why not?

 

Note that score>2 is for test purposes only.

ants2.bas

Edited June 16, 2006 by atari2600land

[SeaGtGruff]

I got the ant to change color when it's close, but I can't get the background color changing commands to work. Why not?

 

Note that score>2 is for test purposes only.

It's because this line doesn't work the way you think:

 if score>2 then COLUBK = 64 : COLUPF = 64

"score" is a 3-byte variable, with each nybble or half-byte representing a digit from 0 to 9 (i.e., it's in the BCD or "binary coded decimal" format). That's OK, but "if" can compare only 1-byte values, so when you say "if score>2" you are actually checking the byte which holds the two leftmost digits of the score. To do what you're trying to do, you need to make bB check the byte which holds the two rightmost digits of the score. Since the "score" variable is 3 bytes, you can refer to each byte using the array notation-- "score[0]" (or just "score") for the first byte, "score[1]" for the second byte, and "score[2]" for the third byte. Thus, if you change the line to the following, the background color will change as soon as the score increases from 2 points to 3 points:

  if score[2]>2 then COLUBK = 64 : COLUPF = 64

By the way, I see that you fixed the diagonal movement. Much nicer!

 

Michael Rideout

[+atari2600land]

So how do I change it from 10 points & up? Suppose I want to change the background color after 19 to 20. How would I do that?

Edited June 16, 2006 by atari2600land

[SeaGtGruff]

So how do I change it from 10 points & up? Suppose I want to change the background color after 19 to 20. How would I do that?

The key is to understand how binary coded decimal (BCD) numbers work. Basically, each nybble or half-byte can store a value from 0 to 15, so each nybble is used to store a digit from 0 to 9. The easiest way to refer to a specific BCD value is to use hexadecimal notation. Thus, if the score is 19, that means the byte at score[2] contains a hexadecimal value of $19 (i.e., the digit 1 is in the high nybble, and the digit 9 is in the low nybble). So to change the background color when the score goes from 2 to 3, and then again when it goes from 19 to 20, you can use the following lines:

 if score[2]>2 then COLUBK=64 : COLUPF = 64
 if score[2]>$19 then COLUBK=34 : COLUPF = 34

Note that you could also write the first line as "if score[2]>$02".

 

Michael Rideout

[jbanes]

I think that SeaGtGruff covered the issues with the game pretty well, so if I may, I'd like to throw out a little bit on the business side of the equation.

 

The purpose of any business is to create value. The value they create is what they sell to make money. When you compare two products in the store, you're going to look at the overall value to you vs. the cost and make a decision based on that. While there are many forms of value (e.g. Does this soda taste better than the other one? Does this product save me time and money? Will this product provide entertainment worth the money I'm spending?), video games tend to focus on entertainment value. People *want* to purchase a game if they expect an exceptional amount of entertainment for their money. The most popular type is probably escapist fantasy games, (e.g. games set in interesting and far away worlds or familiar properties like Star Trek and Star Wars), but that is not a requirement to creating a good game.

 

When you consider the matter of creating a game from a value perspective, one thing becomes abundantly clear. If it's quick and easy to do, it's probably not worth much. After all, if you didn't invest much into creating value, how likely is it that value was created? Sometimes you can create value through extreme originality (e.g. Tetris), but even then a bit of polish goes a long way.

 

So what's the best method of attacking the problem? That actually depends on you and what you want to achieve. However, I can provide a few guidelines. The biggest one, I think, is that you should make sure that your game is fun for you to play. Which means that you should spend a lot of time playing it. If you feel that you're putting it down quickly, consider how you might improve it. Remember, you're the programmer, not just the beta tester! You can make your game better! Add features that you feel will improve the gameplay. Try to get your friends hooked on it too.

 

To give an example of this process, I'm going to point to the last game I completed. (Requires Java) Whipping it together in the first place was pretty easy, but it got about a year of on and off improvements after that. I'd just pull it out every once in awhile, and see what I could do to make it more fun. The bosses were actually added shortly before I submitted it to the contest. Features like the boss life meter and faster vertical thrusters were added based on feedback from other players. In the end, I think it turned out pretty darn well. But it took an incredible amount of effort to do it.

 

Now imagine something like Thomas's Thrust. He had to invent brand new ways of doing things, just to make it possible! Conquest of Mars is obviously done by an experienced Atari programmer. Even AStar obviously took a lot of time and testing to work out all the puzzles. (I'm willing to bet that a lot of people found ways around the intended solutions during the beta period. ) So there's definitely a lot of work required in competing.

 

The reason why I'm telling you this is not to discourage you. In fact, I think your game could become a hit. Unfortunately, you've just started. You need to give it a lot more time and energy. Let the creative juices flow. If you get stuck, go play a few other games for inspiration. If that doesn't help, try to flesh out the game with a silly backstory. It might inspire new improvements to the game.

 

With a bit of time and energy, I fully expect that you could exceed all expectations. Good luck to you!

 

Edit: I forgot to mention one thing. I wouldn't worry too much about distributing the ROM. Most players here want a physical cartridge, and actually prefer being able to try the game before they commit to such a purchase. Sure, some of the users have CuttleCarts, but even many of them prefer to pay money for a well-done cart. It's not often that your customers and your beta testers can be the same group, so I'd suggest that it's a good situation to take advantage of. Just my opinion, though. Everyone has their own take on intellectual property.

Edited June 16, 2006 by jbanes

[+atari2600land]

So why is it that when I put in this code:

 if score[2]>$09 then COLUBK = 36 : COLUPF = 36
 if score[2]>$19 then COLUBK = 192 : COLUPF = 192
 if score[2]>$29 then COLUBK = 80 : COLUPF = 80
 if score[2]>$39 then COLUBK = 168 : COLUPF = 168
 if score[2]>$49 then COLUBK = 240 : COLUPF = 240

once score gets to 10 it goes to COLUBK = 240 and COLUPF = 240, which it should do once it gets to 50?

[SeaGtGruff]

So why is it that when I put in this code:

 if score[2]>$09 then COLUBK = 36 : COLUPF = 36
 if score[2]>$19 then COLUBK = 192 : COLUPF = 192
 if score[2]>$29 then COLUBK = 80 : COLUPF = 80
 if score[2]>$39 then COLUBK = 168 : COLUPF = 168
 if score[2]>$49 then COLUBK = 240 : COLUPF = 240

once score gets to 10 it goes to COLUBK = 240 and COLUPF = 240, which it should do once it gets to 50?

Hmm, this looks like a bug in bB, or else I'm not understanding something that got changed from an earlier version? It looks like the hexadecimal values are possibly being misinterpreted as memory addresses(?) rather than as immediate values? If you convert the hexadecimal BCD values to their equivalent decimal values, and use the decimal values, it works as you intended:

 if score[2]>9 then COLUBK = 36 : COLUPF = 36
 if score[2]>25 then COLUBK = 192 : COLUPF = 192
 if score[2]>41 then COLUBK = 80 : COLUPF = 80
 if score[2]>57 then COLUBK = 168 : COLUPF = 168
 if score[2]>63 then COLUBK = 240 : COLUPF = 240

($19 is hex for 25, $29 is hex for 41, $39 is hex for 57, and $49 is hex for 63.)

 

Michael Rideout

[jbanes]

So why is it that when I put in this code:

 if score[2]>$09 then COLUBK = 36 : COLUPF = 36
 if score[2]>$19 then COLUBK = 192 : COLUPF = 192
 if score[2]>$29 then COLUBK = 80 : COLUPF = 80
 if score[2]>$39 then COLUBK = 168 : COLUPF = 168
 if score[2]>$49 then COLUBK = 240 : COLUPF = 240

once score gets to 10 it goes to COLUBK = 240 and COLUPF = 240, which it should do once it gets to 50?

 

Looks like a signed comparison problem to me. When using signed numbers, $49 would actually be a negative decimal number. Batari BASIC seems to be ignoring the sign, which means that $49 == $9. So the last "if" will trigger for any score above 9.

 

I'll let the Batari experts figure out how to force it to work with unsigned numbers. (I have no idea, personally. I just did a few tests to figure the problem out.)

 

Edit: On second thought, that doesn't make sense. 4 is over from the sign by one binary digit. But the program is obviously ignoring the upper two bits. Numbers below that seem to work fine.

Edited June 16, 2006 by jbanes

[+atari2600land]

Here's the bas file from where I got the code if that helps. I did change a line number so the line numbers would be in order, but that's it.

ants3.bas

[SeaGtGruff]

Looks like a signed comparison problem to me. When using signed numbers, $49 would actually be a negative decimal number. Batari BASIC seems to be ignoring the sign, which means that $49 == $9. So the last "if" will trigger for any score above 9.

 

I'll let the Batari experts figure out how to force it to work with unsigned numbers. (I have no idea, personally. I just did a few tests to figure the problem out.)

 

Edit: On second thought, that doesn't make sense. 4 is over from the sign by one binary digit. But the program is obviously ignoring the upper two bits. Numbers below that seem to work fine.

I don't know, there is definitely something odd going on. I just read in the bug report thread that "score = value" displays a score of 70 (doesn't matter what you set "value" to), and I was playing around and saw that "score = a" compiles as "LDA #$049 : STA score+2", so somehow bB is interpreting "a" to be "#$049". Likewise, "b" is "#$050", "c" is "#$051", etc. Guess what "v" is? So bB is taking the first letter of the variable name ("value" or "v"), even if "dim value = a" defines "value" as the variable "a".

 

On the other hand, "score = $11" correctly sets score+2 to #$11, but sets score+1 to #$0-12 (!). There's definitely something flakey going on, perhaps in the preprocessing before bB compiles it?

 

Michael Rideout

[SeaGtGruff]

Here's the bas file from where I got the code if that helps. I did change a line number so the line numbers would be in order, but that's it.

By the way, you don't need to use line numbers with bB. And if you do use line numbers, they don't need to be in order, since they're actually interpreted as alphanumeric line labels. So you can take off all of the line numbers on lines you aren't branching to; and on lines where you need to branch to, you can use line labels instead. This may not seem like a big deal, especially if you're used to using line numbers, but using alphanumeric line labels can make it easier to understand a program-- at least, if you use line labels that explain what a routine is for, such as

 goto update_players_positions

instead of

 goto 1500

 

Michael Rideout

[+atari2600land]

Here's the bas file from where I got the code if that helps. I did change a line number so the line numbers would be in order, but that's it.

By the way, you don't need to use line numbers with bB. And if you do use line numbers, they don't need to be in order, since they're actually interpreted as alphanumeric line labels. So you can take off all of the line numbers on lines you aren't branching to; and on lines where you need to branch to, you can use line labels instead. This may not seem like a big deal, especially if you're used to using line numbers, but using alphanumeric line labels can make it easier to understand a program-- at least, if you use line labels that explain what a routine is for, such as

 goto update_players_positions

instead of

 goto 1500

 

Michael Rideout

I like using line numbers because I started programming stuff way back with QBasic and that's how that program worked. Anyway, when I set it to this:

226 COLUBK = 30 : COLUPF = 30
 if score[2]>9 then COLUBK = 36 : COLUPF = 36
 if score[2]>25 then COLUBK = 80 : COLUPF = 80
 if score[2]>41 then COLUBK = 192 : COLUPF = 192
 if score[2]>57 then COLUBK = 180 : COLUPF = 180
 if score[2]>63 then COLUBK = 6 : COLUPF = 6

It skipped 57 and went to 63.

[SeaGtGruff]

I like using line numbers because I started programming stuff way back with QBasic and that's how that program worked. Anyway, when I set it to this:

226 COLUBK = 30 : COLUPF = 30
 if score[2]>9 then COLUBK = 36 : COLUPF = 36
 if score[2]>25 then COLUBK = 80 : COLUPF = 80
 if score[2]>41 then COLUBK = 192 : COLUPF = 192
 if score[2]>57 then COLUBK = 180 : COLUPF = 180
 if score[2]>63 then COLUBK = 6 : COLUPF = 6

It skipped 57 and went to 63.

Yipes, that was a typo, the last line should have been "if score[2]>73" (notice that you add 16 to the previous number-- 9, 9+16=25, 25+16=41, 41+16=57, 57+16=73, etc.). Sorry about that!

 

Michael Rideout

[+batari]

So why is it that when I put in this code:

 if score[2]>$09 then COLUBK = 36 : COLUPF = 36
 if score[2]>$19 then COLUBK = 192 : COLUPF = 192
 if score[2]>$29 then COLUBK = 80 : COLUPF = 80
 if score[2]>$39 then COLUBK = 168 : COLUPF = 168
 if score[2]>$49 then COLUBK = 240 : COLUPF = 240

once score gets to 10 it goes to COLUBK = 240 and COLUPF = 240, which it should do once it gets to 50?

Hmm, this looks like a bug in bB, or else I'm not understanding something that got changed from an earlier version? It looks like the hexadecimal values are possibly being misinterpreted as memory addresses(?) rather than as immediate values? If you convert the hexadecimal BCD values to their equivalent decimal values, and use the decimal values, it works as you intended:

 if score[2]>9 then COLUBK = 36 : COLUPF = 36
 if score[2]>25 then COLUBK = 192 : COLUPF = 192
 if score[2]>41 then COLUBK = 80 : COLUPF = 80
 if score[2]>57 then COLUBK = 168 : COLUPF = 168
 if score[2]>63 then COLUBK = 240 : COLUPF = 240

($19 is hex for 25, $29 is hex for 41, $39 is hex for 57, and $49 is hex for 63.)

 

Michael Rideout

Yes, it does appear to be a bug. I'm not sure yet why it's not liking hex numbers, but yes, it does work fine with decimal, or strangely, it works fine with hex if you write it like this:

if $49<score[2] then ...

 

This one's baffling. I'll look into it tonight.

[SeaGtGruff]

Yipes, that was a typo, the last line should have been "if score[2]>73" (notice that you add 16 to the previous number-- 9, 9+16=25, 25+16=41, 41+16=57, 57+16=73, etc.). Sorry about that!

 

Michael Rideout

No, that isn't it, either. It looks like a bug. When I look at the compiled code, it looks very odd:

.L013;  if score[2] > 41 then COLUBK  =  80  :  COLUPF  =  80

LDX #2			   ; Huh?
LDA 41,x			 ; What the... ?
LDX #2
CMP score,x
 BCS .skipL013
LDA #80
STA COLUBK
STA COLUPF
.skipL013
.L014;  if score[2] > 57 then COLUBK  =  168  :  COLUPF  =  168

LDX #2			  ; Weird...
LDA 57,x			; Very weird!
LDX #2
CMP score,x
 BCS .skipL014
LDA #168
STA COLUBK
STA COLUPF
.skipL014

[+batari]

Yipes, that was a typo, the last line should have been "if score[2]>73" (notice that you add 16 to the previous number-- 9, 9+16=25, 25+16=41, 41+16=57, 57+16=73, etc.). Sorry about that!

 

Michael Rideout

No, that isn't it, either. It looks like a bug. When I look at the compiled code, it looks very odd:

LDX #2			 ; Weird...
LDA 57,x		; Very weird!
LDX #2
CMP score,x

Yeah, that's weird!

 

I think I've tracked down the bug, and its cause is indeed weird. Apparently bB thinks that both values are indexed, but only if the first is indexed, the string length of the first value is a lot longer than the second, and we are doing > or <=. Otherwise, it works fine. I think I know how to fix it, but for now, this does work:

 

if 73<score[2] ...

[+atari2600land]

Well, here's the latest version. Suggestions/Improvements welcome

ants.bin

[Thomas Jentzsch]

Suggestions/Improvements welcome

More gameplay!

Add obstacles, maybe make the ants wandering around, give the player something to defend, add bonus items, utilize the fire button...

 

Better presentation!

Add animation (e.g. let the ant crawl and die), maybe multi colored sprites, lots of sounds...

 

Polish the game!

The game just ends with a black screen which is pretty lame. There is no reward for the player except for the score going up. Let him play in rounds, so that he can win a round. Make a nice intermission screen as reward, or at least a little tune. Give him bonus points for reaching an ant fast and for not missing any ant in a round...

 

Currently the game is IMO not addicting at all. Sorry.

[+atari2600land]

Suggestions/Improvements welcome

More gameplay!

Add obstacles, maybe make the ants wandering around, give the player something to defend, add bonus items, utilize the fire button...

 

Better presentation!

Add animation (e.g. let the ant crawl and die), maybe multi colored sprites, lots of sounds...

 

Polish the game!

The game just ends with a black screen which is pretty lame. There is no reward for the player except for the score going up. Let him play in rounds, so that he can win a round. Make a nice intermission screen as reward, or at least a little tune. Give him bonus points for reaching an ant fast and for not missing any ant in a round...

 

Currently the game is IMO not addicting at all. Sorry.

How am I supposed to do all that with only 2K left? That, and this is my second game I ever made with batari Basic, so I don't know all the ropes yet. As for bonus items and/or something to defend, how can there be any if player0 and player1 are used up and all the rest of the available sprites are lines? I'd also like to learn how to make music with Batari so I could add a little song with the title screen. I know this game is far off from finished, but maybe if there were like a list of code examples, I could do a little bit more with this. I'd add something to defend or some enemies or something if someone would tell me how to make more than 2 different sprites with batari Basic. Thanx for the suggestions.

[Thomas Jentzsch]

How am I supposed to do all that with only 2K left?

I don't know, I never used batari Basic, so I won't be able to help you here.

 

But you asked, because you want to sell the game and even started wondering about a label contest. And then you should IMO offer a lot more value than currently. I can comprehend that you are pretty enthusiastic about your creation. But as you already know, there is still a lot you have (and want to) learn.

 

So before bringing your game into competition with other homebrews and actually try to sell it, I suggest improving your skills first and finally the game itself. Not every suggestion I made above may be possible (or even good). But if even an unimaginative person like me has so many ideas, then I can assure you, something is definitely missing.

 

BTW: IMO the very same is true with your current submission to the Minigame Competition. Fortunately there is quite a long time until the deadline for 4K, so you can improve and resubmit your entry there too.

Edited June 16, 2006 by Thomas Jentzsch

[jbanes]

How am I supposed to do all that with only 2K left?

Pff! The whole game is currently fitting into 2K, so you have plenty of space to double it!

 

Actually, you have space to not-quite triple it. The first 1K is used by bB, so you're only using a bit over 1K for your game at the moment. Basically, you've got lots o' space.

 

That, and this is my second game I ever made with batari Basic, so I don't know all the ropes yet. As for bonus items and/or something to defend, how can there be any if player0 and player1 are used up and all the rest of the available sprites are lines?

Missile graphics? Ball? Pretty Playfield designs? Get creative!

 

I'd also like to learn how to make music with Batari so I could add a little song with the title screen.

 

Just a suggestion, but you might want to focus on sound effects first. The effects are noticably absent, whereas title ditties are actually quite rare on the 2600.