Setting out to code a Tic Tac Toe - ΩJr. Information Architecture

2 Players act as opponents, taking turns to enter a symbol in a field. A symbol can only be entered in an empty field. The strategy: to prevent one's opponent from creating a line, whilst creating one's own line.

We can work this out in our head, and using a sheet of paper and a pencil probably is the easiest way of playing, whereas a flat surface of sand and a finger suffice in times of trouble. However, playing it when alone presents a bit of a problem: where do we get an opponent? Since 30 years or so that problem can be answered with: computers!

Thus we creed to create a computed Tic Tac Toe consort. Using this as an example, I'm hoping to provide an insight into the mind of one application developer.

First thing to do:

Analyse the game-play, figure out whether the amount of possible movements and strategies is limited and if so, compile them into a knowledge base.

Why?

Because in most cases, choosing an existing move from an existing strategy is faster than computing the best movement each and every time. For Tic Tac Toe this might not be apparent, but think of a more intricate strategy game like Chess.

Method: play the game a few hundred times and register every movement, plus which party won and in how many moves. Keep on playing until you start repeating movements.

Next thing to do:

Figure out how the computer is going to match known strategies with situations presented in real time.

Options:

Represent the playing board as a coordinated grid and define all moves as grid coordinates, matching each situation to a knowledge base of vectors if present, or calculating new vectors each turn;

Represent the playing board as a picture and define all moves as binary switches, matching each situation to a knowledge base of pictures;

Deciding arguments:

Ease of implementation: what programming environments can I use, and what is needed in each of them to implement the matching system?

Speed: which matching system takes the least computing time and power?

Elegance: which system will have people turning their heads and complimenting the programmer / designer?

Space: which system will use the least amount of space and the least reading/writing instructions? Which system will be most memory-effective? (Why is this important? Because today our hardware is the slowest part of the computer.)

Strategy limitability: if the amount of differing strategies is not limited, a new strategy has to be computed in all situations, in which case picture-matching is of no use at all (because it requires a knowledge base of pictures) and vector-calculation will be the only viable option.

Obviously the method of strategy registration is going to depend on the representation system. Why start out writing down strategies using one method, when you know you will have to convert it into a different representation system?

Third:

Decide how to enter data into the knowledge base if one can be used.

Options:
* Write each strategy as a line into a text file / database;
* Build an interface to edit the strategies, either textual or graphical;
* Build an interface to create the strategies, either textual or graphical.
* Obviously this part can be omitted if the strategy amount proves unlimited.

Fourth action:

To design an interface for the game-play (a layout, a look, something to interact with the computer).

Options:

* Use a textual interface, where supplying a new coordinate to the command line is met with a coordinate generated by the computer. The game will end with the computer announcing the winner. The board can be hand-drawn but the human player will have to know the grid used by the computer.

* Use a graphical interface, where the computer draws a board on a screen, and user input (touching the screen, for instance) creates a symbol in a field, which then is met by the computer generating a response symbol in an other field. When the game ends in a win for the human, a decorative effect can be shown to provide eye-candy.

* A combination of both.

Deciding arguments:
* Will all users be human and capable of vision? Or will there be vision-impaired users? Or perhaps other computed users?
* Which kind of interface is most attractive to the largest amount of users?
* Which interface is going to be usable by most users?

Fifth action to take:

Design the strategy system. If we decided to have the computer match real situations to stored ones, design how. Otherwise, design a pseudo-intelligent strategy system that figures out the next move in real time.

More to consider:

How will we present our game to our users? Will we be installing an application onto their computers or mobile phones (for instance)? Will we allow them to play it on line, using their web browser? Will we be using a voice-assisted interface for the visually impaired? Will we build a service that can be queried by other computed processes? (Ooh, web services: all the new hype. It's nothing more than a command-line tool via the internet.)

Almost last on the to-do list:

Deciding on programming methods and environment.

Options:
* Use Object Orientation or not?
* Use UML or XP? Or something else?
* Use event-driven methods or sequential methods?
* Use a graphical environment or not?
* What generation of programming environment do we want (3rd, 4th, 5th)?

And finally: set out to realise the application.

This itself breaks down into a couple steps:

* Program & Document
* Compile (if needed)
* Test & Debug
* Distribute
* Test & Train
* Improve
* Redistribute
* Advertise

So there you have it:

We set out to make Yet Another Tic Tac Toe, or Yattte for short. We didn't write a single line of code, yet we managed to fill up about 75 lines of text. Imagine employing a task force, imagine having a real customer and attending and registering sales meetings, specification and requirement discussions, prototype sessions, training, testing and improvement sessions, requests for change...