This is a scratch space for candidate SL pages. I admit it is a mess, and am also aware of
http://c2.com/cgi-bin/wiki?WalledGarden,
http://c2.com/cgi-bin/wiki?WikiSquatting ...
Should you think that a section does look promising, feel free to merge or promote into a separate page
Teaching aids?
Teachers use various techniques to transfer knowledge to pupils. This page summarizes various techniques that are available to diversify teaching. In a sense, this is the raison d'etre of Sensei's, so maybe the whole library should be viewed as such a repository.
Wishlists?
In various places on SL, wishlists keep popping up.
To the irritation of some deshis, who don't always see the value of such lists. True, such lists do not always have long-lasting value. Let's take DGSWishlist as an example. In the end, what one wants, is to have concepts implemented. Now, if different Go servers would have to implement a similar wish, one would find a duplication of wishes for each instance of a Go server littered throughout SL.
So wouldn't it be better to centralise wishes, make sure they are generic, and let designers implement concrete wishes on their server? A problem is that some servers have features that are not present on other servers, therefore those wishes would not always be relevant. A well structured generic wish list should contain all wishes from every possible server; a server-specific wish should be converted into a new wish, and then add the wish that was missing in the generic description.
Pages could exist for e.g. servers, clients, editors, analysis software, (Go playing) programs, etc.... This approach would be far more interesting and last longer, as a generic X would maybe never get implemented, but the richness of features would give loads of ideas for (new, emerging or existing) developers.
BTW - this idea might be totally unfeasible, that's why I put it here...
Analogies?
GoAndEconomics made me think that there must exist other analogies to reach people right from within their speciality. This page could collect/link to such analogy pages.
Promising pages, found searching for "analogy" (not always relevant):
Promoting?
This page intends to group ideas to promote Go.
Introducing Go?
- teaching - top level pages (they need restructuring)
- varia
Club rules
A club is a place where humans come together. In such places, rules must exist to guarantee a good organisation. Typically, a newcomers would receive a booklet (or a URL) explaining him/her how to behave, what to do, who to ask, etc... This page intends to group such rules.
- how to take care of newcomers
- there is always at least one pair playing 9x9: can be stopped rapidly
- when other games end, they take over the 9x9
- rules for simultaneous playing: e.g. Black plays only when White comes at the board
KGS Teaching Protocol?
A typical problem on pre-audio KGS when teaching is that pupils tend to ask questions while the teacher is still (maybe painstakingly) typing something. Another problem is that a teacher might go forward in a game at such a speed, that a ppi cannot catch up, and must know of a way to interrupt an explanation and say which move (s)he would like to see (avoid "yes, that move - no, the previous one - yes..." etc) This page tries to propose a way of efficiently communicating via a Go server when no audio channel is available (it is likely that this page will become obsolete in the future...).
See also HusTeachingMethod
1001 Uses for a Dead Go Stone?
Based on
http://www.msoworld.com/mindzine/news/orient/go/special/gostone.html
- on a key chain
- physics experiment: in vacuum, a Go stone will drop as fast as a feather
- attach to the next interstellar bound space probe, as a message from Earth to the aliens
Reviewing notes?
As far as I know, there is no formal description of how to review a game. Also, the SGF format has only limited support for reviewing.
- reviewers introduce themselve in the first node(s) (as well as in the reviewer properties); each comment should be preceded by the reviewer's nick/initials, enclosed in brackets. remember the SGF "reviewer" property as well.
- don't use the "I" form when referring to players/sides. Use Black, White instead.
- be aware of difference between child/sibling variation styles of SGF editors.
- SGF: hyperlinking references to board position: currently, several ways exist to refer to board positions from within comments: coordinates, markers, variation labels, node names. Often, variations are labelled automatically, referring to them risks breaking the link when variations are reshuffled/added/deleted. Using coordinates avoids this problem, but it is more hard to follow (well, I guess one gets used to coordinates after a while...). although 1-move depth variations could be used to show alternatives, upper case letters should be used instead; variations should only be used if effectively followed by moves. referring to variations is tricky because some SGF editors might represent variations with numbers, other with letters (and yet others with user-selectable aphanumerics). Maybe best is to refer to variations by their coordinates?
- to be thought over: how to review games with someone without a common language (or even common character set). Must be possible, if symbols have a well-defined meaning.
- at this time, reviewing (for me) means a first phase going over moves and listening to my feeling to see if a move is what I would have - or certainly not - played.
- in a second phase, how about trying to find the point of no return?, where one of the players should have given up, as there was no way to win any more from there.
- similarly, it might happen that there exist a last break-even point? (i.e. current situation is even), beyond which one side starts winning. Difficult to work with, a projected score will swing around violently all the time, so there might not really be an even point. But tracing back from a game's end, there is always a point where both players were even (for the last time) and after which the winner is known. Might not have much value if pro players continue to swing a few points around jigo until the very end (What is the value of knowing that the even point was two moves before the last one; but for lower kyu levels, I guess the situation where a player is winning long before the end of the game must be common). Could be an interesting concept to study.
- turn-based playing: have the pupil initiate the review with comments, this will make the teacher easier to select the appropriate level of review, adds extra stuff to discuss, motivates the pupil.
- tutor mode (a MultiGo feature where you can only advance when clicking on the right move) is nice when trying to understand teacher moves
- when White creates an SGF from a (memorized) game, she should rotate the board (if possible) so that the bottom left coordinate is T19 when starting to record moves. When Black will open the SGF, he will find the situation as he played it. Of course, Black could also rotate the board. But maybe not all editors are capable of doing this, so if White's can, everybody will be happy.
- make sure you are using Black's perspective when using geographical locations like up, down, left, right (as the board could be rotated by the reviewee). Coordinates or symbols avoid this problem.
- metric: how often does the initiative switch from one side to the other (hypothese: high count=violent game? could be measured as e.g. the sum of distances between a player's reply and the opponent's move)
- spare beginners from deep reviews and many recommendations: make a complete review, but present only the best two or three advices.
See also: Symbols
SLWishlist?
This page lists (my - feel free to add more, but expect my veto as long as it is under my home page) ideas that might be implemented on SL. The advantage of this page is that pruning of e.g. GuineaPigsFeedback will not get rid of possibly interesting ideas.
- extend the footnote concept to true HTML bookmarks (URL#bookmark) to provide the possibility to point into a particular spot in a page
- The way to specify headings seems wrong: ! should be 1st level, !! second, etc... Maybe each page should be inspected on the deepest level present before deciding what heading to associate with !, !!, etc...
- possibility to search in page histories/deltas (as long as this is still available), not only in current pages
- A Favorites/Bookmarks folder, similar to the watched pages concept. My watched pages list is too big to use on a daily basis. The next step that could be expected is to be able to structure the Favorites...
(Not yet sure if this is worth adding to the related pages, so I put it here first. If anyone feels like there is any potential in an idea, feel free to move it to the Variants page.)
This game on DGS brought me to another idea: the first to make a living group loses the game. Probably for small boards only.
- intersections receive a weight that is taken into account when counting. a question could be whether this weight should also be transferred to prisoners taken from those intersections, or maybe a parallel grid should exist for prisoner weight.
- add-on to the "fog of war" concept in PhantomGo: each side divides the complete goban into arbitrary sectors, each allocated to a team member responsible for it. moves and inter-member communications are time-delayed by the server.
- a client might restrict the view of the board to a part of it, there would be no way to move or play outside the view set by the client. The view might be determined as the area within N manhattandistance from the last played move.
- extension of the toroidal board idea: tile an (NxM) goban to produce a toroidal playing space. Then, introduce a "shear" by sliding two adjacent tiles X points along a common edge in one direction. The resulting tiling gets a sheared appearance. Now apply a second shear operation of Y points along the other edge (i.e. in the other dimension): a XxY sized "gap" will appear and serves as a secondary goban.
- when playing on-line on mobius/toroidal boards, the board would re-centre every time on the played move, requiring the player to adapt to the shifted board situation all the time: especially difficult in blitz games.
- a radical variant (using a server) would be to have both players play simultaneous moves instead of in turn; each conflict would be resolved by bidding prisoners, the winner (who invested most prisoners) occupying the conflict intersection, the loser receiving a compensation in the form of prisoners:
- each player secretly selects a number of prisoners, or
- each player bets an increasing number of prisoners; then,
- prisoners are exchanged, or
- loser receives the difference in prisoners from the winner
- see also BidGo
- IGS tried vote games
ComputerAssistedGo?
(cyberGo, ...)
This page would serve for discussing and collecting tools and concepts to be used during analysis as well as during play and to discuss ethics, future and possibilities of this extension to the human mind (Go playing using assistance software, not to replace human decision making - the borderline is very fuzzy, yes).
Although technically already feasible (and in some extent already in use), I think in the future a separate type of online playing might exist, where consenting players are assisted by software while playing.
My approach might tell more about my lack of Go knowledge (or a naive view of things) rather than introduce new ideas: do I underestimate the possibilities of such software, will it never really be useful? Maybe I will change my mind as I dig deeper into Go, only to find how foolish I was to reflect on this matter? Comments about this are welcome as well.
Some question to debate over:
- is this (ethically) permitted?
- What will be impact on the game of Go?
- Does it make sense to advocate against computer assistance during play?
- The borderline with true Go-playing software, where the move decision is taken by software, is very thin here; how do we subdivide this domain into "acceptable" tools and "not acceptable" (in this context, as the use of any tool is already unacceptable in the "classic" sense); what tools are available?
- can advances in technology (processing speed, memory...) make this cyberGo unacceptable (i.e. it should never be acceptable that of two people playing cyberGo, the one with the better machine would have the edge - maybe a weak argument...)
Related pages
Some notes: (sorry for the mess)
- manual features (Player decides on values)
- persistent concepts (are not linked to a move, cannot be stored in current SGF versions):
- persistent concepts are stored in their layers that can be switched on/off
- symbols can be added and deleted
- (visual representation of) status of groups; alive-dead-weak-strong groups
- confirmed territory - points (help counting during the game) - neutral - undecided
- allow to classify potential playing points with a prio and/or value; drag the label to another classified point to reshuffle priorities; supported by special variant to variations concept aimed at evaluating the value of a point (what if Black plays first/what if White playes first => resulting value)
- automatic replies
- manually built game tree to explore variations
- automatic features (mainly counting stuff)
- automatic ladder detection, life & death of groups? - probably not acceptable
- present groups with 1-2-N liberties left -> ko threats, atari, double atari threats; Benson's Algorithm
- strength and liberties of friend/foe contact groups, in relation with own group status
- influence function - see also
voronoi?
- Adjusted Length Analysis
- QARTS
- ModularThinking support
- evaluation areas can be automatically created by taking the smallest involved area over all subbranches? counting (evaluation) is possible inside such an area: all groups inside it are assumed to be alive unless marked dead by the player.
- databases, dictionnaries of any kind are not acceptable?
- window tracking: the cyberGo application monitors and mirrors the current user board (presented in another application window). the idea is to be able to use this app together with any Go client.
- Speculation
DesigningAGoEditor?
(features that should be present in a Go editor)/list of all possible features...
- variations, SGF merge of different reviews of the same game
- ko indication (MultiGo hasn't)
- playback features
- highlight a square (as in Kombilo), show move history only inside/near that square
- options
- possibility to switch between SGF sibling style and children style
- playback in constant interval or using the stored time
- tagging
- analysis
- highlight an area of interest for investigation in variations, be able to count the result in that area. The area is typically created at the root of a set of variations, and allows to compare the results of those variations in the leaf nodes
- all stones are alive except when encircled and no life?
- the border of the area is equal to the border of the board).
- anywhere in a tree, the user can assign a value (
http://www.red-bean.com/sgf/properties.html#V) to a node. Variations that have a value downstream can then easily be compared, sorted and presented in the SGF editor.
- maybe the area could be calculated automatically given the root node of a set of variations: if all variations explore a local fight, the software is capable to identify the area that is involved over all variations. the software could show the result area with the stones that participated in the process (all variations overlaid on top of each other), and the user can flag if necessary those stones that should not be part of the area, after which the software recomputes the area.
- highlight/dim,territory, live/dead/dependent groups
- SGF 3-way merger
- GMP net module - use your favorite editor against GnuGo, or againt anyone across the net.