Robot City revisited

Posted by Thomas Jentzsch, 25 May 2006 · 423 views

Programming Damned Tag Clouds

After "some" time, I recently decided to have another look at Robot City. Since the Minigame Compo deadline for 1K is coming soon, I decided to try again to squeeze the gameplay into 1K. Last time I failed, but now I have some more experiences in compact coding. Still I had to strip down the game massively, but finally I managed to keep the important gameplay elements intact.Attached you find the current version. It is almost complete, except for missing sound and some polishing (especially between level transitions and at game over). I also attached the source code and instructions (maybe someone can check my English). 69 bytes free :)Are the controls ok? Does the game start at a good speed and is the speed progression ok? Do you like the two maps? ... Any feedback is appreciated.

Attached Thumbnails

Attached Files

Robot_City__v1.0_.zip (15.25K)
downloads: 336

Thomas Jentzsch
May 27 2006 1:26 PM

BrianC, on Sat May 27, 2006 9:17 PM, said:

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.

Report

batari
May 27 2006 4:27 PM

Thomas Jentzsch, on Sat May 27, 2006 2:57 AM, said:

Zach, on Sat May 27, 2006 9:40 AM, said:

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?

Report

Thomas Jentzsch
May 27 2006 4:31 PM

batari, on Sun May 28, 2006 12:27 AM, said:

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

Adressing modes!

Report

supercat
May 27 2006 4:44 PM

Thomas Jentzsch, on Fri May 26, 2006 8:54 AM, said:

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.

Report

batari
May 27 2006 4:47 PM

Thomas Jentzsch, on Sat May 27, 2006 5:31 PM, said:

batari, on Sun May 28, 2006 12:27 AM, said:

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

Report

supercat
May 27 2006 4:59 PM

Cybergoth, on Fri May 26, 2006 1:44 AM, said:

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.

Report

supercat
May 27 2006 5:01 PM

batari, on Sat May 27, 2006 5:47 PM, said:

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...

Report

batari
May 27 2006 7:16 PM

supercat, on Sat May 27, 2006 6:01 PM, said:

batari, on Sat May 27, 2006 5:47 PM, said:

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.

Report

Thomas Jentzsch
May 28 2006 12:54 AM

supercat, on Sun May 28, 2006 12:59 AM, said:

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)

Report

supercat
May 28 2006 1:39 PM

Thomas Jentzsch, on Sun May 28, 2006 1:54 AM, said:

(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?

Report

Thomas Jentzsch
May 28 2006 1:54 PM

supercat, on Sun May 28, 2006 9:39 PM, said:

How did you like my approach to sound for SDI? Did I go too crazy in trying to squoosh things?

I am pretty much a visual person, so I must admit, sound is and was always pretty low on my priority list (and is always the last thing I do when programming myself).

Honestly, I can't remember the SFX. But the graphics where pretty impressive.

Report

Zach
May 28 2006 11:18 PM

Thomas Jentzsch, on Sat May 27, 2006 12:22 PM, said:

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

The manual looks good. I found only a couple things that should be changed:

Quote

even after they have been ~~being~~ killed.

Quote

very ~~addicting~~ addictive Odyssey 2 prototype game

Report

Thomas Jentzsch
May 29 2006 2:40 AM

Zach, on Mon May 29, 2006 7:18 AM, said:

The manual looks good. I found only a couple things that should be changed: ...

Thanks a lot!

Now I only need some feedback regarding the changed difficulty progress.

Report

SpiceWare
May 29 2006 8:58 AM

Neat game. Tried it with my Krok Cart and there's a slight roll when it switches to the long corridor map, but not when it switches to the short corridor map.

In Stella, it stops on the following break when switching to the long corridors. It does not stop when switching to the short ones.

breakif {_scan == #263}

Report

Thomas Jentzsch
May 29 2006 11:00 AM

SpiceWare, on Mon May 29, 2006 4:58 PM, said:

Tried it with my Krok Cart and there's a slight roll when it switches to the long corridor map, but not when it switches to the short corridor map.

In Stella, it stops on the following break when switching to the long corridors. It does not stop when switching to the short ones.

I can't repeat this with the latest version (v0.95) The z26 logs show no problems too. Does it always happen?

BTW: How to you enter '{' and '}' inside the debugger with a German keyboard?

Report

SpiceWare
May 29 2006 11:24 AM

Just played a some more. On the first few games it happened when switching to the short corridor map instead. Powered off/on and it didn't occur at all on the next few games. Weird.

might this help?

Quote

german apple keyboard layout brackets were located at ALT-5 and ALT-6 and the braces at ALT-8 and ALT-9.

german windows keyboard, there we have brackets at ALT-8 and ALT-9 and braces at ALT-7 and ALT-0.

Report

Thomas Jentzsch
May 29 2006 11:32 AM

SpiceWare, on Mon May 29, 2006 7:24 PM, said:

Just played a some more. On the first few games it happened when switching to the short corridor map instead. Powered off/on and it didn't occur at all on the next few games. Weird.

My problem is, it always happens when there is only the conditional breakpoint. But when I add another one when jumping to NextMaze it doesn't happen again. Very weird, indeed.

Quote

german windows keyboard, there we have brackets at ALT-8 and ALT-9 and braces at ALT-7 and ALT-0.

Usually they are at ALT_GR (== STRG+ALT) + 7..0. But it seems that neither ALT, ALT_GR nor STRG+ALT allow any input.