# Weekend-Challenge Reboot

In December 2013 we held a bunch of weekly weekend-challenge events, which was , 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 stats up to that date:

• 5 "eligible" challenges
• 4.8 questions / challenge
• 24 questions
• 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 tag is being replaced with .

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 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.

• I lol.ed. I cried. I upvoted anyway. :D – David Harkness Feb 6 '14 at 3:55
• Now that we have a "Code Golf and Programming Puzzles" sister site, don't programming puzzles fit there better? (With potential for reviews to be conducted here) – Ben Voigt Feb 6 '14 at 18:06
• @BenVoigt we don't want golfed code on here. The idea is to foster activity on this site. I believe there's an argument about this on the original "weekend-chalenge" linked post :) – Mathieu Guindon Feb 6 '14 at 18:13
• @lol.upvote: That can be indicated on CG&PP by using the code-challenge tag rather than code-golf (and specifying goals incompatible with golf) – Ben Voigt Feb 6 '14 at 18:16
• @BenVoigt so CR can't have it's own code-challenge tag? I think the problem with CG&PP is that each "challenge" would have to be a Q, and each "participant" would post an A. Have you browsed the code-challenge posts? How about you join us in The 2nd Monitor? – Mathieu Guindon Feb 6 '14 at 18:48
• @BenVoigt The purpose of the code-challenge tag is to boost the activity on the site. The idea is that we make our own implementation and then we review each other's code. You might think that the implementations are similar, but they're not. It's not really intended as a puzzle, we want the implementations to be good code, not few characters or similar as CG&PP normally wants. – Simon Forsberg Feb 6 '14 at 18:52
• @BenVoigt The coding challenges on CG&PP seems to be very concrete problems. Our challenges can be quite vague sometimes, and you're also free to take the challenge however far you want, make it as fixed or as flexible as you'd like. Besides... if we would post our implementations on CG&PP, how would we get them reviewed? As you say yourself, the reviews should be conducted here, so why post it on CG&PP then? – Simon Forsberg Feb 6 '14 at 18:55
• @BenVoigt The first two 'on-topic' requirements for PCG are An objective primary winning criterion, so that it is possible to indisputably decide which entry should win. and A clear specification of what constitutes a correct submission. Test cases are highly encouraged. These two requirements are expressly avoided for our challenges. We have no winners, and we have no specific 'correct submission'. – rolfl Feb 6 '14 at 18:56
• Maybe you can convince these guys to participate. – Daniel Dec 2 '14 at 15:35

# The Ultimate Tic-Tac-Toetm

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.

### 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 and , as well as any other applicable tag(s); also include a link to this post: http://meta.codereview.stackexchange.com/a/1472/23788`.

• There's also a variant where if sent to a board that is already won, you can still play on that board (with the only effect being that you can determine where to send your opponent, without being able to change who won the board you played on) (Although I don't like this variant, it's much more challenging if you can play anywhere) – Simon Forsberg Jan 30 '14 at 17:40
• Like some "I'm skipping my turn" rule? – Mathieu Guindon Jan 30 '14 at 17:40
• And there's also a variant where a 3x3 tied board is cleared and started over, and there could also be a variant where the player who has made the most moves on that board wins (or loses). – Simon Forsberg Jan 30 '14 at 18:05
• If I play upper-left in the center board, your next move has to be anywhere in the upper-left board; it makes a very interesting twist that turns a stupidly simple little game into a highly strategic battle! Try it out: bejofo.net/ttt – Mathieu Guindon Jan 31 '14 at 18:39

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

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).

• "@ChrisW raises an interesting possibility that there is IO" -- That's observation which I read in a book once: "If it doesn't specify the system's input and output, then it's not a specification." That book (a novel) also had more than one team independently implementing (different implementations of) a system to the same specifications (teams competing against each other to experiment). – ChrisW Jan 30 '14 at 12:06
• That would be absolutely awesome indeed, but I think it's a little bit beyond - à la SimonAndréForsberg. Implement a network-playable version if you want, but the challenge is really about implementing the game itself. Right? – Mathieu Guindon Jan 30 '14 at 15:18
• Or if we all use Java we can define an interface to make our bots play against each other :) (A socket-layer also sounds nice though) – Simon Forsberg Jan 30 '14 at 20:06
• @SimonAndréForsberg in your dreams :p – Mathieu Guindon Feb 1 '14 at 0:30
• Even better, make it a peer-to-peer cryptographic protocol for this purpose, where the entire tic-tac-toe playing network serves to arbitrate each game. – AJMansfield Feb 7 '14 at 1:56
• @AJMansfield Cryptographic? Even though it's a nice idea, I am not an expert in making things secure. But, if I also get next month to do it, then we can talk :) – Simon Forsberg Feb 14 '14 at 23:48
• if we were to use an XML file to save the stats of the game, we could send moves back and forth in a specified XML format and it wouldn't matter what language it was coded in because the data would be sent in the same language, XML. – Malachi Jul 23 '14 at 16:22
• @Malachi you're welcome to create a protocol / datastructure that is accepted by all the "owners" of working UTTT implementations... – Vogel612 Jul 23 '14 at 16:29
• @Vogel612 I am thinking bigger.... like massive multiplayer games bigger. bigger boards with more than 2 players to a board... – Malachi Jul 23 '14 at 16:42
• @Malachi I'd bet that XML would manage to convert a payload of a single byte (there are 81 fields) to a monster needing more time and memory than any player AI. – maaartinus Jul 3 '15 at 18:01

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.