Zach's Projects

Clever thinking! I like this idea but this does make the game harder to learn/play, since you are forcing the players to memorize all the pieces right from the get-go, since there is no color-cue as to which piece is which.

Clever thinking!  I like this idea but this does make the game harder to learn/play, since you are forcing the players to memorize all the pieces right from the get-go, since there is no color-cue as to which piece is which.

Thanks Bob. The pieces I've drawn so far are:

 

Top Row

• Valkyrie (spear)
  
• Golem
  
• Unicorn
  
• Djinni
  
• Wizard (wand)
  
• Phoenix
  

Bottom Row

• Archer (bow)
  
• Knight (sword)
  

As for learning the pieces, the original game names all of them at setup, and identifies each piece as the cursor moves over them. I had forgotten about this until I looked at some screenshots over here. Of course the 48 pixel sprite will come in handy here.

 

(It is well known that the Phoenix is a legendary bird that ignites itself and is reborn from the ashes, but few people realize that the bird is in fact a duck. Just kidding, I admit the sprites could use some improvement.)

I've just formulated an Archon kernel which requires extra RAM (actually quite a bit of it) but accommodates either 8x12 characters (with Venetian-blinds flickering) or 8x6 (blinds only, no flicker). I posted a demo in the Homebrew forum; if anyone wants to give me some sprite shapes in the proper dimensions I could put them in. The board is set up with black on the bottom and white on the top.

Yeah, I've been looking at supercat's kernel, and it's very close to the original design. The advantage of higher resolution sprites and recreating the original appearance outweighs the disadvantage of flickering.

 

@supercat, you can get screenshots from the link above, That'll give you the sprite data.

Yeah, I've been looking at supercat's kernel, and it's very close to the original design. The advantage of higher resolution sprites and recreating the original appearance outweighs the disadvantage of flickering.

 

@supercat, you can get screenshots from the link above, That'll give you the sprite data.

 

I'm not enough of an artist to render all those things in 8x12 and 8x6 resolution (it would probably be best to allow players to select lores or flicker mode).

I'm not enough of an artist to render all those things in 8x12 and 8x6 resolution (it would probably be best to allow players to select lores or flicker mode).

 

Can you extend your sprites to 8x14? That is the size of the characters in the C64 screenshots. For smaller sprites, I agree that it would take an artist.

Can you extend your sprites to 8x14? That is the size of the characters in the C64 screenshots. For smaller sprites, I agree that it would take an artist.

 

Sure. I updated the sprites to borrow the original graphics. The original game had light/dark at the left and right sides of the board rather than top and bottom, though, so the sprites should still be redone. But this gives proof-of-concept anyway.

Can you extend your sprites to 8x14? That is the size of the characters in the C64 screenshots. For smaller sprites, I agree that it would take an artist.

 

Sure. I updated the sprites to borrow the original graphics. The original game had light/dark at the left and right sides of the board rather than top and bottom, though, so the sprites should still be redone. But this gives proof-of-concept anyway.

 

Again, nice job. If your kernel can handle an asymmetrical playfield, why move the sprites to top and bottom? I might be missing something, but I'm not sure what you would need with extra cycles if you can already display the board?