Weekend-Challenge Reboot

Question

In December 2013 we held a bunch of weekly weekend-challenge events, which was fun, and generated posts that made it to the site's newsletter, week after week. One may want to tweak this query so as to filter posts created before December 30th, 2013.

Some weekend-challenge stats up to that date:

• 5 "eligible" challenges
• 4.8 questions / challenge
• 8 answers / challenge
• 11 participants (askers)
• 24 questions
• 40 answers (1.667 avg.answers, std.dev. 0.761)
• 4,762 views (avg. 198.417, std.dev. 145.99)
• 70 comments (avg. 4.118, std.dev. 2.804)
• 206 question score / votes (avg. 8.583, std.dev. 2.796)

---

Let's reboot the thing. But differently.

Why? For the heck of it.

When? Between Saturday 2014-02-01 and Friday 2014-02-28, inclusively. Because it's no longer a weekend-only thing, the weekend-challenge tag is being replaced with community-challenge.

Who? Everyone that thinks they can implement the challenge with the best code they can write.

What? We have less than 2 days to decide.

---

Rules.

• Entries must implement the challenge proposed in the accepted answer here. Implementation details are up to each participant.
• There is no platform or language constraint (do it in brainfuck if you dare!).
• You can post working parts of your code separately, as you write them.
• You can post as many questions as needed to get your solution fully peer reviewed.
• Posts must be your best possible code - don't just post something that works, put some effort into it. If you're about to post and see a refactoring opportunity, take it.
• These questions are meant to be examplary CR questions. Don't just dump your code for review, put some effort into your CR question, too.

We shall re-conduct this event later (with a different challenge of course!), if a post-mortem analysis shows that this activity has contributed to bring up the site's metrics. The December stats show 1.67 answers per question - that isn't enough. We need at least 2 answers per question, and of course decent voting.

Answer 1

The Ultimate Tic-Tac-Toe^tm

Tic-Tac-Toe is boring. Let's code The Ultimate Tic-Tac-Toe, a whole different story.

Uh, what?

1. Each turn, you mark one of the small squares.
2. When you get three in a row on a small board, you’ve won that board.
3. To win the game, you need to win three small boards in a row.

You don’t get to pick which of the nine boards to play on. That’s determined by your opponent’s previous move. Whichever square he picks, that’s the board you must play in next. (And whichever square you pick will determine which board he plays on next.)

What if my opponent sends me to a board that’s already been won? In that case, congratulations – you get to go anywhere you like, on any of the other boards. (This means you should avoid sending your opponent to an already-won board!)

What if one of the small boards results in a tie? I recommend that the board counts for neither X nor O. But, if you feel like a crazy variant, you could agree before the game to count a tied board for both X and O.

_{http://mathwithbaddrawings.com/2013/06/16/ultimate-tic-tac-toe/}

---

Specs?

Implement a game that works as described above. Make it a console app, a windows app, a calculator app, a web app, save games and high scores on a cloud, do what you will.

Just keep it "reviewable".

---

Please tag entries with community-challenge and game, as well as any other applicable tag(s); also include a link to this post: http://meta.codereview.stackexchange.com/a/1472/23788.

Answer 2

@ChrisW raises an interesting possibility that there is IO, and a 'winning design'.

This made me think:

If there is a full month for the challenge, maybe an interesting idea would be to define a socket-layer interface and protocol, and then you can connect two solutions to each other and they can compete against each other.... i.e. negotiate who's X, who's O, and then each AI alternate in sending 'moves'

This could maybe be an extension (I don't know how easy it would be for a TI-Socket layer).

Answer 3

I suggest doing the UTT challenge in two parts:

1. First, design the game
2. Then, implement the game (using your or someone else's design/specifications reviewed earlier in the challenge)

Benefits:

• More like real-life (design before code)
• Possibly, several inter-operable implementations from the second phase of the challenge (if several implementations use the same high-level interface specification)

• Optionally, less work:

  • Just do the design, not the whole game
  • Reuse someone else's design for your game
  • Don't implement the game, and implement a player bot instead

I suggest the following requirements for the first stage, the design of the game's I/O:

• Program I/O and UI must support two interactive players over a network: human versus human, human versus bot, or bot versus bot.
• Game state must be presented (to the I/O i.e. UI) in a human-readable and machine-readable format.
• Game rules won't change in the future (you can optimize or specialize your design for UTT only, and needn't make it generalizable for other games)

Essentially, the first challenge is to specify the program's I/O, i.e. its interface to the outside word and users.

If you believe in Test Driven Development, it should be possible to write one or more bots which use the I/O to play the game, before the game itself is written to implement that I/O.

Expected answers will define/specify the I/O and/or UI. They should be clear enough that bots can be written using that specification and will then interoperate with game implementations.

In order to comply with the rules of the site (all answers on this site must include code to be reviewed) and the rules of the challenge in the OP above, answers (design specification) must include code to be reviewed. It's unusual to include code in a specification, but such code could take many forms, for example:

• Code which define/implements the facade
• Code which uses the facade, for example a bot which plays the game (however badly) using that interface

Given that we are allowed (by the rules of the OP) to post our complete solution in stages, you are welcome to accept or ignore the proposal in this answer, to implement and review the I/O before you implement the rest of the game.