Arkanoid clone feeler...all comments welcome.

[vdub_bobby]

Another question for you Arkanoid experts: on average, how many bricks do you have to break to get a powerup pill to fall? Is this constant, or do they become rarer the further into the game you go?

[PacManPlus]

Hey!

 

It's pre-set which bricks will drop a pill and which do not.

 

I have included here a nifty little Windows program called 'Arkedit' by Jim Stolis which lets you edit levels. Choose Load and select the only '.uc' file in the current directory. The bricks with the 'P' on them are the ones that drop a pill, the others do not.

 

BTW I actually haven't had a chance to play it yet to give to an accurate set of ball speeds. I will do that this weekend.

 

Bob

 

P.S. - You will see that I already have edited the 1st three levels

ARKEDIT.ZIP

Edited July 15, 2005 by PacManPlus

[vdub_bobby]

Hey!

 

It's pre-set which bricks will drop a pill and which do not.

Hmmmm...interesting. I assume the pill to be dropped is randomly chosen, though?

 

And thanks for the editor.

 

EDIT:

After playing with the editor a bit, found out some interesting stuff:

 

Arcade brick area is 13 bricks wide by 18 bricks tall. The brick area in my 2600 demo is 16 wide by 15 tall, plus two blank rows on top.

 

But only 1 of the arcade levels uses the top two rows (level 10), so with what I've got so far I can probably reproduce almost exactly each of the 32 arcade (US) levels.

 

Which is good news.

 

EDIT II:

On the other hand, I still haven't figured out a good way to have bricks that take more than one hit to break. Every way I've thought up takes too much RAM...

Edited July 15, 2005 by vdub_bobby

[Albert]

Ooooooo, an Arkanoid level editor. Might be fun to have a contest where people can submit levels they create. We'd need some way to generate a binary based on the output of the level editor so people could test their creations before submitting them. If this editor is not feasible for such a cause, a simple editor suited for this purpose could probably be written...

 

Am I getting ahead of myself?

 

..Al

[vdub_bobby]

Ooooooo, an Arkanoid level editor.  Might be fun to have a contest where people can submit levels they create.  We'd need some way to generate a binary based on the output of the level editor so people could test their creations before submitting them.  If this editor is not feasible for such a cause, a simple editor suited for this purpose could probably be written...

 

Am I getting ahead of myself?

Yeah, probably - - though I admit that when I first started thinking of porting Arkanoid I had the exact same thought.

[PacManPlus]

BTW here is the 'unmodified' arknoidj.uc file so you can see the real first three levels

 

Yes, the pills are random, although some have more weight than the others - the 'D' pills seem to come out much more frequently, and I read somewhere that there are two versions: one with more frequent 'D' pills, and one that is more evenly distributed.

ARKNOIDJ.ZIP

[PacManPlus]

As far as getting the bricks to break on multiple hits, is there a way you can check the color of the brick at the point of collision? Make the color slightly lighter (by subtracting #$01 from it) each time, and if the color is below a value it's done? - Only the grey bricks work this way so at least you have that on your side...

 

The ones that take three hits will hardly notice a change, but the bricks that take 5 hits you can start at a darker value

Edited July 15, 2005 by PacManPlus

[+batari]

Sometimes, working on a game is like working on my VW bug:

891140[/snapback]

Interesting analogy. Though it's hard for me to draw a parallel between Atari 2600 assembly programming and changing the oil or gapping spark plugs. I would say that Atari 2600 assembly programming is the mechanical equivalent of rebuilding an automatic transmission that someone else took apart and threw all the pieces in a box.

891879[/snapback]

Well, when I said "adjust gaps," I meant adjusting the valves, which is a little more complicated (but not much) than gapping the spark plugs.

 

But assembly isn't that complicated...

 

891894[/snapback]

Ok, Valves are a little harder. And 6502 assembly isn't that bad, I've been programming in 6502 off and on since 1980. It's just assembly with all the timing quirks on the 2600 that's tough for me. After months of struggling with kernels, I'm now able to write one without WSYNCs, but I still have trouble squeezing out every last cycle, e.g. I had no idea how I was going to get the ball into the Batari Basic kernel until you did it for me!

[PacManPlus]

OK, aside from my 'multiple hit brick' suggestion above (let me know if that's doable) Here's what I found out about the speed of the ball (I'm pretty sure about this)

 

There actually seem to be 6 or 7 speeds (at least 6 I'm sure of) - The first two slow speeds are only obtainable by catching a few 'S' pills in succession. The boards never start out at the first two speeds:

 

1) Super Slow - the ball is actually slower than the speed of the pills dropping. I'm talking boring slow

2) Slow - the ball speed is the same speed as the dropping pills.

3) Normal - This is usually the speed of the ball at the beginning of the board.

4) Faster

