For whom it may concern

Just noticed your blog entry! I'm so happy that you're working on this project again! The game is extremely addictive!

Level 10.

Level 10.

What's your strategy?

Level 10.

What's your strategy?

I don't know. After reaching level 9, I then played about 10 games in a row where I couldn't get past level 2.

 

I try to get them to shoot each other when the opportunity arises, but mostly I just run around trying not to get trapped, waiting for one of them to get separated from the others, then I pick him off.

 

The weird thing is that if the only thing that changes from level to level is the relative speed of the tanks, then why do they seem to behave differently on the different levels? Level 1 I start off going straight down and the tanks 99% of the time make the same 3-4 opening turns. I've never seen all of them make those same opening turns on any other levels that use board 1, though I think I start all of the the same way. ??

I got to level 8 after a whole bunch of dying around level 3-4. Maybe it'd be best if the game started at maybe level 3 speeds, if you think it's too easy? You don't want to put off the first-time players though, where you're going to be getting many potential votes from

 

I wonder if you're occasionally generating an extra scanline or something - very occasionally I notice the screen sort of jump while playing a level (like, once every couple minutes). Though it could just be a problem with my monitor or something...

I try to get them to shoot each other when the opportunity arises, but mostly I just run around trying not to get trapped, waiting for one of them to get separated from the others, then I pick him off.

I see. So making the relative speed change, should give you some extra challenge.

 

The weird thing is that if the only thing that changes from level to level is the relative speed of the tanks, then why do they seem to behave differently on the different levels? Level 1 I start off going straight down and the tanks 99% of the time make the same 3-4 opening turns. I've never seen all of them make those same opening turns on any other levels that use board 1, though I think I start all of the the same way. ??

That's due to the non-random initialization (saves some bytes). Therefore the 1st level always starts the same. But when you move around, things become random soon and remain random for the rest of the game.

 

That's because there is only one randomness in the whole game, which is inside the iBots AI code. They'll always try to go into your direction. But when this is not possible, they will choose a random direction. Depending on your position, the random number generator gets called more or less often.

 

At the start of the 1st city you are always at the top right of each iBot, so the behavior is always the same. But as soon as you vertically or horizontally cross an iBot's position the randomness starts.

I got to level 8 after a whole bunch of dying around level 3-4. Maybe it'd be best if the game started at maybe level 3 speeds, if you think it's too easy? You don't want to put off the first-time players though, where you're going to be getting many potential votes from

Wait for the new version I'll post tomorrow. It will start as easy as now, but you will notice that it becomes more difficult soon. I just have to find a good balance here.

 

I wonder if you're occasionally generating an extra scanline or something - very occasionally I notice the screen sort of jump while playing a level (like, once every couple minutes). Though it could just be a problem with my monitor or something...

I'll check this. Thanks!

That's due to the non-random initialization...

Ah, that makes sense, thanks.

 

Very fun, and very addictive. It gets very hard, but when I die I have always felt that I could have avoided death and gotten just a little further.

 

EDIT: Level 12. Died too fast to see any bugs.

... but now I have some more experiences in compact coding

 

I wouldn't have thought that this was possible for you, the master code bummer.

You never ever stop learning, so you can always improve.

 

BTW: I just found another 4 bytes.

If you need another byte, I found one. BTW: nice code - I like the use of opcode $82 for a 2-cycle byte skip.

 

Anyway, using sbx, you can replace the two instructions I commented out below. A is different after the code executes, which changes the first store to ptrP1, but it appears that it's overwritten before it's used so it shouldn't matter. Maybe you can save more since you don't have to worry about the carry, but I couldn't figure out how.

.loopX:
clc
.loopSwap:
ldy	 swapLst-1-NUM_OBJECTS,x
lda	 swapLst-1-NUM_OBJECTS+2,x
sta	 swapLst-1-NUM_OBJECTS,x
sty	 swapLst-1-NUM_OBJECTS+2,x
dex
bcs	 .loopX
txa
sbx	 #NUM_OBJECTS
;	sbc	 #NUM_OBJECTS-1
;	tax
bne	 .loopSwap
; setup colors and tank pointers:
inx						;			   X=1!
.loopCopy:
sta	 ptrP1			  ;			   set 2nd pointer after 1st loop
lda	 colorTankLst+2,x
sta	 COLUP0,x
ldy	 dirTankLst+2,x
lda	 TankPtrTbl,y
sbc	 yPosP0,x
dex
bpl	 .loopCopy

Anyway, using sbx, you can replace the two instructions I commented out below.

Works! Thanks, I most likely wouldn't have thought about this, because I never had used SBX before.

 

(I just had replaced all illegal NOPs with BIT... )

You never ever stop learning, so you can always improve.

 

BTW: I just found another 4 bytes.

Indeed. It hadn't occured to me that you could use ASL on a read-only address, as in ASL INPT4. It takes as many bytes as LDA INPT4, but there may be times when it is advantageous.

 

What does Fred mean by using $82 as a byte skip? Does it affect the PC or something?

Indeed. It hadn't occured to me that you could use ASL on a read-only address, as in ASL INPT4. It takes as many bytes as LDA INPT4, but there may be times when it is advantageous.

