Minimal Computox Tactics

When constructing a modern Computox the inevitable question of how accurate the replica should be comes up.  Which features of the original should it incorporate? Should it be based on relays, lamps and switches or more modern tech?

The answers to these and a myriad other questions inevitably come down to striking a balance of safety, utility, authenticity, maintainability and cost.  Some answers are obvious, from an educational standpoint as much of the inner workings of the machine should be visible as possible.  To be used unsupervised in a public setting the machine has to be safe, with a modern power supply.  However, some are less clear.  Is it necessary to provide the ability for the Computox to play first, play a beatable game or to adjudicate two-player games?

It is these last questions I hope to answer, by considering what these three features cost in terms of switch/relay count.  Along the way we will uncover some potential issues with the AUTOX/Computox design.

A small Python script has been written that will test the Computox tactics by playing every possible human game against it.  It takes a couple of optional flags, -b adjusts tactic 3 that spots fork attempts to put the machine in beatable mode, and -c forces the Computox to play first with the associated changes to tactic 4.

As each game is played, the script notes which tactics and win checks are used.  At the end of each game the result, final position and moves are printed out.  Finally, once all games are complete, whether each check within a tactic has been used is printed out, along with the number of wins for each player.  The results are quite interesting.  Let's go through them one tactic at a time.

1 - Play a move to complete a line and win

The table below shows the results associated with tactic 1.  Test indicates which output pin on the SEL uniselector the check is initiated by.  Square1 and Square2 are the squares that the Computox must already have occupied and if Square3 is empty, the move will be made to complete the winning line.  The next four columns indicate whether a specific check and move is exercised when the player or Computox start the game, and whether the Computox is in unbeatable or beatable mode.  A green Y indicates the check passed and the Square3 move was made in at least one game, a dash means it wasn't.

Tactic 1 Usage Results

This provides the first of many interesting results.  There are two checks that are totally unnecessary.  The ability to play E when B and H are occupied and G when H and J are occupied are never used.  Some of the reasons that a particular line is not used are obvious, for example when the Player starts according to tactic 4, the Computox will always play E as its first move, unless the player already has.  Therefore, there is no way for square E to be unoccupied after the first round of moves and any tactic suggesting a win by occupying E is redundant.  Others are less clear.

It is interesting to note that whether the Computox is beatable or not makes no difference to whether particular checks in tactic 1 are triggered.

It is clear from the table that the AUTOX / Computox implementation is not optimal and if the ability for either the player or Computox to start were dropped, additional savings in relay switches and checks could be made.  If we only consider the Square1 and Square2 switches needed to check occupancy (switches needed to check the vacant Square3 can be shared between tactics) and assume a naive implementation that does not share switches, then for tactic 1:

• The Computox uses 40 switches
• An optimal implementation that supports both player and Computox starting games would use 36 switches
• A player starting only machine would use 32 switches
• A Computox starting only machine would use 20 switches

2 - Block the player completing a line and winning

This approach can be repeated for tactic 2, as shown in table below.

Tactic 2 Usage Results

In this case, none of the checks are totally unused, but some switch savings would be possible if support for either the player starting or Computox starting were dropped.  The resulting switch numbers are:

• The Computox has an optimal implementation that supports both player and Computox starting games that uses 34 switches
• A player starting only machine would use 32 switches
• A Computox starting only machine would use 10 switches

 3 - Play a move to prevent the human player setting up a fork

 Tactic 3 shown in the table below, which spots the player setting up a fork, is where the real fun starts.

Tactic 3 Usage Results

When in beatable mode the first five of the six checks are disabled, as indicated by N/A entries in the table.  If the player starts, everything proceeds more or less as expected.  In unbeatable mode the five switchable checks are all used.  It turns out the final check isn't used and the player cannot win.  In beatable mode the first five checks are disabled, the final check remains unused and the player can win.

Things get a little strange if the Computox starts.  In unbeatable mode, only two of the checks are used, one of which is the final B, F, E check.  Again, the player cannot win.  However, in beatable mode this final check is still active and the player still cannot win!  The fact that this last check remains active is documented in the AUTOX articles (see below) and has been confirmed in the Computox wiring.  Not only that, but the example game, taken from the AUTOX article, that I provided when describing the need for tactic 3 introduces the B, F, E check as its solution.

AUTOX Tactic 3 Circuit

However, the text of AUTOX article 2 states that this is intended and that the implementer could change this arrangement, as shown on the right.

Therefore, it appears that both the AUTOX and Computox were only defeatable when the player starts.  However, it would have been relatively easy to allow the Computox to be beaten in both player starts and machine starts modes as the X relay that controls beatable mode has a couple of spare switches that could have been used to disable the final tactic 3 check.

