NAME
Game::Go::Terminal - a playable game on two filehandles
VERSION
Version 0.01
SYNOPSIS
my $t = Game::Go::Terminal->new(size => 9, level => 2);
my $result = $t->start; # returns, never exitsDESCRIPTION
A game of Go against the bot, on in and out.
It is a separate module from Game::Go for a reason a sibling distribution paid for: that one put a thousand lines of escape codes in its top-level namespace module, which is why only its board class ever turned out to be reusable.
Why it ships
The confirmation phase is a two-person negotiation and no unit test will tell you it is unusable. This is where somebody finds out that the proposal is the wrong way round, or that the prompt never says which stones are marked, or that "dispute" reads like a refusal rather than a request to play on. Finding that out here costs an afternoon; finding it out after the JavaScript is written costs the JavaScript too.
What the display has to get right
These are rules rather than decoration:
Coordinates on both axes, A to T with I left out and rows numbered from the bottom. A Go player reads them off the edge constantly, which is not true of any other game on this roster.
The last move marked and the captures named. A capture of a large group is the most important thing that can happen in Go and it is completely invisible in an after-picture.
The confirmation phase spelled out. Two passes stop play; they do not end the game. A player told "the game is over" and then shown a board they can still type at will file a bug, and they will be right.
The final arithmetic, line by line. A board full of stones followed by "W+6.5" with no working reads as something the program made up, and komi and prisoners are both invisible on the board.
ATTRIBUTES
in, out
The two filehandles. Keeping them as attributes is what lets a test play a whole game in process against tied in-memory handles, with no fork and no subprocess to eat the test output.
size, level, colour, komi, handicap, seed, ascii, quiet
Every one is validated in the constructor. A sibling's terminal refused a bad colour with a tidy sentence and exit 2, and died on a bad variant with a raw Perl message and exit 255, because one option was checked in the constructor and the other several calls deeper.
colour accepts b, w, black, white, dark and light.
game, bot
The Game::Go being played and the Game::Go::Bot playing the other side, built in the constructor from the options above. They are readable so that a test can assert against the position rather than against the drawn board, which is the difference between a test that checks the rules and one that checks the spacing.
ansi
Whether to colour the output. Worked out at construction if not given: NO_COLOR wins over an explicit request, which is the whole point of the convention, and otherwise colour is used only when out is a terminal.
METHODS
start
Plays the game and returns the Game::Go::Result. It never calls exit: a module that exits cannot be tested in process.
board_text
The board as lines, coordinates and all.
glyph
One point's character.
SEE ALSO
Game::Go, Game::Go::Bot, bin/go.
AUTHOR
LNATION <email@lnation.org>
LICENSE AND COPYRIGHT
This software is Copyright (c) 2026 by LNATION <email@lnation.org>.
This is free software, licensed under:
The Artistic License 2.0 (GPL Compatible)