I use it several times now. Very useful in e.g. ASL CX...,x to test bit 6. Just make sure that the TIA base read address is $30.

 

What does Fred mean by using $82 as a byte skip? Does it effect the PC or something?

It's working like using e.g. BIT to skip the next one or two bytes. $82 has two advantages over $24 as it doesn't change the flags and requires only two cycles.

 

Though I recently realized that I don't need those advantages in my Robot City code at all.

I have just added the first beta version (PAL-50 and -60 versions too). It now includes SFX and some gameplay polishing. Most noticable are the change of the difficulty increase as described above and the different color order (see new manual for details). I hope the occasional glitch Nathan noticed is gone now too (not 100% sure).

 

1 Byte free!

 

Please, could some native English speaker also have a look at the manual and correct my errors? Thanks!

I like the sound effects!

It's coming along very well. I like the sound effects and level progression. There is one thing I'm confused about, though. I read somewhere that a game thought to be a prototype of Robot City actually turned out to be a Jopac game named Laser.

There is one thing I'm confused about, though. I read somewhere that a game thought to be a prototype of Robot City actually turned out to be a Jopac game named Laser.

AFAIK it is exactly the other way around.

Indeed. It hadn't occured to me that you could use ASL on a read-only address, as in ASL INPT4. It takes as many bytes as LDA INPT4, but there may be times when it is advantageous.

I use it several times now. Very useful in e.g. ASL CX...,x to test bit 6. Just make sure that the TIA base read address is $30.

Interesting method - but I wonder what advantages it has over BIT and BVS/BVC for testing bit 6?

Interesting method - but I wonder what advantages it has over BIT and BVS/BVC for testing bit 6?

Adressing modes!

That SFX is eating up my bytes! I started with 77 bytes free and now I am down to 36 bytes with only about 50% of the sounds done. My former three minigames had much less different actions happing, therefore requireing only a few (not more than 3) different sounds. But Robot City is very different.

 

Well, you might want nicer sounds than SDI, but SDI's sound code was very compact.

 

My init routine set AUDC0 and AUDC1 to 8 (I had the value in a register for some other purpose, so 4 bytes of code). It also set AUDF0 and AUDF1 to suitable values (again using stuff in registers; another four bytes). In my main loop:

 lsr vol0
 lda vol0
 sta AUDV0
 lsr vol1
 lda vol1
 sta AUDV1

Twelve bytes. To generate noises, I set vol0 or vol1 to suitable values (again, using what was handy in registers). For the end-of-game explosion, I think I did a DEC AUDF1 and then stored something in vol1. So probably about ten bytes there.

 

So 4+4+12+10 bytes--30 total--for all my sound effects.

Interesting method - but I wonder what advantages it has over BIT and BVS/BVC for testing bit 6?

Adressing modes!

*Looks it up

 

You're right, there's no BIT ZP,x

Supercat had some cool "dot" solution going for his missile command 1K entry last year.

 

I don't have my code handy, but it was something like:

  lda levelnumber
 sta temp
lp:
 lda temp
 lsr
 lsr
 adc temp
 ldy #0
 jsr putpixel
 dec temp
 bpl lp

 

Worked nicely since I already had a putpixel routine available. Not quite so useful for more typical 2600 game designs.

 

Depending upon how many levels people could get through in Robot City, I'd suggest that a display of vertically-stacked dots might be the way to go. Something like this:

 lda levelnumber
lp:
 tax
 sbx #5
 ldy #$3E
 bcs ok1
 ldy dot_table-256+5,x
ok1:
 sta WSYNC
 sty GRP0
 sta WSYNC
 ldy #0
 sty GRP0
 bcs lp
 ..
dot_table: byte $00,$08,$14,$2A,$55

I think that's 27 bytes total for a level display, plus whatever you need to spend to set the sprite position and color. You should get a big bar for every five levels, and a dot for each level thereafter.

You're right, there's no BIT ZP,x

 

I wonder why BIT was implemented as an "oddball" instruction with just two addressing modes? BIT #immed would have been so handy sometimes...

You're right, there's no BIT ZP,x

 

I wonder why BIT was implemented as an "oddball" instruction with just two addressing modes? BIT #immed would have been so handy sometimes...

The 65C02 has BIT #immed and x-indexed modes as well.

 

As for the NMOS chips, there are empty spots ($34 and $3C) where logically, BIT addr,x should have gone, possibly with little extra design effort. This is where they live on the CMOS chips.

Depending upon how many levels people could get through in Robot City, I'd suggest that a display of vertically-stacked dots might be the way to go.

Vertically won't work here (anymore). The game is now functional up to level 22 (though getting extremely tough by then), so a vertical display would require too much space (even when only adding a dot every 2nd level). And I have run out of bytes anyway. (2 bytes free)

Vertically won't work here (anymore). The game is now functional up to level 22 (though getting extremely tough by then), so a vertical display would require too much space (even when only adding a dot every 2nd level). And I have run out of bytes anyway. (2 bytes free)

 

Well, my approach would have been two scan lines per five levels. Though if you don't have space, I guess you don't have space. How did you like my approach to sound for SDI? Did I go too crazy in trying to squoosh things?