5) Very Fast

6) Super Fast - This is insanely fast difficult to keep up with

 

Please note that just because the ball hits the top of the screen doesn't always mean the ball speeds up. It seems to be more of how many collisions the ball makes. I haven't counted each yet - I neder paid much attention to that back when I played this game a lot because I actually liked having the ball very fast...

 

Hope this helps!

Bob

[vdub_bobby]

OK, aside from my 'multiple hit brick' suggestion above (let me know if that's doable)

I don't think I can get multiple-hit bricks in at all, due to RAM limitations. How important is this? Can people live with two kinds of bricks (breakable/unbreakable) or not?

 

And changing the color of individual bricks is also pretty dicey - the only way possible would be with either some kind of crazy color flicker (i.e., I would have to borrow some of Davie's genius; is he loaning it out?) or with some kind of striping, like supercat suggested above. And that would also probably be too RAM intensive.

 

Here's what I found out about the speed of the ball (I'm pretty sure about this)

 

There actually seem to be 6 or 7 speeds (at least 6 I'm sure of) - The first two slow speeds are only obtainable by catching a few 'S' pills in succession.  The boards never start out at the first two speeds:

 

1) Super Slow - the ball is actually slower than the speed of the pills dropping.  I'm talking boring slow

2) Slow - the ball speed is the same speed as the dropping pills.

3) Normal - This is usually the speed of the ball at the beginning of the board.

4) Faster

5) Very Fast

6) Super Fast - This is insanely fast difficult to keep up with

 

Please note that just because the ball hits the top of the screen doesn't always mean the ball speeds up.  It seems to be more of how many collisions the ball makes.  I haven't counted each yet - I neder paid much attention to that back when I played this game a lot because I actually liked having the ball very fast...

 

Hope this helps!

Bob

892742[/snapback]

Thanks for this info; it helps indeed!

[PacManPlus]

IMHO I don't see it being a huge issue not having the multi-hit bricks, but it might make levels 11, 23 and 27 much easier!

[supercat]

I don't think I can get multiple-hit bricks in at all, due to RAM limitations.  How important is this?  Can people live with two kinds of bricks (breakable/unbreakable) or not?

 

You could probably get three kinds (hit once, unbreakable, hit-twice) without using significant extra RAM if you had two tables of data in ROM for each level and copied one to RAM. Use the following truth table:

RAM/ROM
00 -- No brick
01 -- Unbreakable brick
10 -- Hit-once brick
11 -- Hit-twice brick

Using color striping, the RAM bits would show in color on half the scan lines; the ROM bits would show in color on the other. If you didn't feel a need to copy the arcade layouts, you could save CPU time if you made the board layouts symmetrical. Although the RAM bits would not remain symmetrical, the ROM bits would. Thus you'd have a few cycles left to implement a 2LK.

 

