Check out this 9x9 Go kernel.

[Zach]

Here it is, the game that gave Atari its name! Right now, the kernel just shows a single board position, and there is no interface. However, it is variable driven, and I can set up any position just by changing 27 numbers.

 

It was not easy to manage 9 positions on a single scanline that could be a black stone, a white stone, or an empty position. In fact, there were many times when I thought the kernel design you see would not be possible.

 

If anyone would like to take on the game logic and AI, let me know. This could be a good homebrew opportunity for someone who knows assembly, but hasn't learned Atari 2600 programming yet. Meanwhile, I'm going to take a break from Go, and shift my attention again to the project I know you all want me to finish.

 

-Zach

go9x9.zip

[Nukey Shay]

9 positions? Archon?

 

Aw....the problem is still the background for that one

[Nukey Shay]

< hates "Go"

[Gateway]

very cool, Zach!

[Thomas Jentzsch]

Clever coding!

[Cybergoth]

Hi there!

 

No clue about Go, but the screen looks very impressive!

 

Greetings,

Manuel

[kisrael]

Not to be a negative nelly, but i've heard that Go AI makes chess look EASY...I don't know if the 9*9 board makes it that much easier, but still, it's going to be quite the challenge.

[Zach]

Weston, Thomas, and Manuel, thanks for the compliments!

 

Kirk, you're absolutely right about Go AI making chess look easy. The good news is that it is somewhat simpler on a 9x9 board. A smaller board means a smaller search tree. Still, the nature of Go makes it difficult to find a good heuristic for evaluating a given board position. With that said, I think it would be feasible to create AI that could challenge beginners. That will work out well for a homebrew because most of us around here, including myself, are new to Go.

[pmpddytim]

Weston, Thomas, and Manuel, thanks for the compliments!

 

Kirk, you're absolutely right about Go AI making chess look easy. The good news is that it is somewhat simpler on a 9x9 board. A smaller board means a smaller search tree. Still, the nature of Go makes it difficult to find a good heuristic for evaluating a given board position. With that said, I think it would be feasible to create AI that could challenge beginners. That will work out well for a homebrew because most of us around here, including myself, are new to Go.

832499[/snapback]

 

Looks cool, I have never played but would love to try it out.

 

I still want a 2600 Mancala game. You should do that next.

 

-Tim

[Bruce Tomlin]

The good news is that it is somewhat simpler on a 9x9 board. A smaller board means a smaller search tree.

Ha! Just counting the score properly at the end of the game (especially without manually removing dead stones, or if there are any unfilled dame points) might be beyond the capabilities of the 2600.

Edited April 13, 2005 by Bruce Tomlin

[128bytes]

Great work! If you print a screenshot with an "atari", I may just have to update my atari avatar with it!

[Zach]

Great work! If you print a screenshot with an "atari", I may just have to update my atari avatar with it!

 

I was wondering if I'd hear from you, 128 bytes! Here's your screenshot.

 

As for Bruce's comments, I know it will be difficult, but I won't say it's impossible without trying. I'll most likely do a simpler board game first. At the moment, I'm interested in Go-Moku, a.k.a Pente.

 

BTW, did I mention there is no flickering in the kernel?

[Lord Thag]

Wow! I have no idea how to write an AI for this, but I'd buy it in a flat second. I just spent a week making a (real) Go board to play on.

 

Another route you could go down would be to, instead of making it a playabe go game, you could make this a go puzzle collection. From a Go player's standpoint, puzzles are MUCH more helpful to increase playing strength, as even GOOD go programs can be beaten by a below-average amateur. They are also quite fun. What I'm saying is to make it a database of positions with a correct solution, and the player would have to determine the best place to play. You could put a ton of them in the cart, and by reversing the colors of the stones and/or rotating the position, quadruple that. Does that make any sense? PM me if you would like any more info.

 

Anyway, just an idea....

[128bytes]

Lord Thag's idea is really good!

