Chapter 3 page 1 STARTREK THE COMPUTER PROGRAM By Joe Kasser CHAPTER 3 3.1 Converting the Simulation to a game The problem now is to convert this set of rules into a game that can be played on a computer. First consider the structure of the game. The majority of these games are not real time games. That means that the computer waits for the player to make a move, then evaluates the ramifications of that move recomputing the state of all the variables. After the variables have assumed their new states and the actions taken place, the simulation then assumes a new state while the computer waits for the next move to be made. In a real time game the simulation model is dynamic, and events occur based on the passage of time. The (simulation) game moves along and the player inputs modify the state of some of the variables. This can be demonstrated as follows. In the static game which waits for the player to take a turn, a "move" command will position the Enterprise in a new location (deducting the amount of energy used to get to that location from the available reserves. The Enterprise is then effectively stationary at the new location until the next "move" command is carried out. In the dynamic or real time game, setting the warp factor to move the ship will start it moving. It will then continue to move until either the player intervenes to stop it or change the direction of movement, it collides with something, it runs out of energy, fuel, time or is destroyed by the enemy. The decision to write a dynamic or a static game has to be made when the structure of the game is established. If your terminal cannot be updated in real time, or if addressing the individual character positions is very complex, you are probably better off writing a static or none real time version of the game. 3.2 The Static Model The model discussed herein written in BASIC is the static or non real time version. However since the game is written in a structured modular manner, it wouldn't be too difficult to re- arrange the modules into a real time version. The top level flow charts for both versions of the game are in fact identical and shown below. Copyright (c) Joe Kasser 1989 Chapter 3 page 2 STARTREK THE COMPUTER PROGRAM By Joe Kasser : STARTREK INITIALISE.VARIABLES RANDOM.QUADRANT.FOR.INITIAL.POSITION INITIALISE.QUADRANT LOOP (GAME.OVER.FLAG.SET) + PLAY.GAME ENDLOOP PRINT.END.OF.GAME.MESSAGE ; It begins with an operation that initializes all variables and parameters used in the game. The Enterprise is also then positioned in a random quadrant, which is initialized. The whole game is contained within the LOOP containing the procedure PLAY.GAME. The GAME OVER Flag is a signal between the subroutines and the main or calling routine. It is set within the loop when the game is required to terminate. The flag is tested at the end of the loop, and the game continues as long as the flag does not signal a termination. The flag is set when you win or lose the game, either by being destroyed due to enemy action, by running out of energy and dying slowly as your life support systems fail or by winning the game when you succeed in your mission by wiping out the enemy. The version of the procedure for PLAY.GAME for the static model is shown below. : PLAY.GAME (STATIC MODEL) COMMAND.DIALOG VALID.COMMAND =? YES (0) EXECUTE.COMMAND NO (0) DISPLAY.ERROR.MESSAGE THEN (0) KLINGONS.IN.QUADRANT =? YES (1) SHOOTBACK COMMAND.COMPUTER =? NO (2) COMMAND.SHORT.RANGE.SENSORS =? NO (3) MOVE.KLINGONS THEN (3) THEN (2) THEN (1) ; The procedure starts with some command dialog that asks the player to select a command or move. The computer waits for the player to think of a move and enter it into the computer. Once the move (command) is entered it is checked for validity. If it is a good one, the command is executed. The input command is sequentially compared with the allowed ones, and when a match is found the program flow branches to the relevant procedure. If a match is not found or the command was invalid in the first place, an error message is displayed, and the procedure terminates. After the command has been carried out, it is the Klingons Copyright (c) Joe Kasser 1989 Chapter 3 page 3 STARTREK THE COMPUTER PROGRAM By Joe Kasser turn to do something. The flowchart thus then shows a test to determine if any Klingons are present in the Quadrant. If at least one is, the SHOOTBACK procedure is carried out, which gives them the opportunity to fire at you. If the move made on the current turn was not a SHORT RANGE SENSOR SCAN (SRS), a DISPLAY GALACTIC MAP REQUEST (MAP) or a KLINGON STATUS DISPLAY (KST), the Klingons are allowed to move within the Quadrant by the MOVE.KLINGONS procedure. The PLAY.GAME procedure then terminates. Each procedure that has been defined by a name is usually a subroutine in the BASIC language implementation of the game. 3.3 The Dynamic Model The version of the PLAY.GAME procedure for the dynamic model is very different. Here the model executes continuously while the player changes the state of a number of the action elements. : PLAY.GAME (DYNAMIC MODEL) VISUAL.DISPLAY SHORT.RANGE.SENSOR.DISPLAY LONG.RANGE.SENSOR.DISPLAY TORPEDO.FIRED =? YES (1) MOVE.TORPEDO THEN (1) MOVE.ENTERPRISE KLINGONS.IN.QUADRANT =? YES (1) MOVE.KLINGON SHOOT.BACK THEN (1) RANDOM.EVENT ; In this model we concentrate on action. The first procedure tests to see if a torpedo was fired, if one was it moves it one sector. The action of firing a torpedo now becomes loading the course and current location into an array and setting a "torpedo fired" flag for the MOVE.TORPEDO procedure to act upon. The Enterprise is then moved according to the navigation data. If the enemy is present in the Quadrant, the MOVE.KLINGON procedure moves the enemy inside the quadrant. The enemy then attacks the Enterprise thanks to the SHOOT.BACK procedure. The remainder of the procedure then performs the display function showing the visual, short range and long range sensor displays. It must now be obvious that the dynamic or real time version of the game must be written for a high speed serial CRT terminal or memory mapped video display. The last item is the RANDOM.EVENT procedure which contains all the actions that seem to happen at random in the passage of the game. Routines that are contained in this module include Mr. Spok fixing damaged sub- systems and hitting a Klingon Space Mine. Not shown is the command dialog. If the execution time of Copyright (c) Joe Kasser 1989 Chapter 3 page 4 STARTREK THE COMPUTER PROGRAM By Joe Kasser the PLAY.GAME procedure is fast enough the command dialog can be tested once per loop. If not it should be inserted between the other sub procedures. This will be discussed later when the static model is fully described. The available commands are fewer in this version, because the sensor displays are constantly on the screen, and Damage control takes care of itself as time passes. The player commands are thus as follows NAV Navigation PHA Phasers TOR Photon Torpedoes SHE Shields RES Resign Having laid out the structure of the game from the top, let us now look at the bottom up implementation by considering each command in turn. Once we have done that we will then take a look at how they link together. Copyright (c) Joe Kasser 1989