The Dojo Board

[Pictures courtesy of Tom Viner]

The February 2018 London Python Dojo was hosted by SohoNet to whom we're grateful not just because they hosted, but because they stepped up at short notice when our original venue had to withdraw. It was nice to see quite a few of the SohoNet team at the Dojo. Of course, this was all courtesy of veteran Dojo cat-herder Tom Viner who works there at the moment and arranged everything on the day and beforehand. (And who also won the month's book from O'Reilly who have donated generously to us every month for the nearly 10 years that we've been running this Dojo).

/images/MVIMG_20180201_182700.thumbnail.jpg

The atmosphere was great as usual, and it's good to see a nice mixture of old hands, semi-regulars, and newcomers come together. Our Patented Voting Method which, together with the Team Numbering System, surely deserves its own Wikipedia page, raised a few laughs as usual. Plus some confusion - also as usual.

/images/tom-dojo.thumbnail.jpg

I'd offered to give a Lightning Talk about my Dojo Board framework. And I put an activity on the ideas board to build something (anything!) to make use of it. This activity tied in the voting with "Yet Another Trump Tweeter" [not actually called that] and Tom very kindly applied the cat-herder's tie-breaking prerogative to declare that my Dojo Board would be the activity du soir.

First, a little background about the project. At one time it was reasonably common for people propose a challenge for the Dojo which had a board-game flavour to it: Battleships, Noughts-and-Crosses, Connect4, Boggle, Word Search, all those kind of things. They're well-understood or easily-explained challenges which fit nicely inside our hour-and-a-half of coding format.

The Dojo format is fairly open and if a team wants to focus on the mechanics of a board structure, then that's up to them. But often, they really want to work out the gameplay of noughts-and-crosses or which search algorithm will apply best to Boggle etc. But they get bogged down in agreeing a common structure for the board and how to display it.

So, one Dojo about three years ago, we decided that the challenge of the day would be precisely to create a board framework which could be used in future Dojos. I don't remember the outcome, although I don't think that any of the offerings was compelling, but I got interested in the idea afterwards, hacked on it a bit, dropped it, let it gather dust, picked it up again recently and produced something usable with tests and everything!

It's on Github so you can view it, clone it, fork it, raise Issues, send Pull Requests and so on. The main idea is that it be a useful framework where your challenge is board or tile-based but where you don't care about the board mechanics.

Highlights include:

  • n-dimensional (anything from 2 upwards)
  • any or all dimensions can be +inf, that is: they all start from zero but can be infinite to the right.
  • standard Python indexing for get/set/del: board[0, 0] = 'X'
  • boards can be sliced from other boards, eg to allow a visible viewport on a wider -- possibly infinite -- landscape
  • useful functions to find neighbours, detect edges and corners, follow lines
  • simple text output for 2-d boards

You can see the full README and, of course, read the code.

Last night was the first time it was used in earnest, even by me! I'd put a fair bit of thought into the design, conscious of the kind of requirements which board/tile games bring, but I'd never actually used it. Yesterday's challenge was an open one: use the Board framework to do something. And there was definitely variety between the 5 teams.

One team did a Minesweeper clone; one ambitious team used the infinite dimensions to generate a scrolling(ish) land/sea text map; our team managed a maze solver; someone did Connect4; the other team did Battleships. I was pleased to see that, by and large, the framework was useful and usable. There were a few Issues/PRs raised during the evening, which is good. A couple of people mentioned possible improvements, and I implemented a corner detector when our team needed it! (Open Source itch-scratching at work).

/images/MVIMG_20180201_213344.thumbnail.jpg

I made a few changes on the way into work this morning based on some of the feedback from yesterday: neighbours can now ignore diagonals; draw now accepts a callback which defaults to str which allows the caller to, eg, hide or obfuscate board elements according to their state (think: Battleships); and iterline can now be limited to a number of steps (this one, again, from the Battleships team).

Some things I plan to include, having seen a few struggles yesterday are (in no particular order):

  • itercorners
  • iteredges
  • iterhorizontals
  • iterverticals
  • iterdiagonals

Something which I added relatively late in the day, but which gives a real boost, is the simple text-grid output. It's not rocket science (although it does a little bit of work to get even column sizes) but it's just the kind of thing which you tend to leave to the end in a Dojo and then get flustered trying to work out the order of iteration and the combination of "+"/"-"/"|" characters in the right places.

So I'd also like to implement a .paint method which produces a PNG and, like .draw, uses a callback to request an image for each data item (cached, of course) to draw inside the corresponding cell.

But all that will have to wait because tomorrow I'm helping out again at the Turing House Coder Dojo in Teddington in the afternoon, and then running a robotics workshop for our club's PiWars entry in the evening. So I'll be a bit busy...