Groovy Tic-Tac-Toe

Drab as a fool, aloof as a bard

2009-03-31 16:52

Posted by Hagfish in Programming

Comments (0)
Trackback (1)

Groovy Tic-Tac-Toe

I have enjoyed using Groovy in the past, and even think it might be the nicest (programming) language in the world, so I thought I would try using it for a fun little project. Perhaps I should have remembered how difficult it was writing a graphical program in Java (on which Groovy is based), or perhaps I should have given up when I realised that Debian doesn’t have a nice Groovy 2D graphics library packaged yet, but my hubris got the better of me and I waded in, trying to create the game Tic-Tac-Toe. I would call it “Noughts and Crosses”, except the limitations of the graphical commands available meant I couldn’t do crosses. So, I will show you the source code needed to run this game, and warn you of the difficulties you will encounter if you try my bizarre way of doing graphics in Groovy.

The Code




import java.awt.*
import javax.swing.*
import groovy.swing.SwingBuilder

// Make some variables global to be reused by functions
swing = new SwingBuilder()
player = 0
gameOver = false
wins = [[0,1,2],[3,4,5],[6,7,8],[0,3,6],[1,4,7],[2,5,8],[0,4,8],[2,4,6]]
grid = [0]*9

def checkWinner()
{
    return wins.collect{grid.getAt(it)}.collect{it.unique().size == 1 && it[0] != 0}.inject(false){total, item -> total || item}
}

def cellClickAction(e, panels)
{
    if (gameOver) return;
    cellId = e.source.name.toInteger()
    if (grid[cellId]) { return false } else { grid[cellId] = (player%2)+1 }
    def panel = panels[cellId]
    def color = (player%2) ? Color.RED : Color.BLUE
    def newBorder
    // Need a swing context to create a lineBorder, which is then assigned to a variable defined outside of the context
    swing.panel() {
       newBorder = lineBorder(color:color, roundedCorners:true, thickness:50)
    }
    panel.border = newBorder
    gameOver = checkWinner()
    return true
}

def changePlayer(textlabel)
{
    if (!gameOver) player++
    def playerName = (player%2) ? "Red" : "Blue"
    if (gameOver)
    {
        textlabel.text = playerName + " wins!"
    }
    else
    {
        textlabel.text = playerName + "'s go."
    }
}

def resetBoard(panels)
{
    def newBorder
    for (panel in panels.findAll{it != null})
    {
        // Need a swing context to create a lineBorder, which is then assigned to a variable defined outside of the context
        swing.panel() {
            newBorder = lineBorder(color:Color.WHITE, roundedCorners:true, thickness:50)
        }
        panel.border = newBorder
    }
    grid = [0]*9 // Reset the board state
}

def frameMaker()
{
    def legend = [0:Color.WHITE, 1:Color.RED, 2:Color.BLUE]

    def frame = swing.frame(title:'TicTacToe', preferredSize:[303,303])
    {
        // This closure is an anonymous inner class which inherits from the superclass created by swing.frame
        // Moving this closure outside of its current context would make functions like gridLayout undefined

        boxLayout(axis:BoxLayout.Y_AXIS)

        def textlabel 
        textlabel = label(text:"Blue's go.", constraints: BorderLayout.WEST)

        def panels = []
        def currentPanel

        panel(constraints: BorderLayout.CENTER)
        {
            gridLayout(columns:3, rows:3, vgap:1, hgap:1)
            for (i in 0..8) // 9 cells
            {
                color = legend[i]
                currentPanel = panel(
                    preferredSize:[4,4],
                    name:i,
                    background:Color.WHITE,
                    border:lineBorder(color:Color.WHITE, roundedCorners:true, thickness: 50),
                    mouseClicked:{e -> if (cellClickAction(e, panels)) { changePlayer(textlabel) } }
                )
                panels[i] = currentPanel
            }
        }

        button(text:'Reset', actionPerformed: { gameOver = false; resetBoard(panels); changePlayer(textlabel) }, constraints:BorderLayout.SOUTH) 
    }
}

frame = frameMaker()
frame.pack()
frame.show()

Comments

Of course, good code should be self-documenting, but I accept this is ugly, ugly code, and it never hurts to give people a bit of an introduction to understanding a complex program. Starting at the bottom, then, there are three fairly trivial lines which create a frame from the frameMaker() function and pack() it and show() it, which is the necessary boilerplate code to get a graphical object to appear on the screen. As these are the last lines, you can tell that the interactivity code must appear earlier on, and the program is event-driven so the frameMaker() function assigns other functions as event-handlers for click events.

