Electronic Goban - Revision history

ITechGeek: Undo revision 3983 by Yrewevaca (talk)

2010-11-24T06:25:56Z

Undo revision 3983 by Yrewevaca (talk)

← Older revision		Revision as of 06:25, 24 November 2010
Line 1:		Line 1:
	~~----~~
	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
	~~----~~
	~~=[http://ynejynezex.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=~~
	~~----~~
	~~=[http://ynejynezex.co.cc CLICK HERE]=~~
	~~----~~
	~~</div>~~
	== Background ==		== Background ==

Yrewevaca at 02:39, 24 November 2010

2010-11-24T02:39:47Z

← Older revision		Revision as of 02:39, 24 November 2010
Line 1:		Line 1:
			----
			<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
			----
			=[http://ynejynezex.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
			----
			=[http://ynejynezex.co.cc CLICK HERE]=
			----
			</div>
	== Background ==		== Background ==

Bjorn: fixed formatting error

2008-05-17T06:52:16Z

fixed formatting error

← Older revision		Revision as of 06:52, 17 May 2008
Line 17:		Line 17:
	== Implementation Ideas ==		== Implementation Ideas ==

	Simply but, a big array of multicolor LEDs, each one an "intersection" on the board. 19^2, 361, of them. A glorious sight to behold. Initially I thought it would be neat to make each LED a pushbutton, but quickly realized that multicolor LED pushbuttons are expensive, make the whole project orders of magnitude more difficult and would be rather fragile (I'd be delighted if someone showed me otherwise though). So the backup plan would be to simply have a big old grid of LEDs and a d-pad (think... nintendo controller) to move around your "stone" on the matrix before placing it. A five button interface, one on each side. If you use Red/Green bicolor LEDs you can get three colors (tricky eh?): Red, Green, and Yellow. I ''think'' [[http://www.superbrightleds.com/TriColor%20LED.htm these]] are true tricolor LEDs... in the sense that you have one anode (or cathode, your choice) per color (unfortunately they cost way too much, we'll see if they can be found cheaper, something under $0.30 would be nice). The stone you're "placing" would be yellow, and upon pressing would turn your color (based on whose turn it is, obviously). The yellow could also be used to mark the "edge" when playing on a smaller 9x9 or 13x13 board.		Simply but, a big array of multicolor LEDs, each one an "intersection" on the board. 19^2, 361, of them. A glorious sight to behold. Initially I thought it would be neat to make each LED a pushbutton, but quickly realized that multicolor LED pushbuttons are expensive, make the whole project orders of magnitude more difficult and would be rather fragile (I'd be delighted if someone showed me otherwise though). So the backup plan would be to simply have a big old grid of LEDs and a d-pad (think... nintendo controller) to move around your "stone" on the matrix before placing it. A five button interface, one on each side. If you use Red/Green bicolor LEDs you can get three colors (tricky eh?): Red, Green, and Yellow. I ''think'' [http://www.superbrightleds.com/TriColor%20LED.htm these] are true tricolor LEDs... in the sense that you have one anode (or cathode, your choice) per color (unfortunately they cost way too much, we'll see if they can be found cheaper, something under $0.30 would be nice). The stone you're "placing" would be yellow, and upon pressing would turn your color (based on whose turn it is, obviously). The yellow could also be used to mark the "edge" when playing on a smaller 9x9 or 13x13 board.

	This is a project ideally suited for a microcontroller of some sort. They're surprisingly cheap (once you factor in how much it costs to get PIC/AVR prog hardware) and should be very easy to interface to a computer for game data offload. Also, the algorithms for driving this thing will be more sophisticated than I'd want to try to implement on a PIC or AVR. Totally open to ideas here though - I've never done anything with microcontrollers except some robot programming in C with PICs, and then only using an existing framework.		This is a project ideally suited for a microcontroller of some sort. They're surprisingly cheap (once you factor in how much it costs to get PIC/AVR prog hardware) and should be very easy to interface to a computer for game data offload. Also, the algorithms for driving this thing will be more sophisticated than I'd want to try to implement on a PIC or AVR. Totally open to ideas here though - I've never done anything with microcontrollers except some robot programming in C with PICs, and then only using an existing framework.

Bjorn: added note about easter eggs

2008-05-17T06:48:43Z

added note about easter eggs

← Older revision		Revision as of 06:48, 17 May 2008
Line 12:		Line 12:

	So the plan would be to build something that's as close to the form factor of a real goban, but shrunk a bit for portability, and completely electronic. I'd say about a 30cm square (~1 foot for the unit challenged) and no thicker than a paperback book would be a good size. Something you can throw in a bag without hesitation. It should have as intuitive an interface as possible, the ability to automatically score the game, and best of all store games and export them to a computer somehow.		So the plan would be to build something that's as close to the form factor of a real goban, but shrunk a bit for portability, and completely electronic. I'd say about a 30cm square (~1 foot for the unit challenged) and no thicker than a paperback book would be a good size. Something you can throw in a bag without hesitation. It should have as intuitive an interface as possible, the ability to automatically score the game, and best of all store games and export them to a computer somehow.

			Of course, it should also have some pointless eastereggs built in... [http://en.wikipedia.org/wiki/Conway%27s_game_of_life the game of life] springs to mind.

	== Implementation Ideas ==		== Implementation Ideas ==

Bjorn: added proposed projects tag

2008-05-17T06:14:18Z

added proposed projects tag

← Older revision		Revision as of 06:14, 17 May 2008
Line 20:		Line 20:

	Driving a huge multicolor LED matrix will be... interesting. The normal solution for a monochrome display is, as I understand it, a bunch of shift registers. I guess for this, if you use "true" tricolor LEDs, you'd just need twice as many shift registers. If you use bicolor LEDs, which, as I understand it, achieve the third color by duty cycle trickery (switching between the two colors very rapidly to blend them) I'm not sure how you could accomplish this. Advice needed.		Driving a huge multicolor LED matrix will be... interesting. The normal solution for a monochrome display is, as I understand it, a bunch of shift registers. I guess for this, if you use "true" tricolor LEDs, you'd just need twice as many shift registers. If you use bicolor LEDs, which, as I understand it, achieve the third color by duty cycle trickery (switching between the two colors very rapidly to blend them) I'm not sure how you could accomplish this. Advice needed.

			[[Category:Proposed_Projects]]

Bjorn: starting this page, getting some ideas out there.

2008-05-17T06:13:23Z

starting this page, getting some ideas out there.

New page

== Background ==

[http://en.wikipedia.org/wiki/Go_(board_game) Go] is a board game of strategy, like chess, that is around 3000 years old and the most popular game of it's type in the world. Before going any further, take a look at the wikipedia page... the short version is that it's an ''extremely'' easy game to learn and for every player to date beyond mastery. No computer or algorithmic approach can beat even a moderately skilled amateur (it's been in the crosshairs of the AI community since chess, a vastly inferior pastime, fell with little resistance) but four year olds are routinely taught to play. Its played on a grid, usually 19x19, but occasionally bigger and frequently smaller for faster or educational games (9x9 and 13x13 being the other standard sizes). The object is for two players to try to surround as much of the board as possible by placing immovable stones on the intersection points of the grid, the central caveat being that stones can be captured if totally surrounded by opposing colored stones. There are maybe two other rules, depending on how you count, but it's beautifully simple.

Games are played ([http://en.wikipedia.org/wiki/Image:Go-Equipment-Narrow-Black.png illustrative picture]) on a board called a Goban, traditionally a very thick slab of wood with it's own feet that sat directly on the floor, with players on opposing sides sitting on cushions. These days you're more likely to see a table board, which is still essentially a slab of wood. The stones range from traditional (read: expensive) slate and shell to bottlecaps (glass/plastic coated lead being the most common).

== Concept ==

Many clients exist to play Go on computers/handheld devices. These are wonderful in that they can record your game in the SGF format, which is (near) universally used by players to review their games (an important part of getting better, often done with a teacher or opponent). They're also handy when you're moving around, and can't set up a bunch of slick stones on a slab of wood (trains, planes, automobiles, bicycles). For casual games, it's nice to be able to stop and resume at any time.

The big downside is face to face interaction. It's simply nowhere near as enjoyable to play by passing a handheld back and forth or staring at a computer, the latter not being particularly portable most of the time anyway.

So the plan would be to build something that's as close to the form factor of a real goban, but shrunk a bit for portability, and completely electronic. I'd say about a 30cm square (~1 foot for the unit challenged) and no thicker than a paperback book would be a good size. Something you can throw in a bag without hesitation. It should have as intuitive an interface as possible, the ability to automatically score the game, and best of all store games and export them to a computer somehow.

== Implementation Ideas ==

Simply but, a big array of multicolor LEDs, each one an "intersection" on the board. 19^2, 361, of them. A glorious sight to behold. Initially I thought it would be neat to make each LED a pushbutton, but quickly realized that multicolor LED pushbuttons are expensive, make the whole project orders of magnitude more difficult and would be rather fragile (I'd be delighted if someone showed me otherwise though). So the backup plan would be to simply have a big old grid of LEDs and a d-pad (think... nintendo controller) to move around your "stone" on the matrix before placing it. A five button interface, one on each side. If you use Red/Green bicolor LEDs you can get three colors (tricky eh?): Red, Green, and Yellow. I ''think'' [[http://www.superbrightleds.com/TriColor%20LED.htm these]] are true tricolor LEDs... in the sense that you have one anode (or cathode, your choice) per color (unfortunately they cost way too much, we'll see if they can be found cheaper, something under $0.30 would be nice). The stone you're "placing" would be yellow, and upon pressing would turn your color (based on whose turn it is, obviously). The yellow could also be used to mark the "edge" when playing on a smaller 9x9 or 13x13 board.

This is a project ideally suited for a microcontroller of some sort. They're surprisingly cheap (once you factor in how much it costs to get PIC/AVR prog hardware) and should be very easy to interface to a computer for game data offload. Also, the algorithms for driving this thing will be more sophisticated than I'd want to try to implement on a PIC or AVR. Totally open to ideas here though - I've never done anything with microcontrollers except some robot programming in C with PICs, and then only using an existing framework.

Driving a huge multicolor LED matrix will be... interesting. The normal solution for a monochrome display is, as I understand it, a bunch of shift registers. I guess for this, if you use "true" tricolor LEDs, you'd just need twice as many shift registers. If you use bicolor LEDs, which, as I understand it, achieve the third color by duty cycle trickery (switching between the two colors very rapidly to blend them) I'm not sure how you could accomplish this. Advice needed.