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.
3 Answers 3
The Ultimate Tic-Tac-Toetm
Tic-Tac-Toe is boring. Let's code The Ultimate Tic-Tac-Toe, a whole different story.
ultimate_ttt_board
ultimate_ttt_winner
Uh, what?
- Each turn, you mark one of the small squares.
- When you get three in a row on a small board, you’ve won that board.
- 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
.
-
1\$\begingroup\$ 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) \$\endgroup\$Simon Forsberg– Simon Forsberg2014年01月30日 17:40:05 +00:00Commented Jan 30, 2014 at 17:40
-
\$\begingroup\$ Like some "I'm skipping my turn" rule? \$\endgroup\$Mathieu Guindon– Mathieu Guindon2014年01月30日 17:40:46 +00:00Commented Jan 30, 2014 at 17:40
-
2\$\begingroup\$ 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). \$\endgroup\$Simon Forsberg– Simon Forsberg2014年01月30日 18:05:07 +00:00Commented Jan 30, 2014 at 18:05
-
6\$\begingroup\$ 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 \$\endgroup\$Mathieu Guindon– Mathieu Guindon2014年01月31日 18:39:56 +00:00Commented Jan 31, 2014 at 18:39
@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).
-
\$\begingroup\$ "@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). \$\endgroup\$ChrisW– ChrisW2014年01月30日 12:06:09 +00:00Commented Jan 30, 2014 at 12:06
-
1\$\begingroup\$ 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? \$\endgroup\$Mathieu Guindon– Mathieu Guindon2014年01月30日 15:18:25 +00:00Commented Jan 30, 2014 at 15:18
-
\$\begingroup\$ 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) \$\endgroup\$Simon Forsberg– Simon Forsberg2014年01月30日 20:06:46 +00:00Commented Jan 30, 2014 at 20:06
-
\$\begingroup\$ @SimonAndréForsberg in your dreams :p \$\endgroup\$Mathieu Guindon– Mathieu Guindon2014年02月01日 00:30:45 +00:00Commented Feb 1, 2014 at 0:30
-
\$\begingroup\$ 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. \$\endgroup\$AJMansfield– AJMansfield2014年02月07日 01:56:09 +00:00Commented Feb 7, 2014 at 1:56
-
\$\begingroup\$ @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 :) \$\endgroup\$Simon Forsberg– Simon Forsberg2014年02月14日 23:48:17 +00:00Commented Feb 14, 2014 at 23:48
-
\$\begingroup\$ 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. \$\endgroup\$Malachi– Malachi2014年07月23日 16:22:48 +00:00Commented Jul 23, 2014 at 16:22
-
\$\begingroup\$ @Malachi you're welcome to create a protocol / datastructure that is accepted by all the "owners" of working UTTT implementations... \$\endgroup\$Vogel612– Vogel6122014年07月23日 16:29:53 +00:00Commented Jul 23, 2014 at 16:29
-
1\$\begingroup\$ @Vogel612 I am thinking bigger.... like massive multiplayer games bigger. bigger boards with more than 2 players to a board... \$\endgroup\$Malachi– Malachi2014年07月23日 16:42:45 +00:00Commented Jul 23, 2014 at 16:42
-
\$\begingroup\$ @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. \$\endgroup\$maaartinus– maaartinus2015年07月03日 18:01:14 +00:00Commented Jul 3, 2015 at 18:01
I suggest doing the UTT challenge in two parts:
- First, design the game
- 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.
code-challenge
tag rather thancode-golf
(and specifying goals incompatible with golf) \$\endgroup\$An objective primary winning criterion, so that it is possible to indisputably decide which entry should win.
andA 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'. \$\endgroup\$