Looking inside frameMaker() then, there is a big comment which explains one of the major influences on the code’s structure. The swing.frame() function is followed by a block of code in squiggly brackets, which is like creating a subclass of JFrame with the magical “metaprogramming” feature of Groovy, but as this subclass is like an anonymous inner class, the scoping is very tricky, and it is this that leads to the strange code structure. For instance, inside the frame there are some panels (representing the nine squares of the board) and a text label for instructing the user about the game state, but because they are defined inside an inner class, the functions that have to read the state of the panels or change the text label have to be sent a panels or textlabel variable from inside this inner class block. I could not find a way to access parts of the block from outside, which meant trapping more syntax than I would have liked inside it. Ideally I would have used the Model View Controller pattern and had a board object with a state that I could interrogate and manipulate, without passing variables out to functions.

Aside from these constraints, the rest of the code is relatively straightforward. Nine panels are created, numbered 0 to 8, and are given that number as their name attribute, by which they can later be referenced. They are formatted such that they have a thick, rounded, inner border which is so thick and rounded it looks like a circle. To begin with the circle is white, but it can be changed to red or blue when the respective player clicks on one. The click is handled by a cellClickAction() function, and if the move was successful the player is changed using changePlayer(). This function updates the text label to tell the player whose go it is, unless the cellClickAction() has caused the game to end. The gameOver state is set at the end of cellClickAction() based on the result of checkWinner(), which is where the language starts to shine.

I’ve always liked programming one-liners, and the checkWinner() function is an example of a great one that is possible thanks to Groovy’s support of closures. Getting your head around how they work can involve a bit of a mental leap of faith, or “passing through the brain barrier”, but once you can think in closures, they are a much more natural way of expressing code which would otherwise require nested loops and one-off functions. Incidentally, the inner class block of code mentioned earlier is also technically a closure, but that’s not such a good example if you’re new to them.

Assuming you have some experience of closures, then, I will try to explain how this one-line closure monster works. Firstly I need to point out the wins variable which is an array of triples, and these triples each contain the indices of three panels on the board which are in a straight line. The question that the function has to answer, then, is “Do any of these triples refer to three panels that are all red or all blue?”, since if they do then red or blue has created a line and has won. As the code stores whose go it is, the function doesn’t need to determine who the winner is itself, as it should be the player who has just played.

The flow of logic is from left to right in this line, so what happens is that wins is considered, and for each of its triples a new triple is formed containing the values of the colours on the grid at the three indices (zero for white, one for red or two for blue). Each of these triples is then condensed down into an array of unique values, such that a triple representing three panels of the same colour gets condensed into a singleton of that colour. The size of this condensed array then gets checked to see if it is a singleton, and the first value of the array is checked to make sure it isn’t zero (representing white). If these checks both pass, the condensed triple is replaced by true and otherwise it is replaced by false. The result so far is an array the same length as wins which contains just booleans, representing whether a line of red or blue has been found at each of the places specified by wins. All that is left is to work out whether this array contains a true, but this can be done by “injecting” a false at the beginning of the list and sequentially ORing the entries of the array until there is just one left. If there were any true values in the array, they would be kept by each of the ORs and be the value left at the end, otherwise only a false would be left. This is precisely the value that the function needs to return, so that is what happens.

Conclusion

So, I should point out that I don’t deliberately try to make life hard for myself, but if you don’t push yourself you don’t know what you’re capable of. If I had gone for a text-based interface, I could have had more control and structured the code more how I wanted, but then I might as well have written it in PHP or JavaScript, as I wouldn’t be demonstrating the powerful desktop-app capabilities of Groovy. Having said that, other than starting in a well-sized chromeless window, there is not much difference from loading this program implemented as a DHTML page and loading it as a Groovy script, except the user would need Groovy installed on their machine if they wanted to run the code above.

All that remains is for me to point out what is wrong with the program still, apart from the choice of language and the ugly programming. The main thing is that the text label and the reset button are centred based on their left hand edge, unlike the conventional form of centring where the centre of an object is aligned to the centre of its container. I don’t know why this is, and I leave it as an opportunity for commenters on my blog to provide a patch to show how clever they are. This might actually be easy, because I didn’t spend much time trying to look for a solution after spending ages trying to solve an earlier graphical problem…

Why is it so hard to set the background colour so that the thin grey lines between the white panels are black instead?

Trackbacks

Trackback specific URI for this entry

A bit of help with closures in Groovy
I also had a few points I wanted to make about other aspects of the language, including things I found while working on the game that I presented in my last blog post, so I thought that this would be a good time to write up these ideas.

Groovy Tic-Tac-Toe

Drab as a fool, aloof as a bard

2009-03-31 16:52

Groovy Tic-Tac-Toe

The Code

Comments

Conclusion

Quicksearch

Archives

Categories

Syndicate This Blog

Blog Administration