Breakout-Based Non-Infringing Video Game

[Luigi301]

I gave up on my 5200 game. Instead, I'm starting work on a Breakout-style game! So far I have a bottomless rectangle that turns gray when you hit the black-and-white switch!

 

I do have a way to store level data. If it works right, the level data itself should be small enough for me to include a lot of levels! Of course this is me we're talking about, so it could be completely wrong...

Edited July 31, 2005 by Luigi301

[Luigi301]

And now I have a paddle. Bricks are needed.

[potatohead]

And now I have a paddle. Bricks are needed.

900637[/snapback]

 

 

Are you reading the paddle, or just using a joystick for now?

 

(Wondering because I'm thinking about a paddle option for my game.)

[+batari]

And now I have a paddle. Bricks are needed.

900637[/snapback]

Are you reading the paddle, or just using a joystick for now?

 

(Wondering because I'm thinking about a paddle option for my game.)

900686[/snapback]

bB doesn't support paddles at this time because it requires kernel cycles.

 

If there is interest in paddle support, however, I can make alternative kernels for them easily enough, but you will need to sacrifice one of the objects, like a missile or a ball or something.

[potatohead]

And now I have a paddle. Bricks are needed.

900637[/snapback]

Are you reading the paddle, or just using a joystick for now?

 

(Wondering because I'm thinking about a paddle option for my game.)

900686[/snapback]

bB doesn't support paddles at this time because it requires kernel cycles.

 

If there is interest in paddle support, however, I can make alternative kernels for them easily enough, but you will need to sacrifice one of the objects, like a missile or a ball or something.

900722[/snapback]

 

That would be a nice option, but I would rather have the objects right now over the paddle. I suppose one could use a trakball, if non-linear movement was needed.

[maibock]

How about a game called "Break-In" ?

 

Would be a mix between breakout, warlords, zoo keeper, and perhaps pong..

 

the bricks would be set up like zoo keeper - bricks in the center of the screen with an opening in the very middle.

 

4 players would control one paddle along the 4 sides of the screen

 

You gain points when after YOU hit the ball and the ball hits the bricks. You lose a point(s) when the ball gets past you.

 

variants:

 

- perhaps have something in the very center that gives you more points when hit

- you can "catch" the ball with your paddle

- you can control the ball

[Luigi301]

I'm reading the joystick for now until paddle support is included. I wouldn't mind sacrificing a missile for paddle support.

 

Break-In sounds like a really great idea, but I don't think I have the programming knowledge to do something like that. Besides, Batari only supports 2 players

[maibock]

ah no problem - just some ideas I had with breakout

 

good luck with your game!

[Luigi301]

How many bit reads can I make in one draw cycle before it desyncs the screen? I've got a great idea for storing levels but I need to know if it's practical.

Edited July 29, 2005 by Luigi301

[Luigi301]

if a(0)=1 then pfpixel 1 1 on

 

causes DASM to error saying "cannot parse line =". What am I doing wrong?

[s0c7]

if a(0)=1 then pfpixel 1 1 on

 

causes DASM to error saying "cannot parse line =". What am I doing wrong?

900889[/snapback]

 

Usually when that happens to me it means I have whitespace at the end of the line. If you have a space after the on, get rid of it.

Edited July 29, 2005 by s0c7

[Luigi301]

It doesn't error if I turn the a(0)=1 into a=1, but if I use a whole variable my levels will never fit. The guide says I can use a(n)=x where n is bit 0-7 to check the value, but it doesn't seem to be working.

Edited July 29, 2005 by Luigi301

[Luigi301]

I can't get bit accesses to work. Here's my code, can anyone see a problem? The exact error is "cannot parse line =".

 

1 y = 80
2 z = 70
5 COLUPF = x : scorecolor = 10 : COLUP0 = 120
6 x = 90
8 if switchbw then x = 10
11 PF0=128
12 pfhline 0 0 31 on
15 player0:
 %00000000
 %00000000
 %00000000
 %00000000
 %11111111
 %11111111
 %11111111
 %11111111
end

20 player0x = z
22 player0y = y
25 if joy0left then z = z - 1
26 if joy0right then z = z + 1
30 if z > 151 then z = 151
35 if z < 31 then z = 31
50 if d = 0 then gosub screen1
70 drawscreen
75 goto 5

screen1
 a = %11111111
 gosub makescreen

makescreen
 if a(0)=1 then pfpixel 1 1 on
 d = 1
 goto 70

gameover
 goto 5

Edited July 29, 2005 by Luigi301

[vdub_bobby]

I can't get bit accesses to work. Here's my code, can anyone see a problem? The exact error is "cannot parse line =".

I dunno; possible bug?

 

But in any case, you are going to want to "return" from those gosubs...

[Luigi301]

Ah, found my error. You don't use a(n)=0, you use a(n) or !a(n). And they're reversed except for bits 6 and 7!?

 

Anyone know how many pfpixel commands will fit in one draw cycle? I've got a terribly inefficient but slightly ingenius method for storing levels and drawing them on the screen.

Edited July 29, 2005 by Luigi301

[Luigi301]

Since Batari Basic doesn't do balls yet, I've been working on the engine.

 

Some details:

 

Each row is 11 bricks long and stored in a whopping one byte (!) of data, meaning I can have a LOT of screens if I do this right! I haven't hit the wall yet on pfhline commands, so I don't know how many rows a screen can have maximum, but I haven't tested more than four at once. Control will be done using the paddle when Batari Basic supports it. Screens are called randomly up except for the first screen, which is always the following screen. 44 pfhline commands to draw a screen!

 

Also, a question for the gurus: How do I tell how much ROM space I have left to work with?

Edited July 29, 2005 by Luigi301

[+batari]

Since Batari Basic doesn't do balls yet, I've been working on the engine.

 

Some details:

 

Each row is 11 bricks long and stored in a whopping one byte (!) of data, meaning I can have a LOT of screens if I do this right! I haven't hit the wall yet on pfhline commands, so I don't know how many rows a screen can have maximum, but I haven't tested more than four at once. Control will be done using the paddle when Batari Basic supports it. Screens are called randomly up except for the first screen, which is always the following screen. 44 pfhline commands to draw a screen!

 

Also, a question for the gurus: How do I tell how much ROM space I have left to work with?

901105[/snapback]

The compiler should tell you, if you're using 0.2. If you're using the IDE, however, I think that it might close the DOS window so fast that you can't see the message.

[Luigi301]

Sweet, I've got 2100 bytes left. Meaning that at 4 bytes per screen, I can fit... 500 or so screens.

[Luigi301]

Now it turns various shades of gray when you turn the black-and-white switch, and the paddle doubles in size when you hit the left difficulty switch!

breakout.bin

[Luigi301]

Another screenshot featuring a different level.

[Luigi301]

Symmetric playfields? We don't need no steenkeeng symmetric playfields!

[Luigi301]

I just had a GREAT idea. Breakout's been done. It's been done so many times it makes you want to barf.

 

But what about this?

 

2 paddles, one on top, one on bottom, bricks in the middle. The object of the game is to break through the wall and make the ball go past your opponent's paddle. The ball starts in the middle somewhere and breaks itself out, making a hole in the wall with it, meaning two games are never the same! Now THAT sounds like a good game! Any opinions? Can I do it in Batari?

Edited July 30, 2005 by Luigi301

[Jess Ragan]

There was this type-in game in an old computer magazine... it was either Family Computing or Compute!, but that's not important. Anyway, it was called Hit or Miss, and it took a fresh new approach to the game of Breakout, putting the player in the MIDDLE of the screen and the blocks on either end.

 

The hook was that the drain zone randomly switched sides, from the top of the screen to the bottom and back... the object was to keep the ball in play for as long as possible, bouncing it against the safe end of the screen while keeping it away from the opposite end.

 

Hit or Miss was a fairly original game for a Breakout clone. Perhaps you could try making a version of that for the 2600?

 

JR

[Luigi301]

2-player engine set up! Once Batari does balls I can add collision detection and a ball, too! I found another bug: joy1left and joy1right are not recognized by DASM!

[+batari]

2-player engine set up! Once Batari does balls I can add collision detection and a ball, too! I found another bug: joy1left and joy1right are not recognized by DASM!

901602[/snapback]

You can use one of the missiles for your bouncing ball for now.

Edited July 31, 2005 by batari