And changing the color of individual bricks is also pretty dicey - the only way possible would be with either some kind of crazy color flicker (i.e., I would have to borrow some of Davie's genius; is he loaning it out?) or with some kind of striping, like supercat suggested above.  And that would also probably be too RAM intensive.

 

If you color the bricks as described, it should not be particularly RAM hungry.

[vdub_bobby]

You could probably get three kinds (hit once, unbreakable, hit-twice) without using significant extra RAM if you had two tables of data in ROM for each level and copied one to RAM.  Use the following truth table:

RAM/ROM
00 -- No brick
01 -- Unbreakable brick
10 -- Hit-once brick
11 -- Hit-twice brick

Using color striping, the RAM bits would show in color on half the scan lines; the ROM bits would show in color on the other.  If you didn't feel a need to copy the arcade layouts, you could save CPU time if you made the board layouts symmetrical.  Although the RAM bits would not remain symmetrical, the ROM bits would.  Thus you'd have a few cycles left to implement a 2LK.

The problem is that I need 60 bytes in RAM for the PF data that is displayed and if I have multi-hit bricks then I need at least another 30 bytes in RAM to keep track of which multi-bricks have been hit once already. I can't code the rest of the game with just the leftover 38 bytes of RAM; I'm not that clever.

If I reduced the number of bricks it might be possible (if I reduce the rows to 10 then I use 40 bytes for PF display RAM and 20 bytes for multi-hit tracking, which would cost the same RAM as now) - so it's a possibility.

[Brad2600]

If I may ask, could somebody kindly post a screenshot? I'm curious as to what this looks like.

[Gateway]

Here's two screengrabs from z26.

 

There are two borders and two Invaders. Currently, Only one Invader and one border are visible because of flicker.

[PacManPlus]

Some more technical game stuff: from History.Dat in MAME:

 

- TIPS AND TRICKS -

 

 

* Hint 1 : The power pills are not quite random. There are essentially two types of games. One has lots of light blue multi-ball pills and the pink warp pills - this is a low scoring game. The high scoring game gives you more of the other pills.

 

 

* Hint 2 : On each level, the ball will not speed up completely until it hits the back wall, so :

 

1) Try to remove bricks from the bottom up, or punch a hole through thicker areas of bricks rather than go straight through (e.g. take out the left side of level 2 rather than the single block at the right as you will catch far more pills).

 

2) If you have collected a lot of S pills and the ball has been in play for a bit of time, be prepared for a sudden speedup.

 

 

* Hint 3 : Also, the D token speeds up the balls and is pretty useless on most levels (the one with the enclosed diamond is the only good example I can think of).

 

 

* Hint 4 : As only one pill can fall at a time, multiple balls can reduce your potential score quite drastically. Every pill is worth 1000 points. For the first few levels, get every pill you can, but do not use the special powers. You will get a lot of extra ships and should get a gray P (extra vaus) or two - thereby starting early with 6 or 7 ships.

 

 

* Hint 5 : In the mask end game, you should get 15 hits (1000pts per hit) on the mask/per man until you eliminate the mask with the 16th hit on your last man to end the game.

[supercat]

The problem is that I need 60 bytes in RAM for the PF data that is displayed and if I have multi-hit bricks then I need at least another 30 bytes in RAM to keep track of which multi-bricks have been hit once already.  I can't code the rest of the game with just the leftover 38 bytes of RAM; I'm not that clever.  

893607[/snapback]

 

I'd forgotten for some reason that if you have 1 bit per block stored in ROM, you can't change it during the game. Maybe I'm too used to the Supercharger (where all the code is in RAM).

 

Still, you might be able to do okay if you don't mind sprawling out your kernel a little bit, using an extra few bytes of RAM, and possibly adding two no-bricks scan lines between the rows of bricks. The key is to observe that right now you're using two bits of RAM per brick (because each brick is two lores pixels wide). What you need to do is pack one bit from each of eight bricks into each byte. Then you can use something like:

 ldy bricks1,x
 lda translate1,y
 sta PF1
 lda translate2,y
 sta PF2
 lda bricks2,x
 lda translate1,y
 sta PF2 ; Be sure to time this one right
 lda translate1,y
 sta PF1

