TEACH: A Generic Script-based Teaching Language:
Author: Jeff Rollason in collaboration with Reijer Grimbergen

Copyright Notice: This article is Copyright AI Factory Ltd. Ideas and code belonging to AI Factory may only be used with the direct written permission of AI Factory Ltd. The language "TEACH" is Copyright AI Factory Ltd 2008.

As mentioned in previous round-ups (see Summer 2008), we have an in-house script-based teaching language (TEACH), already in use in our shogi product. This is available in the Xbox360 Live product Shotest Shogi, turning this from just being a program to just play the game, into a full graphical teaching system for shogi.

This idea translates well to other games, so will become our future company standard for in-game teaching.

Typical approaches to in-game teaching

Typically game products provide limited in-game teaching. For games such as chess the first measure taken is to provide a "hint" button, which will advise what move you can make. Our first Chess product took this further and extended the hint system to provide an in-game coach.

chess coach

This sits in the background and compares its own choice of move with whatever the user played. If the evaluation of the coach's move and the player's choice significantly differs, it pops-up and warns the player. In the above shot the player clearly made a very poor choice, but the same coach might also suggest that the player's move was just "inferior".

Other more elaborate games may choose to provide lengthy in-game text help so that the player can read about the game and show examples of play, with explanations. This functions rather like a textbook for the game.

Other games provide a true teaching session, but these are commonly based on very game-specific hard-wired systems locked to that particular product.

Defects in the above approaches

The systems above have their defects. The hint and coach system are attractive as they are simple to implement. The coach is nice as it feels like there is someone there helping you. A defect in this is that our friendly coach can spot your mistakes and can offer better choices of moves, but will not explain why your move is bad. This could be improved by showing the main line arising from your "mistake", but this is learning without explanation, just showing the main variation that follows. This is not really teaching you how to play.

The "in-game teaching book" approach substitutes for having a textbook on the game, but is actually quite hard work to study.

Finally the bespoke hard-wired true teaching probably offers an effective means for teaching, but probably does not carry to other products and cannot accommodate any easy extensions or add-ons, so is in general a "one-off".

Raising the game and putting teaching at the centre

The first reason to consider having teaching is simply to explain how to play the product. However this can be looked at another way and considered as an opportunity to provide a primary teaching tool to learn the generic game. Before computer games, teaching of a game like chess rested on human-human teaching and textbook study. Now human-human teaching is hard to beat, but is not necessarily ideal. First it depends on the availability of a person prepared to teach, and secondly on them having the knowledge and time to do this. A friendly skilled Uncle can be great for this!

Failing an exhaustible access to a skilled human tutor, the next alternative is text book learning. However this is a bit like exam work preparation and only works well for the more dedicated player.

We now have computer games. The case can be made that this may provide the opportunity to create the most universal effective learning system for any game.

The teaching system, as designed for Shotest Shogi

Our teaching system, based on TEACH, relies on simple text scripts to drive a graphical UI in Shotest Shogi. It is attractive as it allows complex teaching scripts to be created on-the-fly, without needing any changes to the core product. This would make it possible to completely replace any existing tutorial with a new one, with no code changes.

Of course the value of this depends on the flexibility and range of teaching options that the language can support.

TEACH supports the following key attributes:

1. In-game explanatory text
2. Multiple options for highlighting squares
3. Playmove and takeback support
4. Setting of user tests
5. Structuring stepping through lessons
6. Response to specific incorrect answers a user might give

Of these, "6" is particularly significant. It is important to be able to say more than just "that is the wrong move". The system, as implemented can intelligently comment on the user's choice, explaining why it is poor and hinting what they should be looking for.

This limited framework is enough to create a compelling teaching system.

An Example Script

The following is a very small section of the tutorial script provided for Shotest Shogi. Note that this is Japanese chess, which also has the rook used in chess, but this is depicted by a flat piece, as shown below:

:Section: (5) The rook

;Lesson 5: The rook

:NewLesson: The rook moves

:Clear:
:SetSQ: 5e=BR
:TextStart: The rook is one of the two major pieces in shogi.
:UserTask: WAIT
:TextStart: It can move any number of squares horizontally or vertically.
:ShowSQ: 5d,5c,5b,5a,6e,7e,8e,9e,4e,3e,2e,1e,5f,5g,5h,5i
:Exit:

:Lesson: The rook

:Clear:
:Turn: Sente
:SetSQ: 7g=BR,5g=BR
:ShowSQ: 1g,5g
:Success: 1
:TextStart: What is the fastest way to move these two rooks to 5g and 1g?
:TextFail: Sorry, this is not a good first move. Please try again.
:SelectPC: 7g
:UserTask: PLAYMOVE
:TestResult: (1) 1g=BR,5g=EMPTY
:TestResult: (0) 7g=EMPTY: Are you sure that moving this rook first is the fastest way?
:Exit: This is the right way to start. Have you figured it all out?

:Lesson: The rook

:Turn: Sente
:SelectPC: 7g
:Success: 1
:TextStart: Please enter the next move.
:TextFail: Sorry, this will not get one rook on 1g and the other on 5g. Please try again.
:UserTask: PLAYMOVE
:TestResult: (1) 5g=BR,7g=EMPTY
:TestResult: (0) 1g=EMPTY: This rook was already on right square. Not a good idea to move it...
:Exit: Yes, by moving the first rook away from 5g, the second rook can now move to this square. Therefore, you need only two moves.

This starts with a "Section" title that will display "(5) The Rook" as the major lesson title. This is followed by a lesson intro that clears the board (Clear), sets pieces on the board (SetSQ), tells the user what is being talked about, waits for the user to click to respond (Usertask: Wait), displays another comment (TextStart) and then highlights a number of squares on the board (ShowSQ).

However the second and third sections of "The rook" are more interesting. This displays the following:

shogi rook tutorial

It is asking the user "What is the fastest way to move these two rooks to 5g and 1g?", expecting the moves 5g->1g followed by 7g->5g. The first section requires the move 5g->1g and this is tested by the following two lines:

:TestResult: (1) 1g=BR,5g=EMPTY
:TestResult: (0) 7g=EMPTY: Are you sure that moving this rook first is the fastest way?

The first tests for the first (and only) solution, which requires 1g to have a black rook and 5g to be empty. The second line is flagged as an incorrect solution (0) and tests for square 7g being empty. For this to happen the rook on 7g must have moved, which is incorrect. If the user does this, the message "Are you sure that moving this rook first is the fastest way?" is displayed. If any other wrong move is played, then the default "Sorry, this will not get one rook on 1g and the other on 5g. Please try again." is displayed and the test is repeated.

If the user passes that first test, the script moves on to the final third section so the player can play the second move. Here the "wrong move" tests for the user moving the same rook twice, responding with "This rook was already on the right square. Not a good idea to move it...".

This can be enhanced to check for all kinds of possible mistakes, giving clear, targeted advice.

The Advantages of this System

This looks very simple, but it was a simple example. The script above can highlight multiple correct solutions and comprehensive "wrong answers". This is not just limited to simply listing all possible moves with a response for each, but a more intelligent combination of tests to satisfy types of failure.

For example maybe moving a particular piece is generally a bad idea, but moving it to a particular square requires highly specific comment. The script can code both, and the specific test can get priority over the general one. This generality can be based on the piece moved, the square moved to or even the type of piece they are trying to move.

Note that the example above only shows a few features. The script support 27 command types, each of which may have significant sub-functionality. In the following screenshot you can see that there is more than one way of highlighting a square.

shogi square highlighting

The script also supports simply playing through positions or games, with animation. It is a very convenient way to show a game sequence, as this is animated before you. This is great for seeing opening play. It also allows sequences of same-side play, so that a piece can be shown moving through a string of squares, without needing to show both sides playing moves.

Conclusion

This system was originally created to allow a tutorial author to create a teaching script, without needing the core program to change, so they could work independently. This quickly showed that it was actually a very powerful basis for creating a teaching system. Its power comes from having a highly visual system, that can intelligently respond to incorrect user choices. This is so much more attractive than using a textbook, as you watch move sequences animated before you, while squares are highlighted as some point is being made.

Another clear advantage is that this system is easy to program. A 3rd party user could easily create their own teaching scripts, which could turn the product (Shogi in this case) into an open teaching system that many 3rd party authors could contribute to. This kind of attribute is very attractive as the "rest-of-the-world" is a potentially huge contributing resource.

Jeff Rollason: December 2008