[128bytes]

I did update my avatar - thanks, Zach.

[Zach]

I like your idea, Lord Thag! I'll think about it more when I'm ready to work on Go again.

[supercat]

It was not easy to manage 9 positions on a single scanline that could be a black stone, a white stone, or an empty position. In fact, there were many times when I thought the kernel design you see would not be possible.

827947[/snapback]

 

Cute. I don't quite understand how it works, though playing around with the disables on Z26 it seems you're using ten sprites for 'masking' purposes (clever) and you're using the Ball to fill in the middle part of the playfield (so you don't have to do 2x/line updates between rows). Not sure how you're going to handle alternating black and white stones in the first five columns and none in the rest, though.

 

BTW, with regard to the go puzzle idea, I think it sounds cool if you can find a non-copyrighted source of puzzles. Each puzzle would take 17 bytes in a fixed-size format if you packed things optimally and simply stored the board and the solution, so you could fit about 60 puzzles per kbyte. To add interest, you might allow a variable number of additional bytes per board which would give an 'if-then' of proposed solutions and results. So if someone selects a wrong move which was anticipated by the puzzle creator, the program could illustrate what would happen if that move was played (and thus why it's a wrong move). This would require an engine that could understand the rules, but no AI.

[Zach]

Cute.  I don't quite understand how it works, though playing around with the disables on Z26 it seems you're using ten sprites for 'masking' purposes (clever) and you're using the Ball to fill in the middle part of the playfield (so you don't have to do 2x/line updates between rows).  Not sure how you're going to handle alternating black and white stones in the first five columns and none in the rest, though.

 

You are right about the use of sprites and balls. It is a complicated kernel, but here's how it works briefly. The stones and grid are drawn in the playfield, and the corners of the stones are masked by sprites and missiles. There are three different routines to draw the go board:

 

a) The scanlines between stones

b) The scanlines where a horizontal line of the board is drawn

c) The scanlines where stones are drawn above and below the horizontal lines

 

Routine a is the simplest. The playfield and ball registers are set and left alone for several scanlines while variables used for b and c are calculated.

 

Routine b is an asymetrical playfield where COLUPF is black and COLUBK is white (sometimes vice-versa). There are carefully timed color changes at both edges of the board.

 

Routine c is a combination of an asymetrical playfield and quick color changes to the PF using STX and STY. The trick is to run a small part of this code in RAM so that STX can be used for white and STY can be used for black. Without running code in RAM, I don't think this kernel could have worked (not in 4K anyway).

 

This explanation is a bit of a simplification, but it gets across the main points. Here's the source code if you want to look into it more. Once again, it's complicated.

go9x9_mar30.zip

Edited July 6, 2005 by Zach

[Wrathchild]

If not Go, then why not Ataxx?

 

The C sources for a Palm version which has good AI is at :

http://www.eecg.toronto.edu/~manohv/ataxx.html

[Zach]

If not Go, then why not Ataxx?

 

The C sources for a Palm version which has good AI is at :

http://www.eecg.toronto.edu/~manohv/ataxx.html

883448[/snapback]

 

Hey! Ataxx is pretty cool! I'm surprised it isn't better known. I made a mock-up that should be feasible. I can think of a few other games that could be played on this board, such as Vertical Four in a Row, Reversi, and Hip.

Edited August 22, 2005 by Zach

[Cybergoth]

So, with Four-Play nearly finished, are there any news on Go?

[Zach]

Actually I've got many projects going on that are higher priority than Go.

[Atari-Jess]

I'll just have to keep on waiting for that glorious game on my beloved VCS...

[Zach]

Well, if there is enough interest, I may move up Go's priority. When Four-Play is completely finished I'm planning to run a poll to get input as to what my next project should be.

[Pac Munchkin]

Go is a great game I have played it before, you capture your opponents pieces by surrounding them like Othello.

 

But Go is the original game much older.

 

Wade