Unfortunately, doing the translations like that probably takes a little more time than you've really got available (since you also want to display other things as well). Thus, I would expect you'd probably have to make some clever use of temp variables in a sprawling kernel design (which would probably not be a problem in an 8K or 16K cart, but might not be possible in a 4K cart).

[vdub_bobby]

That's an interesting idea. Might be doable - probably have to stripe the bricks.

[supercat]

That's an interesting idea.  Might be doable - probably have to stripe the bricks.

896419[/snapback]

 

Another thought: if having a two-hit brick flicker is desirable, what about declaring that a brick whose pixels are both set is a one-hit brick (unless it's unbreakable), but a brick only one of whose pixels is set is a two-hit brick. Then use a 256-byte translation table once per frame on all the bricks to switch any left-pixel-only bricks to right-pixel-only bricks.

[djmips]

I don't think I can get multiple-hit bricks in at all, due to RAM limitations.  How important is this?  Can people live with two kinds of bricks (breakable/unbreakable) or not?

 

I love the multi-hit bricks with less compromises. How about just using more RAM? Superchip get's you an extra 128 bytes.

 

Some of the classic games used Superchip: DIG-DUG, Defender II, Jr. Pac-Man. So you'd still be very 'classic' if you used it and all of the emulators + Cuttle Cart support it. If you want to put this in a cart, there's enough know-how here to create and start making modern Superchip carts.

 

From SIZES.TXT

 

Atari's 'Super Chip' is nothing more than a 128-byte RAM chip that maps

itsself in the first 256 bytes of cart memory.  (1000-10FFh) 

The first 128 bytes is the write port, while the second 128 bytes is the

read port.  This is needed, because there is no R/W line to the cart.

[supercat]

If you want to put this in a cart, there's enough know-how here to create and start making modern Superchip carts.

 

And do you know where to find one for less than $15? I'm currently working on one (32K RAM + 64K flash + a new bankswitching method to aid hi-res graphics) but it's not done yet.

[Thomas Jentzsch]

And do you know where to find one for less than $15?

Couldn't you just canibalize common SC games (e.g. Dig Dug)?

[Cybergoth]

Hi there!

 

Couldn't you just canibalize common SC games (e.g. Dig Dug)?

 

CANIBALIZING DIG DUG? SACRILEGE! It's one of the best games ever for the 2600! Don't you dare touching 'em!

 

How about re-canibalizing those crappy Elevator Action protoype release cartridges instead, for which some criminals already destroyed Dig Dugs before?

 

Greetings,

Manuel

[djmips]

And do you know where to find one for less than $15?

Couldn't you just canibalize common SC games (e.g. Dig Dug)?

898008[/snapback]

 

so... I ripped open one of my DIG DUG cartridges (sorry Manuel, heh I'll put it back together) and did a bit of internet sleuthing.

 

I looked at the superchip boards up on atariprotos.com to get an idea of what a board with eproms would look like.

 

Crystal Castles Prototype from atariprotos.com

 

And here I've photographed my dig dug PCB.

 

 

Note that the Dig Dug game has two IC's and one of the IC's is marked in a similar way (IMP) to the SuperChip on the prototype.

 

Edited to add the following:

 

I also dug through the Stella Archives and it turns out that one Russell Babylon created a custom downloader that supported the SuperChip simply by incorporating the chip from a cartridge.

 

SuperChip cart

Edited July 25, 2005 by djmips

[Jess Ragan]

NOOOOOO!!! (dives on top of Crystal Castles to protect it)

 

That was one of MY favorite 2600 games! Ruining a copy of Crystal Castles, even with the best of intentions, is akin to defacing a national monument, or drawing a mustache on the Mona Lisa!

 

Er, anyway. Nice goin' with the Arkanoid clone there, Bob. It's already showing more promise than Off The Wall, the quirky Breakout clone released late in the life of the 2600. Never did figure out what was going on with that one... the gameplay elements never really felt solid, almost as if Nolan and crew were desperately trying to find ways to distance it from its obvious inspiration, Arkanoid.

 

JR