Astroshoot

[+atari2600land]

In case you don't read my blogs, I'm making an Astrosmash-type game, and I'd like your comments about it so far.

astroshoot2.bas.bin

[gambler172]

Hi

can become a good game,if you add some more different looking enemies.

greetings gambler172

[jbanes]

The shots need to be a LOT faster. They shouldn't take as long to move up the screen as the asteroid does to come down. This will also help compensate for the single-shot design.

[Thomas Jentzsch]

Why do you always play around with new, but pretty basic ideas?

 

IMO it would be much better if you develop and finish one idea first instead of mass-producing undercooked demos. Have look at other bBASIC games, there are some pretty good examples of what is possible.

[+atari2600land]

I thought Ants/Ima Dyma was pretty new. The only other example of that I've seen so far on the 2600 is Tapeworm. In answer to your question, though, is because, I admit it, I don't really have any ideas. That and I'm trying to get used to the software. I've only been playing with this stuff since June, you know.

[jbanes]

I think what Thomas is intending to say is that you could take the individual games you write much further than you do. It seems to most people that you stop just as the game is becoming really playable. (e.g. Spacebacon.) He was merely suggesting that you take your good games and make them GREAT games. I don't think this is what he wanted to happen:

 

http://www.atariage.com/forums/index.php?a...;showentry=2102

 

That said, I understand what you're doing. By creating all those minigames, you've been learning. And it shows. Each iteration of your titles has been steadily improving. You're getting to the point where you probably need to start thinking about making more complex gameplay dynamics. For example, we were having a discussion about Activision not all that long ago. One problem that Activision realized was that many Atari games got repetitive. Unfortunately, when the games got repetitive, they got boring. So Activision analysed the problem and realized the solution: Every game needs a shark.

 

By "shark", they meant that something unexpected needed to happen to break up the monotony. In Fishing Derby, this was an actual Shark. In Enduro and Robot Tank, this was changing weather patterns. In Beamrider this was a boss character. In Stampede this was skulls and stopped cows. No matter what it was, there was always some sort of change happening.

 

Imagine playing Enduro if the weather never changed? Passing all those cars would get pretty boring after a while, don't you think? But by switching you between icy sliding, darkness, fog, and back again to a normal track, Activision played with your emotions. You felt anxious when you came across a new weather pattern. When you lasted through it, you felt relief and triumph. When you got farther than you'd ever gotten before, you felt accomplishment.

 

The model that Activision pioneered is the one that game designers continue to refine. Levels, powerups, traps, etc. are all outgrowths of that same idea of 'shaking things up'. So don't stop working on games. See about making them better and better!

[Thomas Jentzsch]

I don't think this is what he wanted to happen:

Definitely not.

[neotokeo2001]

http://www.atariage.com/forums/index.php?a...;showentry=2102

 

Stay with us now.. Things are not that bad.

 

With Super Maria Sisters and Space Bacon you have two really nice games that are real close to being great little games. You just have to take some time and polish them up and tweak them. I know that you are new and have run into a wall a few times but that is what the forum is for. There are a lot of people here that can help with problems(As you have seen).

 

I have no programming knowledge so you are way ahead of me. But that doesn't stop me. When I run into dead-ends or as far as I can go, there is always someone willing to help.

[+atari2600land]

Well, thanks for the support. The computer that had the code for Super Maria Sisters and Space Bacon on it broke. So unless someone wants to take a look at the code in the binary versions and reproduce it in Batari BASIC, I'll have to start over again. I think I can remake Space Bacon kind of easily, but Super Maria Sisters will be a hard one. Well, I've added a third version of Astroshoot. I've been thinking of ways to get a shark in here, and I have a couple ideas:

- On the later levels, make the asteroids or the ship quad-player size.

- Have special indestructable asteroids

- Have a little thing go halfway at the bottom of the screen where the ship is to avoid.

I also made a problem with this new version: When you're really close to an asteroid and shoot it, the bullet keeps going up. Either that, or it automatically fires a new one (I can't tell which.)

If anyone has any suggestions on how not to make this just another Astrosmash clone, I would like to hear them. Maybe I could use a few of them.

astroshoot3.bas.bin

[jbanes]

The computer that had the code for Super Maria Sisters and Space Bacon on it broke.

That's sad.

 

Well, I've added a third version of Astroshoot. I've been thinking of ways to get a shark in here, and I have a couple ideas:

- On the later levels, make the asteroids or the ship quad-player size.

- Have special indestructable asteroids

- Have a little thing go halfway at the bottom of the screen where the ship is to avoid.