Overall, tactic 3 uses 14 switches on the Computox.  This could be reduced to 11 or 6 switches if either player or Computox starting modes were dropped respectively.  Further adding the complete beatable mode only adds four switches on a single relay over the baseline unbeatable game. 

4 - Claim a "good", empty square

The final tactic is to claim a good vacant square.  This is simpler than the previous checks as it is only necessary to test a single square, as detailed in the table below.

Tactic 4 Usage Results

As was noted in the earlier article, it is interesting that square F is never played in an unforced way.  However, it seems we can go further and suggest that square H is also never played as an unforced move.  Also, if the Computox starts in beatable mode squares B and D are also never played in an unforced way. 

Therefore, there are some small switch savings to be made, but nothing significant.

Winning Checks

In some sense we've saved the most interesting aspect for last.  The method of checking for a winning move, as detailed in the next table.

Winning Check Usage Results

There are eight possible ways to win tic-tac-toe, three columns, three rows and two diagonals.  Each could theoretically give rise to  either a Computox or player win in any particular scenario.  There a Computox win is found it's documented as a red C, with player wins a green P and combined Computox or Player wins as a yellow C/P.

As expected, the Computox can win in most ways if the player is not up to scratch.  Where things are interesting is positions where the player wins.  If the player makes the first move there is a single winning line across the bottom of the board through G, H, J.  As noted earlier when looking at tactic 3, if the Computox makes the first move, with the B, F, E fork check in place the player cannot win.  However, if this check is removed, the example game results in a player win down the centre of the board on B, E, H as described in the earlier article.  This is the only winning position.  

The really interesting thing is that neither of these lines are documented the Model Engineer AUTOX circuits (see blue lamp circuit below), and the Computox only encodes checks for player wins in the columns of the side of the board on A, D, G and C, F, J. 

AUTOX Winner Check Circuit

It is relatively easy to show that these two columns can never be winning given the other rules.  To set up a fork with D or F  being winning moves requires the player claiming opposing corners this will either be A and J with the Computox grabbing E and C or the player claiming C and G with the Computox grabbing E and A.  At this point the fork is set up by blocking the Computox diagonal on G or J.  The Computox can now block one of D, F or H.  The order of checks in tactic 2 will mean that the potential blocks on D or F will be chosen in preference to H, and therefore, the winning line is G, H, J. 

This seems to be an error in both the AUTOX description and the Computox implementation and suggests that, with the fork checks as they are, neither machine can correctly identify player wins.  However, when discussing the Computox win circuit the hanging HXB-B2 switch was noted (see below).  This may now make sense as it could form part of a check for the G, H, J line.  The missing link should therefore be to a G switch.  The fact that this link was not found when buzzing out the circuit might be because the switch is shared with another purpose and a diode is in place to prevent the winning circuit interfering with this (although the GXA-B4 is also spare and available).  This might also suggest that this problem was only found when debugging the machine after its construction and the G, H, J check was added as a fix.

Computox Winner Check Circuit

It does seem as though the player win checks could be reworked to use 5 or 6 switches to check for B, E, H and G, H, J covering both the player starts and Computox starts modes.

To this point we have not mentioned adjudication of two player games.  The AUTOX does not implement two player games, and therefore, we do not have any documentation of its implementation.  The feature was assumed to exist owing to the Computox having two controllers.  However, the winning circuit suggests that this is not the case.  With checks for only two player / X winning lines it is unclear how the Computox could fairly call a game.  However, without support for a two player game the purpose of the second Computox controller is unknown. 

Conclusions

It looks as though the move selection and winner assessment circuits in the Computox could be simplified to remove redundant checks, saving 6 switches.  There would also be a benefit to only supporting one of the player first or Computox first modes, saving a further 8 or 48 switches respectively.  Finally, the beatable mode could be removed saving a further 4 switches.

Although it might be tempting to remove the player first mode, handicapping the Computox by forcing it to play second is desirable, as it makes its victories more impressive than if it makes the first move.  Retaining the beatable mode is also desirable as without it, the opponent is not very interesting, and its inclusion is relatively inexpensive.  This leaves the inclusion of the Computox starts mode.  Given its cost is less than 10% of the total number of switches, providing it does not complicate other aspects of the implementation, it should probably be included too as it increases the variety of the opponent.

Finally, given the uncertainty about its nature and limited value supporting a two player game is probably unwarranted in a replica.  The interest in a machine like the Computox is in its ability to defeat a human opponent, rather than act as referee.