The only way to find out if something is merely noise or actual information is sit down, read it and try what it says. Yourself. They named me Tom for a reason.
So last weekend I sat down, started reading [part1] of the Tic-Tac-Toe (TTT) example in the 1060 Research newsletters and set myself the goal of using it to create a Connect Four game.
There are a couple of differences :
The board is bigger. Typically Connect Four is being played on a 6 (rows) x 7 (columns) board, but variations exist and I wanted to have as general a solution as I could get. This resulted in two resources :
res:/connectfour/rows
res:/connectfour/columns
These can be backed by anything (a literal, a fileset, a database implementation), but the point is that they return the dimensions of the board.
There are more diagonals in play. While having a general solution for rows and columns, Peter rather quickly glosses over the diagonals in the TTT-solution, just defining the two that count (one of which is actually an antidiagonal).
I decided to have a more general solution where a diagonal goes from top left downwards. The diagonal:0 starts in the top left corner. Diagonals above that one get a positive index (diagonal:1 and so on, counting to the right), diagonals underneath that one get a negative index (diagonal:-1 and so on, counting down).
Antidiagonals go from top right downwards. The antidiagonal:0 starts in the the top right corner.
Antidiagonals above that one get a positive index (antidiagonal:1 and so on, counting to the left), antidiagonals underneath that one get a negative index (antidiagonal:-1 and so on, counting down).
A token drops down the column. As you know, a token (I went with X and O again) is not put in a specific place, but drops down the column into the lowest available position.
The victory condition is four of the same token next to each other in a row, column, diagonal or antidiagonal. That after all is the name of the game ...
All that resulted in a bit more code. Since the dimensions of the board are unknown, I couldn't just map a row, column, diagonal and antidiagonal to a cell{} resource. Here for example is my groovy code for the row :
import org.netkernel.layer0.nkf.*;
INKFRequestContext aContext = (INKFRequestContext)context;
int vNumberOfRows = aContext.source("res:/connectfour/rows", Integer.class);
int vNumberOfColumns = aContext.source("res:/connectfour/columns", Integer.class);
int vRow = Integer.parseInt(aContext.getThisRequest().getArgumentValue("x"));
String vIdentifier = "cells{";
if ( (vRow >=0) && (vRow < vNumberOfRows)) {
for (int vColumn = 0; vColumn < vNumberOfColumns; vColumn++) {
vIdentifier = vIdentifier + "c:" + vRow + ":" + vColumn + ",";
}
}
else {
throw new NKFException("argument - x - should be in the range [0 - " + (vNumberOfRows - 1) + "]");
}
vIdentifier = vIdentifier + "}";
INKFRequest subrequest = aContext.createRequest(vIdentifier);
subrequest.setVerb(INKFRequestReadOnly.VERB_SOURCE);
aContext.createResponseFrom(aContext.issueRequestForResponse(subrequest));
In case you are wondering why I take context and put it into aContext ... that works a lot easier in my editor.
Obviously, the SINK to a cell also requires a bit of code :
case INKFRequestReadOnly.VERB_SINK:
int i;
for(i = vNumberOfRows - 1; i >= 0; i--) {
if (! (aContext.exists("pds:/connectfour/cell/" + i + "-" + vColumn) ) ) {
aContext.sink("pds:/connectfour/cell/" + i + "-" + vColumn, aContext.sourcePrimary(String.class));
aContext.sink("pds:/connectfour/lastmove", "c:" + i + ":" + vColumn + ":" + aContext.sourcePrimary(String.class));
break;
}
}
if (i < 0) {
NKFException e = new NKFException("invalid move");
aContext.createResponseFrom(e);
}
break;
This also shows that I keep track of the last move made, a very convenient resource, since in order to check if there's a win, I need to know where the token fell.
Now, it is very easy to stand on the shoulders of a giant and shout out how great you are ... while ignoring the giant (which then proceeds to punch you in the face). However, given the above variations ... it was plain sailing all the way. The TTT story was great information, it delivers the goods !
For those of you not on Facebook, the amount of very (!) popular games that are mere variations (!) on this theme (with a bit of graphical polish) is huge. Just looking [here], I note Bubble Safari, Bubble Witch Saga, Diamond Dash, Candy Crush Saga, Bejeweled Blitz, Bubble Island. Look at the numbers. Look again, you missed some zeroes the first time.
Now, I'm not a graphical wizard (know thy strenghts and weaknesses), but when showing my first cut of the game to a friend, she wanted graphical icons instead of the textual X's and O's. I also added a multigame layer so it becomes a hotseat game that you can play with your loved ones. You can reach the (early) Christmas edition online here : http://netkernelbook.org/connectfour/<youridentifier>/
Obviously you need to replace <youridentifier> with some number or word or whatever that only you know.
A couple of quid pro quos to end this blogentry :
* A real multiplayer version is coming up soon. I'm thinking about using websockets and you can see that lastmove-resource is going to be very handy.
* I noticed as well as you - when you try it - that it is dreamily slow, not blindingly fast. This is due to the persistance mechanism being in a database (remember Peter switched to database persistance) rather than in memory. For a TTT that's sufficient, for larger boards that works too slow. I'm working on a fix for that. [Here] you can have a look at the Visualizer trace for a first move (with cleared cache). It does add up.
* Note that I only have a small host out there, it is a showcase host, not a massive player host. If you are interested in your own copy, contact me and I'll send you the full source.