STRATEGO specification ________ _____________ The VAX/VMS* operating system is an extremely user-oriented operating system. It is a highly modular system, with individual modules that are transparent to the user who has no interest in them. However, one of its greatest advantages is the almost total access to the components of the operating system granted to the programmer. These components, which can be called freely from any VAX standard language, can be thought of as a set of high-level tools available to any programmer. Most of these tools are in the form of "System Services". The system services include device-drivers, software interrupts, I/O services, process control, condition handling, memory management, and much more. Also available are a host of "run-time library" and mathematical routines, as well as language-dependent functions. Yet, the mere existence of these modules does not guarantee programmer accessibility. If it requires a VMS guru with 10 years experience to use the services, then their actual utility is dubious. The quality of the documentation and the strict adherence to standards will largely determine the usefulness of the modules. Furthermore, simply having the services available does not mean that the programmer will have the capabilities required. The best and most straightforward way to address these issues is to answer them from experience. If a task can be defined that will require a great deal of stepping out of the normal skin of the programming language into the bowels of the operating system, and such a task is handed to a good programmer with little VMS system service experience, the result of this task will be an excellent indicator as to the usefulness of the operating system as a software development environment. One type of programming that has reached the status of "art" is the writing of games. Games have a very wide and very demanding audience. They must be extremely user-friendly and very "smart". The game player wants the computer to do all the "housekeeping" operations and the more obvious game functions that require no decision making on the part of the player. Inputting information to the computer must be as efficient as possible. Finally, the player does not want to read pages of rules to learn how to use the system. He wants to start playing right away. Would anyone put a quarter into a video game that had a 300-page manual and required typing commands in by hand? Games put a special demand on the programmer as well as the operating system. Since the game format allows the programmer to add a virtually unlimited number of "features", there is almost always room to make use of more operating system capabilities. Of course, since the user is so demanding, achieving the -------------------------------------------------- *Trademark Page 2 precisely desired result from a service is critical. The board game STRATEGO was chosen as a suitable proving ground for the VAX/VMS system services. The overall objective of the project is three-fold: 1. Test and exercise as much as possible the VMS system services and the operating system in general. 2. Test the interaction of the services with a standard VAX high-level programming language (FORTRAN) 3. Produce a game that meets the highest standards of user-friendliness, ease of use and intelligence. The final product must be of professional quality. STRATEGO is a game program written in VAX-11 FORTRAN for VAX/VMS computer systems. The game is based on the popular boardgame of the same name. It is a two player strategy game, similar to chess, played on a 10x10 rectangular grid board. Each player is in command of a 40 piece army, including soldiers ranking from Marshal down to Scout, several Bombs, a Spy, and a Flag. The object is to capture the enemy's flag. Each player sets his pieces up as he sees fit, and does not know the rank of the opposing pieces until he encouters them in combat. Sometimes, when he loses the combat, he still won't know the enemy's value. Thus, unlike chess where you always know what the opponent's pieces are, a major part of the game is in gathering information and taking occasional risks based on guesses. The game is over when one player either loses his flag, surrenders, or cannot move a piece. The game is played on the computer with each player sitting in front of a DEC VT-100 compatible terminal. Displayed on the monitor is the playing board, a list of captured pieces, an area for error messages, a dialogue area, and the opponent's name and turn number. By moving the cursor on the screen, the player can select which piece to move and its destination. The player can also make notes to himself, send messages to the opponent's terminal, review previous dialogue, jump temporarily to the VMS operating system, and get detailed or quick help at any time. To play the game, each player logs into the VAX. Each process MUST have the same group number in the UIC. The player then executes the STRATEGO.COM file which defines several logical names and executes the STRATEGO.EXE program. The first player to execute the program will be put in a wait state until another process in the same group anywhere on the system executes the STRATEGO program. When that happens, the players exchange names and the game is in progress. Page 3 The processes are synchronized through the use of VMS Event Flags. Both process can "watch" the same event flag cluster and are instructed to perform a certain action if a particular event flag is set. The typical use of the event flags is to signal the other process that you have completed your move. The other process then knows to leave its wait state and take its own turn. The processes communicate to each other through a shared global section of virtual memory. Thus, one process can set a variable that the other process uses. Since a requirement of the program is that it should need no privileges to run, only process in the same group (a VMS restriction) can access the same global section. The players communicate to each other, and the program communicates to the other player through the use of VMS Mailboxes. Whenever a message is deposited into a player's mailbox, his process is interrupted and the message is displayed on the screen. Thus, players can "talk" to each other at any time, regardless of what the program is currently doing (with some exceptions). The program knows when a player is waiting (usually for the other player to move or set up), and the VMS Timer services are used to indicate to a player that he is in a wait state. Every several seconds, a "wait display" flashes. Several functions are available at all times, even when waiting, through the use of software interrupts in the VMS Asynchronous Trap (AST) system services. Previously mentioned was the ability to send a message to your opponent. Others are: screen refresh, make a note to yourself, scroll backwards or forwards through the display, talk to the operating system (by spawning a sub-process), and request help. I/O is accomplished using the VMS Queued I/O system services (QIO). These services allow single-character input from the terminal, read and write to the mailboxes and set up traps for various control characters and keyboard ASTs. The screen display is handled using the VMS Run-time library screen functions. These are optimized to run on the VT-100 series of terminals, but should work on almost any video terminal (although the results may not be satisfying). There is a bug in the standard VT-100 firmware that causes the scrolling functions for the dialogue area to work incorrectly. This bug does not exist in VT-102, most emulators (such as the C.Itoh CIT-101), and (hopefully) VT-200 series terminals. The program is highly modular and liberally commented. All the system services are contained in two modules (an initialization routine and a package of useful system service routines), thus portability to another system could be accomplished by modifying these two modules and writing the screen handling routines normally extracted from the VMS run-time Page 4 library. Certain non-standard FORTRAN features may need to be changed as well. It was built using the CMS code management system and the MMS module management system. The MMS DESCRIP file is included in the distribution for those who have MMS. The EMACS text editor with an interface to both CMS and MMS was used. All source and reference files are included in the standard distribution. Modifications to the program are permitted. Instructions for building the system are in AAAREADME.TXT. This program was developed entirely at Hughes Aircraft Space and Communications Division, PWB/Engineering department by Gordon Howell. Neither the author nor Hughes Aircraft assume any responsibility for this product's performance. Any questions may be directed to the following address. An attempt to respond to any reasonable query will be made, but no guarantees are offered. Gordon Howell Hughes Aircraft PO Box 92919 Building S50/X342 Los Angeles, CA 90009 (213) 615-9075