Well, the original astrosmash actually had a few sharks of its own. You might be able to learn from those. The big one was a special spinner that was slow to fall, but would kill you if it hit the ground. (Note that I said the ground, not your ship.) This basically forced you to deal with it whenever it showed up.

 

Another thing Astrosmash did was that it threw large and small rocks at you. The large rocks would split into two small rocks when shot. Small rocks would be destroyed immediately. You should be able to recreate the splitting by reusing the second sprite and one of the missiles. (I presume you have a missile free, right?) It can also be done with flickering.

 

Astrosmash also had only two or three rock speeds, but it randomly threw them at you. So one rock might be slow, but the next one might be fast. An option in your case is to have fast and slow, but bump up the fast and slow speeds with fractional nudges every time the player levels up.

 

Last but not least, Astrosmash subtracted from your score every time a rock hit the ground. This created an incentive to take risks shooting the rocks. If you took no risk, then you'd quickly find yourself back at zero. In your version, the player can pick and choose which rocks he goes after with no consequences.

 

I also made a problem with this new version: When you're really close to an asteroid and shoot it, the bullet keeps going up. Either that, or it automatically fires a new one (I can't tell which.)

It automatically fires another one. You need to record the previous state of the button so that you can check it each frame. If the button was pressed in the last frame, then don't fire. If it wasn't pressed, then do fire. This logic will fix the issue and make the game seem a bit more polished.

[Thomas Jentzsch]

A lot of really good suggestions.

[+atari2600land]

Updated Astroshoot with new features, and, unfortunately, new bugs. Here's a list:

 

New features:

- Added a second big rock.

- When big rock gets shot, splits into two seperate rocks (used NUSIZ1=$01)

- When rock hits ground, score decreases by 1

 

Old feature taken away:

- since I had to move player0's missile (which was missile1) to missile0 in order to use the NUSIZ1 feature, I lost the ability to use no_blank_lines.

 

New bugs:

- When a big rock gets shot far up, it doesn't split into two.

- Little white specks appear sometimes when rock is shot.

 

If someone has some free time, maybe someone can help me with these bugs. The original bug is still there, and I used variable b as a flag to indicate whether joy0fire has been shot, too.

 

EDIT: e is the flag that says joy0fire is true, not b. I'm also working on a way to make the second rock be seperate from player1 (like missile1 or ball), but I can't seem to make it work for some reason. I'll keep trying and eventually post whatever I've done so far on that here.

astroshoot4.bas.bin

astroshoot4.bas

Edited September 29, 2006 by atari2600land

[jbanes]

This code won't do what you want by itself:

 

144 if joy0fire && e=0 then e=1
145 if e=1 then d=d-2
if d=10 then e=0

 

All it does is prevents firing until the bullet reaches the end of the screen. What you want is something like this:

 

  if joy0fire && e=0 && p = 0 then e=1 : p=1
 if !joy0fire then p = 0
 if e=1 then d=d-2
 if d=10 then e=0

 

That way you're tracking three variables:

 

1. If the fire button is pressed.

2. If the bullet is firing.

3. If the user released the fire button after firing.

 

A mild improvement to the above would be to prevent the user from refiring altogether until after the current bullet is gone:

  if joy0fire && e=0 && p = 0 then e=1 : p=1
 if !joy0fire && e=0 then p = 0
 if e=1 then d=d-2
 if d=10 then e=0

 

A few more suggestions:

 

- Re-DIM all the variables before using them. You may know right now that 'p' stands for 'pressed', but anyone else looking at your code will have trouble understanding this. In addition, if you shelve the project temporarily, you may not remember yourself how it all works. So this:

  dim firing = e
 dim pressed = p
[...]
 if joy0fire && firing = 0 && pressed = 0 then firing = 1 : pressed = 1

is a lot clearer than this:

  if joy0fire && e=0 && p = 0 then e=1 : p=1

As a bonus, you can tell which variables you're using by looking at the list of 'dim's at the top of your file.

 

 

- NUSIZ1 is a nice start, but it's not necessary. According to the docs, you can use missile1, the ball, and both sprites together WITH no_blank_lines AND pfcolors both set. I was presuming you were using the ball for the shot, but the missile works just as well. So if you're using the missile for firepower, split the rock between the sprite and the ball. This will allow you to send each of them spinning off in a diagonal direction. The one caveat is getting the ball to be the right color. Normally it takes on the color of the playfield, which is bad if you have a pfcolors background. However, if you set the options "PFcolors no_blank_lines background", the pfcolors should be applied to the background instead of the playfield. (I've never tried this, so caveat emptor.)