GBAGI
The Sierra Adventure Game Interpreter for the Nintendo Game Boy Advance
By Brian Provinciano
Text Input
AGI games are primarily text based. The player enters input via the keyboard such as "look at tree", and the interpreter parses the input. This is not possible on the GBA, as the GBA does not have a keyboard. It is very easy to add an external keyboard to the GBA via it's serial port. However, GBA games should not require attachments, and even with a palm size keyboard it would be less than ideal. The solution is to convert the games to an interface similar to the original Lucas Arts style point and click--a combination between the text based input of early Sierra games, and the graphical point and click of later SCI games.
The Dictionary
Format of the Words
Simply, all of this means that we have more words than we need. If the player is selecting words rather than typing them, most of them can be discarded. If the player will be selecting words to make a phrase, having to scroll through 1200 versus 300 makes a huge difference. The solution would be to remove the extra words, but it's not that simple. |
Cleaning The Dictionary Each word group has roughly one "solid word". For example, with "examine, gaze, look, look on, looking, ..", "look" is the solid word. Sure, "examine tree" would work, "gaze tree" could possibly, but "read tree" or "looking tree"? Not at all. You could do "examine note", "look note", "read note", but "show note" or "look on note" generally would not be what is desired. The solid word is the word selected which is general enough to be used in the majority of cases.
Above is a selection from word group #81. The words "bouncer", "cop", "clerk" and "man" are all in the same group. So, in actuality, if playing Leisure Suit Larry, you could go up to the clerk at the store and type "talk to cop" and the clerk would respond as if you had said "talk to clerk". For a blind text based input system this is acceptable, but not for a point and click system. Taking the dictionary, selecting the solid words, then removing the extras is only part of the solution. For example, "enter" and "exit" are in the same group in Leisure Suit Larry. Though they are treated the same by the interpreter, they really should be separate. So, before the solid words are selected, the solid groups need to be. The objective is to make the interpreter run all the games on the GBA with no manual or per-game configuration needed. We can't be building a database of all the solid words on each game. Instead, an array is created with the solid words based on two or three of the main games. Odds are, the table is complete enough to be used with any game regardless.
The game formatting utility loads the game's dictionary. Next, it scans through it for the solidGroups. If it the word in the solidGroups array is in the dictionary, it places it, and it's group number to the new dictionary. Next, is scans the original dictionary for the solidWords. If a word is found, it is placed in the new dictionary. Finally, all the remaining, untouched groups are read, and the first word in each group is placed in the new dictionary. The new dictionary is now created, and on average, 1/4 the size of the original! |
 |
 |
 |
Input Interface #1 One listbox with common words for quick selection, |
Input Interface #2 One listbox with common words for quick selection, |
Input Interface #3 One listbox with common words for quick selection, |
The first input interface was a simple test while building the interpreter to make sure the parse system was functional. The second improved input by allowing the user to select words with less scrolling/searching. The third contained only words selectable in the current room. One may think that this could spoil the game, but it really is no different from the Lucas Art's interface in games such as Monkey Island, where you could just move the cursor around and it would highlight all selectable objects. It also alleviates the case where every once and a while in a text based game you would see something, but not know exactly what it was called in the game.
The third interface was better, but still not ideal. Two listboxes of words was definitely the best way to present the words because it would allow for less scrolling. However, the displaying of words looked quite random. In games such as Monkey Island with a native words based point and click system, they had the verbs (ie. the "common words"), and then people and objects which could be combined with the verbs to form phrases. For example, you would select "look" from the action words, then select the "door". All AGI games have are a bunch of words all jumbled together. However, that doesn't prevent sorting them.
I created a dictionary database with entries of words their type, then wrote a simple utility which took all the words from the AGI game, and sorted them based on a database. It flagged all the words which were verbs and then put them back into the game. So now after the automatic processing, the game has all the redundant words removed, all the words sorted by type, and a table of flags stating whether or not the word in accessed by the current room. The verbs are displayed in the first listbox, and the nouns and the rest in the second. In some cases, verbs are unflagged to give more accurate dictionaries. For example, Leisure Suit Larry doesn't "store anything", however, he does "go to the store", thus store is treated as a non verb. The resulting interface presents the game in a new, more modern light!
Finally, the final touch on the automatic interface was to shrink the amount of words listed, but allow access to absolutely all the words that the player could access through the current room. To do this, I extended the converter to include all the words from the current room, as well as the words from rooms the current logic uses. The result is a very good word list, though it was significantly larger on a per room basis. To overcome this, I simply added a "More>>"/"Less<<" button to the dialog window. When showing less, it shows on the words from the current room and the logics the current room calls. When showing more, it shows that, plus all the words from logics that call the current room, which would also be accessible if using the text input interface.
 |
  |
Input Interface #4 One listbox with the verbs (action words). |
Input Interface #5 One listbox with the verbs (action words). All the words normally accessible through the current room can be used, but the extra words can be hidden. |
Interface Conversion
As described above, the adventure games can be easily and automatically converted to work with a select and click interface. However, if a new interface was desired, the existing games could be easily modified on a per game basis. The games evaluate which words were entered by calling the "said()" command, for example, "if(said("open", "door")) { ...". To convert them to a point and click interface similar to later Sierra games, all that would be needed would be to design a little icon bar or what not, then replace the "if(said" commands with "if(click" commands, or something similar.
Converting a game's interface is very simple. In this example I used a Sierra AGI game demo pack. It does not use any text input from the player, but rather uses keys to select which demo to view. An on screen keyboard could easily be added allowing the player to press the "F10" key and such, but that takes away from the Nintendo experience. Instead, I simply modified to code to allow the player to select a game with the directional pad (or in the PC's case, arrow keys), and then select the game with the "A" button (or in the PC's case, the Enter key). As a little visual enhancement, I also added a yellow selection border around the selected game. It took only a matter of minutes, and the result was quite pleasing:
 |
 |
Original, Unaltered PC Version Used keys for game selection. |
Quick GBA Conversion Allows simple selection with the directional pad. |
In the case of the text input adventure games however, I believe that they work great as text selection adventure games. The automatic conversion works fantastic, but the games could always have their entire words of input manually sorted in mere hours.
The AGI
game's dictionary is stored in a file called "words.tok". This
file consists of an array of word strings and group indexes. To make
player input work, words with the same or similar meaning are grouped
together. For example, "look" and "examine" are grouped
together. So, the player could type "look tree" or "examine
tree" and it would produce the same results. Once the input is parsed,
the phrase as actually just an array of integers, group indexes. "look" and "examine",
for example, are simply "group #2". The code (logic resources)
do not check if the player entered "look" specifically, but
simply "group #2".
