Return to Answer

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)

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.

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.

I suggest doing the UTT challenge in two parts:

1. First, design the game (and choose a winning design)
2. Then, implement the game (using the design/requirements 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)

I suggest the following requirements for the design:

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

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)

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.

I suggest doing the UTT challenge in two parts:

1. On the first "weekend-challenge", design the game (and choose a winning design)
2. For the next "weekend-challenge", implement the game (matching the design/requirements decided on the first phase of the challenge)

Benefits:

• More like real-life (design before code)
• Inter-operable implementations from the second phase of the challenge (because they use the same high-level design)

I suggest the following requirements for the design:

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

You might argue that 'design' instead of 'code' is off-topic for this site, but I'd argue that:

• I'm looking for an unambiguous specification (which, is similar to code)
• You can optionally include code for a bot which plays the game (however badly) using that specification

I suggest doing the UTT challenge in two parts:

1. First, design the game (and choose a winning design)
2. Then, implement the game (using the design/requirements 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)

I suggest the following requirements for the design:

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