TK1 Help Files

RPG Toolkit Development System Version 1.4 Documentation (C)Copyright 1998 By Christopher B. Matthews. Produced by Awesome Software. RPG Toolkit Development System Version 1.3 (C)1998 By Christopher B. Matthews DISCLAIMER: Awesome Software, and Christopher B. Matthews, are not in any way liable or to be held responsible for any damages incurred by the use of this software, either to your computer, to funds lost, time or otherwise. THE USER ASSUMES FULL RESPONISBILITY FOR THE USE OF THIS SOFTWARE. The RPG Toolkit Main Menu makes use of the program AAPLAY.EXE, a public domain program released by Autodesk. Awesome Software is in no way responsible for this program. Note:this document does not include the graphics mentioned thoughout the text. RPG Toolkit Development System Starting The Program Ideally you should start the program from DOS. This allows the drawing sequences to be faster, and prevents confusion in file placement while you are creating your own games. You can, however, run the program under Windows or even Windows 95. If your games make use of the Version 1.3 Enhanced option to play MIDI files, you must run the program from Windows. Starting From DOS: First, change into the RPG directory if you haven't already. This is done by typing: CD\RPG From this point, you may begin the program by typing: TOOLKIT Starting From Windows 3.XX: From the Program Manager, open the File menu and select the Run command. A new window entitled Run opens up. At the Command Line prompt, type: C:\RPG\TOOLKIT Where C is the drive onto which the program is installed. After pressing the Enter key, the program will start. Starting From Windows 95: From Win95, click the Start button in the bottom left hand corner of the screen. Select the Run command. At the Command Line prompt, type: C:\RPG\TOOLKIT Where C is the drive onto which the program is installed. After pressing the Enter key, the program will start. If everything has gone well so far, you should be into the program, andan option screen should be in front of you: This is the RPG Toolkit main screen, from which you can gain access to all of the utilities that come with the RPG Toolkit. The following list of programs are here: -RPG.EXE- Main program which allows you to create games. -RPGFIGHT.EXE- Fighting sequence editor. -RPGTRANS.EXE- Translator program which allows you to play your games. -SEARCH.EXE- Searches for all files in a game. -ROTATE.EXE- Rotates a graphic. -FLIP.EXE- Flips a graphic. You select the program you wish to run by moving up and down the screen with the arrow keys. Hit ENTER to select the file you wish to run. To begin, select Main Program (RPG.EXE). It is from here that we will learn how to create our own games. You can also run this program by typing RPG at the Dos prompt. Once you have selected this program, you will see a screen similar to the one in Fig.1: Press any key to leave the title screen and enter the program. Once you have pressed a key, a menu is displayed on your screen (Fig. 2). This is the graphics mode selection menu. Notice there are three options: 1- CGA (320 X 200 X 4 Colors) 7- EGA (320 X 200 X 16 Colors) Each of these screen modes are used for different kinds of monitors and graphics cards. Almost all monitors today support EGA. EGA is the best option, because it has more colors. That may not seem important to you now, but it will in the future once you start creating games. The more colors you have, the better texture your graphics will have. Select the screen mode your monitor uses, and press ENTER. NOTE: If you don't know which screen mode your monitor uses, you can probably tell by the number of colors it uses. If the monitor is old and has only 4 colors, it's CGA. If it's fairly old and doesn't use much shading of colors, it's EGA. If the monitor is new and your computer can run programs like Windows that requires a lot of colors, it's VGA. Since the Toolkit doesn't support VGA, select EGA. If you have a VGA or EGA monitor, it will support all of these modes, although it is best just to use the EGA setting. Once you have selected the screen mode, you will enter the Main Menu (Fig. 3). You are presented with the following choices: 1- Edit Board 2- Edit Tile 3- Clear Data 4- Edit Program 5- Edit Main File6- Edit Main Fight File 7- Edit Character Animation 8- Exit 9- Run RPG Fighting Editor Each of these options will be discussed in detail in the following sections not in the order that they appear in the menu, but in the order that they should be discussed to logically explain the development of an RPG using this program. Edit Tile(Option 2) Enter the Main Tile Editor Menu by pressing 2 at the Main Menu screen. The Tile Editor Menu (Fig. 4) has the following options: 1- Edit Tile 2- Load Tile 3- Return To Main Menu These choices will be explained in a moment, but before that, it is important to explain the usage of tiles in the RPG environment. Tiles are small 16 X 16 pixel graphics that can be saved, edited and retrieved. These small graphics are the most important part to the development of any game you will create. These tiles are used to create player graphics, enemy graphics, fight scene backgrounds and boards (or rooms. They will be described later). The fact of the matter is, the tiles you create with the Tile Editor are the backbone of your game's graphics system. Without tiles, there would be no graphics and therefore, no game. The importance of tiles will become clearer as you learn more. The following is the explanation of each of the above choices: Choice 1- Edit Tile Choose this from the Edit Tile Main Menu to enter the tile editor. You will see a new screen with a black background (Fig. 5). The white square in the top left hand corner of the grid is the cursor. Move the cursor around using the arrow keys on the keyboard. Notice that as you move the cursor around in the grid, a small pixel in the box next to the grid moves with it. This box is called the Tile Box, and the grid is called the Tile Grid. The Tile Grid is divided up into squares, the whole gride being 16 squares by 16 squares. The Tile Box is 16 pixels by 16 pixels big. The Tile Box is a smaller representation of the Tile Grid showing you what the tiles you draw will look like on a board, as a player graphic, etc. If you haven't changed anything yet, to the right of the screen there is a small section that says "Color 1", and there is a small blue box below it. This shows you the current color you are working with. When you place a pixel in the Tile Grid, it will be the same color as the color shown here (in this case, blue). To see this, place a pixel anywhere on the grid. You place a pixel in the grid by pressing SPACEBAR. Notice that the cursor disappears, and a small blue square appears where the cursor was. Move up, down left or right away from the new pixel and the cursor appears again. Also notice that there is a small blue pixel in the Tile Box representing the larger blue spot in the Tile Grid. Get used to moving the cursor around and placing colors, or pixels on the grid. All this drawing is great, but all the pixels are blue. Why not work with another color? To select a new color, press C. You are prompted to enter a new color. At this point, you enter a color code. A color code is a special code that tells the computer what color you want to use. Eventually you may remember a number of color codes, but yocan also type LIB to see a color library that has all of the color codes. For now, let's say we want to use the color red. The color code for red is 4 (see color library). Press 4, and then ENTER. Now the color section of the screen reads "Color 4" and has a small red box below it. Now all the pixels you place on the grid will be red. Try it. What if you make a mistake and you want to erase a pixel? This is done by selecting black as your color and placing a black (or empty) pixel over the one you wish to erase. The color code for black is 0. Press C, enter 0 and press ENTER. Note that there is no colored box below "Color 0" because the background is black also. Now place black pixels in place of other colors by pressing SPACEBAR over them. You probably have a Tile Grid full of garbage by now. Let's wipe the slate clean and draw a serious picture. To clean up the Tile Grid, we must exit the Tile Editor. This is done by pressing D (for done). The Tile Editor Menu screen appears. Select "Edit Tile" (option 1), and you will re-enter the Tile Editor with a clean grid. Now draw a serious picture in the Tile Grid by selecting colors from the built in color library. When you're finished, press S to save your tile. The prompt "Filename?" will appear at the bottom of the screen. Type in a filename (max. 8 letters in length) and press Enter. The tile will be saved in your current directory (\RPG\) with an extension of .GPH (for "Graphic") If you had called your tile TEST, it would be saved as TEST.GPH. It is a good idea to save your tile often during the course of creating it. If you are drawing a number of files with the same background (ie. a tree against a background of grass), it is a good idea to draw the background first (the grass) and save it, and then draw a tree over parts of the grass, and save it as another filename. This will become more useful as you begin to create boards. Now to explain what the other functions in the Tile Editor menu are... Choice 2- Load Tile If you are still in the Tile Editor, save your work, and press D to return to the Tile Editor Main Menu. The second option on the menu, Load Tile is what will be discussed next. Press 2 to choose this option. The screen will clear, and at the top a directory of all the tile (*.GPH) files will run down the screen. These are the names of all the tiles on your computer. To go back to the menu, type EXIT at the prompt. To load a tile, type the name of the tile at the prompt at the bottom of the screen. It is important not to include the extension of the filename (the ".GPH" at the end of the name.) Once you have entered the filename, press ENTER, and you will enter the Tile Editor. The save graphic will appear in the Tile Grid and the Tile Box, and your cursor will appear in the top left hand corner of the Tile Grid. You can edit the current tile just as you would a graphic that you had just started in the Tile Editor. Choice 3- Return To Main Menu Select this choice from the Tile Editor Menu by pressing 3. This takes you back to the main menu. Edit Character Animation(Option 7) Select this option from the Main Menu by pressing 7. This takes you to the Character Animation menu (see picture). This menu has four options: 1- Edit Animation 2- Load Animation 3- Save Animation 4- Return To Main Menu Each of these will be discussed below: Choice 1: Edit Animation A character animation is a frame by fame description of a character in your game. Basically, you're creating a small animation for your character's movements. There are four frames of animation per direction. Press 1 at the Character Animation menu, and you will be taken to the Character Animation screen. This screen shows each from of the character animation. You must create each frame of animation from the Tile Editor and save each tile for use here. Once you have all the frames drawn, you can create the animation file. Looking at the screen, you can see four main sections: Front View, Right View, Rear View, and Left View. Each of these sections has four letters underneath. Each letter represents one frame of animation. You must create four tile graphics of your player walking forwards, backwards, left and right (a total of 16 graphics). Once these are created, you assign each frame of each position on this screen. For example, if you want to define the four frames of animation that make up the player walking forward, you would be filling in positions A through D on the screen (the front view). To select each position, press a letter on your keyboard (A for the A position, etc). Once you select a position, you will be asked if you really want to change it. Press Y for yes. Now you will be taken to a screen which lists all the .GPH tile graphics in the current directory. Type in a filename for this frame of animation (do not include the .GPH extension). Once you have selected a filename, you will return to the Character Animation Screen and your selected graphic will now be displayed. It is very important that you select a graphic for all 16 positions, otherwise unpredictable results may occur when you play your game!!! If you're too lazy to make 16 graphics, just fill in a bunch of the empty slots with graphics you've already drawn. If you don't want your character to be animated anyway, don't fret: your character can be made up of a single tile (*.GPH) graphic if you wish. For more information, see the Board Editor section under selecting a character graphic. Once all of the animation positions have been filled, press X to return to the menu. Choice 2: Load Animation To load a character animation, press 2 from the menu. This takes you to a screen which lists all .CHA files in the current directory and asks you which one to load. Type in a filename, or type EXIT to return to the menu (do not include the .CHA extension!). To view the contents of the file, select option 1 from the menu. Choice 3: Save Animation From the menu, press 3 to save your animation. You will be asked for a filename. Enter it, or type EXIT to return to the menu. Do not include the .CHA extension. Choice 4: Return To Main Menu To return to the Main Menu, press 4 from the Character Animation Menu screen. Edit Board(Option 1) You select this command by pressing 1 at the Main Menu. When you press 1, a new menu appears (Fig. 7). The following options are presented to you: 1- Edit Board 2- Save Board 3- Return To Main Menu These choices will be explained in the following pages... Choice 1- Edit Board Select this option from the Board Editor Main Menu by pressing 1. A new screen appears which shows you a directory listing of all the board files in the RPG directory (board files have an extension of .BRD). A prompt at the bottom of the screen asks you which file you would like to open. Right now, we don't want to open a saved file; we want to work on a new file. This directory screen has three options: NEW, which lets you edit a new board, EXIT, which takes you back to the menu, and Filename, which is the filename of the board you wish to load (it is important not to include the .BRD extension). Since we wish to work on a new board, type "new" (no quotations), and press ENTER. A new screen comes up asking you the name of the board. The name you give the board will be it's filename when you save it, so be sure it's eight characters or less in length and contains no periods (.), commas (,) or anything else that's funny looking. Do not include the .BRD extension!!! Once you have entered the board's filename and pressed ENTER, you are prompted as to what color the board should be. The value you enter must be a color code as was discussed with the tile editor. A list of all the color codes and their corresponding colors can be found in Appendix A. The board color is the color any empty tiles will be filled with. Since there is very rarely an empty tile on a board after you have created it, this option is not used very much. Since that will often be the case with you, simply press ENTER at this prompt for no board color. In fact, just press ENTER now with no value at the prompt. The screen may say "Initializing Board, Please Wait..." briefly, but then the screen will clear, and you will be in the Board Editor (Fig. 8). Note that there is a large grid on the screen, very similar to the grid in the Tile Editor. This grid is called the Board Grid, and is 19 X 11 boxes large. Each of those boxes is exactly 16 X 16 pixels in length; the same size an individual tile graphic is (coincidence? I think not). A board is one screen in your game. You can fill your board up with tile graphics and programs (to be discussed later) and anything else you can think of, and then put your character down in that environment to move around and interact. If tiles are the most important thing in an RPG game, the board is a close second. Each individual board is a file by itself, and contains links to other boards in the game, so that the player can move from one board to the next in a game whose size is limited only to the amount of space you have on your hard drive. The white box up in the top left hand corner is your cursor. Just as in the Tile Editor, you must use the arrow keys on the numeric keypad to move around ensuring that NUM LOCK is on. Move your cursor around. There's nothing new here, this is just like a big Tile Editor; or is it? Notice the top of the board. The name of your board is in the left hand corner, followed by your cursor's coordinates on the board (let's say 1 , 1) then word "NONE", and then "NRML". This is your Status Bar. The Status Bar consists of the following parts: Filename X-Coord , Y-Coord Current Tile.GPH Tile Type The Filename is the filename of the board you are working with. The X & Y Coords are the x and y coordinates of the cursor in the Board Grid. The Current Tile.GPH is the filename of the tile currently selected (right now your screen probably says NONE, because you haven't selected a tile yet). The Tile Type is the type of tile you are working with (either NRML for normal, SOLID, or UNDER. These will be discussed later). The Status Bar will become more important to you as you learn more about the Board Editor. Right now, all you know how to do is move around. What else can be done in the Board Editor? Press H to see the help screen (Fig. 9). There are a number of different options. Don't worry about memorizing them; you can always get to the help screen from the Board Editor by pressing H. Right now, the only command we're interested in is S- Select tile. This command allows you to select a tile to work with in the Board Editor. Press any key to return to the Board Editor, and then press S. When you press S, a new screen appears with the directory of all the tiles in the directory (\RPG\). Type in one of the filenames you see here (try one of the tiles you created in the Tile Editor). Do not include the .GPH extension!!! Once you have entered the filename and pressed ENTER, you will see the tile being displayed on the screen and then you will be back in the Board Editor. Notice that the Current Tile position in the Status Bar now contains the filename of the tile you just selected. Now the interesting part begins. Press SPACEBAR to place a tile on the board, and move your cursor away. Notice that the tile is now on the board. Move around and place more tiles on the board as you wish (Fig. 10). What if you don't like a tile where it is? Move over on top of it with the cursor, and press E to erase it. All this time you have been placing tiles in the "Normal" setting, or NRML as it appears in the Status Bar. The Normal setting means that every tile you put down right now will be assigned a setting of Normal. That means that when a player graphic steps on the tile, he (or she) will be able to walk over it, much like your cursor sails right over the tiles you place in the Board Editor. Normal Tiles are usually used as "carpet" tiles. That is, they are used to draw the floor of a castle, or the grass on a lawn. The player can walk on "carpet tiles" just as you can walk on carpet. But what if you wanted to put up walls? You could insert tiles into your board that looked like walls, but the computer doesn't know they're supposed to be walls as long as they are placed on the board with the "Normal" setting. If you were to place walls on the board with the normal setting, the player could walk right through them when you run the game. In order to make tiles you place on the board "solid", so the player can't walk right over them, press T to toggle the tile mode. Notice that the Status Bar now shows "SOLID" where "NRML" once was. Now all the tiles you put on the board will be "Solid", that is, the player won't be able to walk over them, just like you can't walk through a wall. Solid tiles aren't used only for walls. You should also make any sea shore you create to have solid tiles at the edge of the water so the player can't go out into the water (unless that's what you want to happen). You should also make any "people" you put on the board solid so that the player doesn't walk up on top of them when he/she talks to that person (more about this later). There is one more type of tile available that isn't used as much as the other two, but is still very useful. Press T one more time to toggle the tile type. "UNDER" now appears where "SOLID" once was in the Status Bar. The "Under" type of tile is very similar to "Normal" type, because the player can go through the tile. Unlike "Normal", however, the player goes underneath the tile instead of on top of it like with the "Normal" setting. This is useful when you want the character to go underneath an arch that is on the screen, or to go into a secret passage. Whichever tile type you are using for a specific tile, be careful not to forget to toggle it again back to the type you wish by pressing T. It is a common error to forget to toggle the tile type and end up with a completely "Normal" type wall, or a completely "Solid" ground. If this error occurs, however, there is a way to fix it... Position your cursor over a tile on the board and press ENTER. This brings up the Tile Information Screen (Fig. 11), and tells you the name of the tile at this position of the grid, and whether it's normal, solid or under. Press R to return to the Board Editor, or press T to toggle this tile between normal, solid and under. This is an easy way to fix a small mistake in placing the tile as the wrong tile type, but for a number of tiles, it's faster just to re-select the graphic you were using, and place those tiles over the old ones making sure you have selected the tile type you wish to use. Once you get back to the Board Editor, press H again to view the help screen. Notice that one of the options is to "Place Player On Board". This means to assign a position to this board as to where the player begins on the board. By default, the player begins at position 1,1. You may have already found this out if you have tried to place a solid tile at this location. This value is really only important with the starting board, because it tells the computer where the place the player at the very beginning of a game. All the other boards place the character in a position relative to the position from where he/she came from in the last board. Anyway, exit the help screen, and move the cursor to the place where you wish to have your character. Press P, and a message will be displayed in the status bar saying that there is a new player position at the coordinates of the cursor. If you try to assign the player position to a tile that is solid, you will not be allowed. Now we get to one of the most important parts of the Board Editor- the Board Information Screen (Fig. 12). Enter the Board Information Screen by pressing I. The screen shows you: 1) The filename of the board you are working on. 2) The current cursor position. 3) The currently selected tile. 4) The board color (if you only pressed ENTER when prompted for this at the start of the Board Editor, this value will be 0). 5) The screen mode (1- CGA, 7- EGA, 13- VGA). 6) The starting player position. 7) The player graphic. 8) The board's direction links. 9) If there is fighting allowed on the board or not. 10) The board's constant value. The first 6 items are really of no consequence to you. What is important is everything after item 6, because those are the things you can change from this screen. Item 7 is a very important part of the board. It is absolutely necessary that you assign this a graphic. The player graphic is the graphic that is the player. When the game starts, the computer looks for this graphic to put the player on the screen and move him/her around for the rest of the game. To assign the board a player graphic, press P. You will be asked whether you want to use a Character Animation File (*.CHA) or a Tile File (*.GPH) as you player grpahic. To select Character Animation, press A, otherwise press T for tile. A directory of all the tile or animation graphics currently in the RPG directory is shown. Select one of the graphics to be your player graphic, and press ENTER. Once again, it is very important not to include the .GPH or .CHA extensions. When you have pressed ENTER, you will return to the Board Info screen, and now the name of the graphic you have selected for your player will be in the list. The board's direction links are very important as well. These tell the computer which board the player will go to if he/she goes north, south, east or west of the board you are working on. For example, if the northern link was NORTH.BRD, then when the player reached the top of the screen and pressed up to continue north, NORTH.BRD would be loaded, and the player would start on the opposite side of NORTH.BRD. To illustrate this in a real life sense, imagine you were in a room. In front of you (let's call this direction north), there is a door. You walk to the end of the room until you're right in front of the door. Right now, the door is still to the north of you. You walk through the door and enter the next room (or, the next board if you like). Now the door is to the south of you- you are at the bottom of the "screen" on this new board (Fig. 13 a.). It is also important to keep in mind that when you link two boards, the "Normal" tiles must match up with the "Normal" tiles of the next room. This means that the player can't go walking along in one room (along "Normal" or "Under" type tiles), and expect to get into the next room if the place where the player wants to go in the next room has a solid tile laid down. If you were to walk from one end of your room to the next and there were a wall there, you wouldn't be able to go through the wall. Similarly, if your character were to walk from one side of a board to another so that he/she would have to go onto the next board, the space in front of the player (on the next board) must not be solid; that would be like walking into a wall (Fig. 13 b.). This will become clearer as you begin to make games. To set the direction links, press N for north, S for south, E for east and W for west. Once you press one of these keys, a new screen will come up with a directory of all the boards in the RPG directory. Type in the filename of the board that this board is linked to and press ENTER. Do not include the .BRD extension! By default, there is no fighting allowed on a board. You can change this by pressing F at the Board Information screen. This will take you into a new screen that will first ask you what the skill level for the board is. This can be any value you want it to be, because it is merely a measuring device used by the computer. Later on you will also assign a skill level to the enemies you create for the game. Only those enemies with the same skill level as the room can be fought by the character in a battle. This allows you to give the boards for the beginning stages of the game easier enemies than those of the later stages of the game (it would hardly make sense to force your player to fight something that could beat him/her with one swipe of it's hand). Enter a new value for the skill level, or press ENTER for no change. Once you do this, a directory of all the background (*.BKG) scenarios appears on the screen, and you are prompted for the board's background scene. The background is a backdrop that is used for fighting sequences. Later on it is discussed as to how they are made, but until then just know that you can either enter a new filename (no extension!), or press ENTER for no change. After you have done this, you return to the Board Info screen. The last thing you can change from the Board Info screen is the board's constant value. Select this by pressing C. This takes you into a new screen that prompts you for the new value. Either enter a value, or press ENTER for no change. This value can be any number you want. The board's constant value can be used by the RPG Editor's programming language to determine what it can do on a particular board. Don't bother yourself with that technical nonsense right now. At this point, the constant value isn't important to you, so you can just leave it alone. It'll come up later and will be discussed in greater detail. That's the Board Information screen. Press R to return to the Board Editor. If you want, press H again to see the list of commands in the board editor. The next one we'll go over here is G. Press G to enter the board's Program Screen (Fig. 14). There is a list on this screen that goes from 0 to 9 with program information, and then your cursor's board coordinates are shown. This screen allows you to place program tiles on the screen. Programs are just tiles that allow the player to interact with his/her environment. They allow you to buy items, unlock doors, send you places, and just about anything you can think of. Don't worry about them now. They'll be discussed later. All you need to know is that you can assign the tile you are currently on to be a program tile by pressing a number from 0-9, depending upon which program you want to use (you can have up to 10 programs on one board). Just press 0 now. Notice that your current coordinates are put up in place of program 0's coordinates. You have just assigned the tile you are on to be a program tile- program 0 to be exact. All you've done is assign coordinates to the program. You still don't have a program there. In order to assign a program to the program 0 slot, press P. This takes you to a new screen, and up top the prompt "Which program (0-9)?" appears (Fig. 15). Since we are working with program 0, press 0. A directory of all the program (*.PRG) files appears on the screen. Type in the desired one and press ENTER being sure not to include the .PRG extension. Once you have done this, you will return to the Program Screen, and you will notice that the filename you have just chosen has been assigned to program 0's slot. All this means is that when the player steps on the coordinates of program 0 (let's call them 4,5), the program assigned to program 0 is run (let's say it runs the program "merchant.prg"). Don't worry about programming right now. It's really easy, and I'm not just saying that because I'm a computer nerd. I have designed the programming language for this Toolkit to be simple enough for anyone to learn it quickly. This will be discussed in more detail later. You may do this for up to 10 programs, which is more than enough that will every be required on one board. To return to the Board Editor, press R. The next option is V, which takes you to the Version 1.3 Enhanced options screen. There are two options: M- Change Midi File and T- Change board title. If you press M, you will be prompted as to which Midi music file will run when the player enters this room. If you press ENTER, no file will be selected. Note that this will cause any files playing to stop when the player enters this board. If you want to play one file all the time, always include it in your board. If you press T, you will be asked what the board's title is to be. The board's title is displayed at the top of the screen when the player enters the room. Press R to return to the Board Editor. Now that you're back in the Board Editor, there's just one more command to learn for it, and it's a real easy one. Press M to return to the Board Editor Main Menu. Don't worry! Your board isn't lost forever! Notice that there's a new option on the menu that says "Return to current board" (option 4). Press 4 to return to your board. You don't have to return to your board, however. It's in memory, and you're free to wade through the Toolkit and do things like create tiles, or anything else you want to do just be sure that you go back and save your board before quitting, clearing data and going into the fighting editor program. All three of these options will erase your data. The smart thing to do is save it before you go adventuring through the rest of the program. That's what I do, but it's not required. Choice 2- Save Board If you're still in the Board Editor, press M to return to the Board Editor Main Menu. To save your board, press 2 from the Board Editor Main Menu. This will take you to a new screen that will say "Saving xxxx.BRD" (xxxx is the name of your board). Ignore any errors the computer might spit at you- they're not really errors, and nothing is harmed. Once your board is saved, you will return to the Board Editor Main Menu. What if you want to load your saved board? To load a saved board, select 1 at the Board Editor Main Menu. This will take you into the Board Editor, but before it does, it will show you a directory of all the boards in the RPG directory. Last time, you typed NEW to work on a new board, but instead of doing that, type the filename of the board you just saved not including the .BRD extension! Your board will load and leave you sitting there in the Board Editor, ready to edit it (Fig. 16). Choice 3- Return To Main Menu To return to the Main Menu, press 3 at the Board Editor Main Menu. Choice 4- Return To Current Board (not always there) This option appears on the Board Editor Main Menu if you have been working on a board and have returned to the menu by pressing M. By pressing 4 at the Board Editor Main Menu, you return to the board you were previously working on. Edit Program(Option 4) Select this option by pressing 4 from the Main Menu. This takes you into the Program Editor Main Menu (Fig. 16). The menu has the following choices: 1- New Program 2- Load Program 3- Return To Main Menu 4- Save Program These options will be discussed in a moment, but before that, I must explain the use of programs in the RPG environment. As we have already learned, you can assign certain tiles in the board editor to a program. When a player steps on this tile, a file is loaded and a program is run. The programs which you create using the Programming Editor are very useful things which allow your player to interact with the game. These programs are based upon a simple programming language developed for this toolkit. Don't worry about programming for now. This section simply explains how to use the Programming Editor, and also introduces you to a few simple commands. Later on there is a section that will teach you this programming language in greater detail. It is very easy, so don't worry about it. Choice 1- New Program By selecting 1 from the Programming Editor Main Menu, you enter the Programming Editor. The Programming Editor is a very simple text editor used to write programs for RPG games. I highly recommend, however, that you use a text editor instead, because working with the Programming Editor really isn't good enough for those long programs. A text editor such as the one that comes with dos (versions 5.0+) is fine. You can, however, use a word processor being sure to save your files as ASCII, text, plain text, or whatever your word processor calls it. If you use something other than the Programming Editor, be sure to save your files with a .PRG extension! This is very important! If, even after this warning you insist on using the built in Programming Editor (it is rather convenient to have it there ready for use at all times), the following section will explain how to use it. After selecting New Program from the menu, you are taken to a new screen and prompted for the name of the program. This will be the filename for the program. Type in a name (max 8 characters and no extension), and press enter. You will enter a new screen that uses large letters. This is the Programming Editor (Fig. 17). The screen uses large letters, because this is the size the letters will be in your game. By making the letters this large, it is easier to see how much space on the screen text will take up. You will notice the prompt: 0> near the top of the screen. This is the place where you enter text. The first part of this prompt, the '0' tells you which line number you are on, and the second part, the '>' simply tells you that it is a prompt. You can begin entering lines of code now for the program you are creating. Since you don't know any of the programming language yet, just enter whatever you want and press ENTER. Notice that now the prompt 1> appears. This is the prompt for the next line. Enter anything here and press ENTER. As you do this repeatedly, you may notice that the Programming Editor is a little bit like a word processor, because it lets you enter text in a word processing fashion. Unlike a word processor, however, you cannot use the up and down arrow keys to move from one line to the next, and once you fill up the screen with text, there is no apparent way to scroll back up and view what you have already typed or modify it. This is where a real word processor comes in handy, because it's easy to move around and edit your code. It's a little more confusing in the Programming Editor. For now, just enter garbage into each line until the first few lines disappear when you reach the bottom of the screen (the program is too large to fit on the whole screen). In a word processor, you would simply use something like the up arrow to scroll back to see the rest of the program. It is different in the Programming Editor. To view the full program, type LIST and press ENTER. Once you have done this, the program will scroll down the screen again, probably too quickly to see the parts you want to before they disappear again. To see this part of the program, type LIST again, but this time, quickly press Q as soon as it starts scrolling. If you pressed Q fast enough, you'll see that the listing stops before it reaches the end so you can see these parts of the program. That's all good and fine, but what if you want to edit a line? In a word processor, you'd just move your cursor to where you wanted to edit the line and edit it. It is different in the Programming Editor. To edit a line, type EDIT and press ENTER. This causes you to be prompted, and you are asked which line you wish to edit. Type in the line number and press ENTER. The line you wish to edit will be displayed, and then you will be prompted as to what you wish it to be changed to. If you decide you don't want to change it, press ENTER, otherwise type in the new line. Now then, what if you're typing along, and you notice that you forgot to include a line of code somewhere. You bring up the list, and see that the missing line of code should be between lines 19 and 20. In a word processor, you would just position your cursor at line 20 to produce a blank line between lines 19 and 20 so you could enter a line of text there. It's different, of course, with the Programming Editor. To insert a blank line between two existing lines of code, type INSERT at the prompt. You will be prompted as to where you want to insert the blank line. If you change your mind and don't want to insert a blank line, just press ENTER, otherwise type the line number where the new blank line should appear. In this case, you would type 20, just as you would press ENTER on line 20 in a word processor. Once you have entered the line number and presses ENTER, type LIST again to see the program listing. You will see that at the line you chose to insert (let's say 20), there's now a blank line. What happened to the line of code at line 20 before it was inserted? It's now shifted down one line, as is the rest of the program below line 20. Once you have inserted a blank line, you'll want to put something in it. This is done by using the EDIT command, and typing the line number of the one you have just inserted. You can see how much easier things are with a word processor. You can do the same things with the Programming Editor as you can with a word processor, but it's a little harder. Right now you probably have a program in memory that is full of garbage. To clean this up, type DONE to return to the Programming Editor Main Menu, and select 1 for New Program. Enter the filename, and you will return to the Programming Editor with a clean slate. Since you're there ready to go, I'll take this occasion to teach you two of the most basic of the commands in the programming language used by the RPG Toolkit. The first command is one which you have already been using, though you didn't know. Just type something- anything, as long as the line doesn't start with the ':', '#', '*', or '@' symbols (the reason why will be explained later). To start you off, type this: This is programming code! Believe it or not, but that is programming code for this programming language. Plain text by itself will be displayed in the Message Box when the program is run. The Message Box is a small text box that appears at the top of the screen when a program is run and gives messages to the player. From what you know so far, you can use a bunch of text lines to have programs talk to your player when you try out some sample games. I told you this programming was easy. The next command you'll learn here is the comment command. Comment commands always begin with an asterisk (a '*'). Any text that appears after that symbol is ignored by the computer. Essentially, any command that begins with a * is ignored when the program is run. If it's ignored, what good is it, then? Comments allow you to insert little notes to yourself in your programs to make them easier to understand. Comment regularly. Trust me, if you write a program to be used at the first of the game and a few weeks later when the game is finished that program isn't working right, comments will be very useful to you when you go back and edit the program. They will help you understand what the program does and how you planned it to work. If you leave a line blank, it will be ignored by the computer. If, however, you want a blank line to be inserted in the Message Box when the program is run, just put the symbol @ on a line all by itself. This will cause the computer to put a blank line in the Message Box. When text is displayed in the message box, it is displayed five lines at a time, and then the player must press a key to see the rest of the text. At the end of a program, the computer will immediately restore the screen to the way it was before the program was run, erasing the Message Box altogether. That means if you have 6 lines of text, the first five will be displayed and then computer will wait for the player to press a key. When a key is pressed, the last line will be displayed, but will immediately vanish because when the program ends the computer restores the screen to the way it was. There are ways of overcoming this, but until you learn them, a simple remedy is to include @ symbols on each line until all the text lines add up to be a multiple of 5 plus one (so the computer will think there's more text and pause for you). The "plus one" should be a @. Comments must appear on a line by themselves. When writing plain text lines for your programs, you can include the '*' symbol, or any other symbol as long as it isn't at the first of the line. If it's not at the first, the '*' symbol will be displayed in the Message Box, just like the rest of the text. Here's a sample program using what you have learned so far: * A sample program demonstrating comments and text. * Lines that start with a '*' are comments and are ignored. * The following will be displayed in the Message Box: Hello, this is a happy program. Notice that the Message Box is small. That's why you should keep your lines of text on one line. @ * The last @ (blank line) was included because the Message * Box can only show 4 lines at a time. By inserting a @, * the computer is fooled into thinking there are more lines * of text ahead, and will wait for the player to press a key. Type in this program and type DONE to return to the menu. In a moment, how to save this program will be discussed. Once you have saved it, enter the Board Editor, and load the board which you had worked on earlier. Using the G command, place this program on the board. You can skim ahead to see how to play the game and see what the program does (you will have to look at how to create the Main File, and how to run the Translator), or you can wait patiently until we get to that point. Choice 2- Load Program To load a program that is saved to disk, press 2 at the Programming Editor Main Menu. This will take you into a screen that displays a directory of all the programs in the current directory (\RPG\). At the bottom, you are prompted as to which program you wish to load (Fig. 18). You can type EXIT to return to the menu, or you can type the filename of the program you wish to load. It is important to remember not to include the .PRG extension. Once you have typed the filename, press ENTER, and you will enter the Programming Editor. The loaded program will be displayed on the screen, and you will be free to edit it as you would a new program. Choice 3- Return To Main Menu To return to the Main Menu, press 3 at the Programming Editor Main Menu. Choice 4- Save Program By pressing 4 at the Programming Editor Main Menu, the program in memory will be saved to disk with the filename given to it when it was first created. Choice 5- Return To Current Program (not always there) This option appears on the menu if you have been working on a program and you have typed DONE to return to the Programming Editor Main Menu. By pressing 5 at the menu, you will return to the Programming Editor to continue working on the program. Like the Board Editor, you can leave the Programming Editor and do other things within the program and return to work on the program later (as long as you haven't cleared the data or run the RPG Fighting Editor). Edit Main File(Option 5) Select this option by pressing 5 at the Main Menu. It takes you into a new menu called the Main File Menu (Fig. 19). The menu presents the following options: 1- Edit File 2- Load File 3- Save File 4- Return To Main Menu The main file is an essential part of your game. It contains all the information that tells the computer what screen mode to work with, which board is the starting board, which program should be run at the beginning of the game, etc. The above choices are explained in the following: Choice 1- Edit File Select this choice by pressing 1 at the Main File Menu. By doing this you are taken into a new screen which shows the options the game will run under (Fig. 20). This screen shows information regarding the game, and has the following choices: 1- Edit Filename 2- Edit Starting Program 3- Edit Constant Program 4- Edit Initial Board 5- Edit Fighting 6- Midi Music On/Off 7- Character Transparency On/Off 8- Return To Menu Here's what each option does: Edit Filename- Select this option by pressing 1 at the Edit File menu. A prompt appears at the bottom of the screen which asks you what the filename should be for the main file. Type in a name 8 characters or less being sure not to include the .GAM extension. Nothing complicated here. Edit Starting Program- Select this option by pressing 2 at the Edit File menu. The starting program is a program created with the Programming Editor or a word processor that runs as soon as the game starts. This means that you can create title screens, opening story sequences, a menu to open saved games, etc. As you learn more about programming these types of things will become more real to you, and you'll see how very easy it is to create something like a title screen or opening sequence with the Toolkit's programming language. As soon as the program ends, the computer looks for the starting board and begins the game. When you select this option, you are taken into a new screen that shows a list of all the program (*.PRG) files in the current directory (\RPG\). At the prompt, type in the name of the starting program, or type EXIT for no change. Keep in mind not to include the .PRG extension! (Like I have to remind you.) When you enter the name and return to the menu, you'll notice that the filename of the starting program is now in the slot assigned for that information. Edit Constant Program- Select this option by pressing 3 at the Edit File menu. The constant program is a program that will run at any point in the game if the player pushes the right key on the keyboard. This is very useful, because it can be used to show inventories of the player's items, the player's teammates (if any), it could be used to save the player's progress, load the player's progress, exit to DOS (this is the only way the player can quit to DOS, so be sure to include this in your constant program), etc. When you select this option, it takes you into a screen similar to the one for the starting program option (see above). Enter the name of the run time program (with no extension), or type EXIT to return to the menu. If you have entered a filename, you are next prompted for the program's run time key. This is the key the player must press to activate the program while playing the game. I suggest X. Why? Because I'm crazy. Once you have selected the run time key, you will return to the menu, and the information you just entered will be displayed on the screen. Edit Initial Board- Select this option by pressing 4 at the Edit File menu. This takes you into a screen that displays all the *.BRD (board) files in the current directory (\RPG\). The initial board is the board where the player starts the game. You can't get much more important than that. Type in the name of the board (no extension), and press ENTER. If you want to exit without assigning an initial board, type EXIT. Edit Fighting- By default, there is no fighting allowed in the game. To change this, press 5 at the Edit File menu. This takes you into a new options screen. Fighting in games created with the toolkit is done in traditional RPG style where your player selects a move from a menu and then carries it out. The enemy retaliates, of course, and the battle continues on until someone wins. More on creating fighting scenes later, but until then you must decide how your player will get into fights. In a typical RPG game, the player walks around, and suddenly enters the fighting system without seeing the enemy on the board. This is the way it is done with the Toolkit. The player walks around for awhile, and eventually gets into a fight with unseen enemies (actually, you can see them in the fighting system, but you can't see them on the board, just like a traditional RPG). There are two ways by which your player can get into fights: randomly, or planned. This screen shows which kind of fight is currently selected. The default is random. A random fight is one where the player gets into a fight based upon the computer's random number generator. To make that sound a little more human, all it means is that the player takes a step. When he/she does that, the computer pulls a number out of a hat (metaphorically, of course). If that number matches a pre-defined number (let's say 25), then the player gets into a fight. I find this to be an effective way of making your characters fight, because it is unpredictable. A planned fight is a little different. You, the game maker, decides how many steps the player can go before he/she gets into a fight. Let's say you selected 10. That means that the player will get into a fight every 10 steps. It's more predictable, but ensures that your players are always fighting (actually, players fight quite frequently with the random setting as well). Choose what kind of fight you want now. You are prompted as to what kind of fighting you want. Press 0 for a random fight, and 1 for a planned fight. To leave it the way it is, press ENTER. Once you do this, you are prompted again. If you selected a random fight, then you are asked what the chances of getting in a fight are (the default is 1 in 50- it may seem slim, but it really isn't). All you enter here is the maximum number of the chance. If you wanted the chances to be 1 in 50, you'd type 50. If you wanted them to be 1 in 100, you'd type 100. If you want to leave it as it is, press ENTER. If you selected a planned fight, you are asked as to how many steps the player is allowed to take before getting into a fight. If you wanted your player to get into a fight every 10 steps, type 10. If you wanted him/her to get into a fight every 50 steps, type 50. If you want no change, just press ENTER. Next, regardless as to what type of fighting you chose, a list of all the fighting (*.FGT) files in the RPG directory is shown. A fighting file is similar to the main file in that it tells the fighting system how it should work, much like the main file tells the rest of the game how to work. The main fighting file will be explained later. Just know for now that you can type in the filename keeping in mind not to include the .FGT extension. If you don't want to change this, just press ENTER. The whole deal here is shown in Fig. 21: Midi Music On/Off- Pressing 6 toggles whether or not you wish music to be played throughout the game. If you select Yes, then your game will require Windows Version 3.1 or better and a soundcard to play. Character Transparency On/Off- Pressing 7 toggles whether or not you want character transparency. This means that when you play your games, the player will blend into the background if transparency is selected, making a much more realistic view. If transparency is turned off, a big black box will be behind the player at all times. It's recomended that you have a 486 or better computer to use Transparency effects, otherwise your game will be too slow. Return To Menu- Select this by pressing 8 at the Edit File menu. Guess what- this option takes you back to the Main File Menu. Choice 2- Load File Select this option by pressing 2 at the Main File Menu. This takes you to a new screen that has a listing of all the main files in the RPG directory. Enter the filename you wish to load not including the .GAM extension! Choice 3- Save File Select this option by pressing 3 at the Main File Menu. This takes you to a screen that tells you that it's saving the main file. Remember- the filename has already been defined in the Edit File menu. Choice 4- Return To Main Menu By selecting 4 from the Main File Menu, you will return to the Main Menu. Edit Main Fight File(Option 6) Select this option by pressing 6 at the Main Menu. By doing so, you are taken into a new menu; the Main Fight File Menu (Fig. 22). The following options are presented to you: 1- Edit Enemy Strengths 2- Edit Teammate Variables 3- Load File 4- Save File 5- Return To Main Menu The Main Fight File is similar to the Main Game File, because it governs all the activity that goes on in the game with regards to fighting. The Main Fight File is the file the computer uses to decide which enemy the player will fight, who is on the player's team, etc. If there is to be fighting in your game, it is imperative that you create a Main Fight File, and include it's filename in the list of files that appear in the Main Game File. Choice 1- Edit Enemy Strengths Select this option by pressing 1 at the Main Fight File Menu. This takes you to a new screen such as the one in Fig. 23. In your RPG game, you can have up to 251 enemies that are either bosses or normal enemies. This is more than enough. This screen shows the filenames of the enemy files, and the skill levels of each enemy. Right now, all these should have no values in them. At the moment, you can only see some of the enemy listing. Press 2 (Next List) to cycle through the other enemy lists. Once you reach 250, pressing 2 again will take you back to the first. At the moment, no enemies are specified for use in your game (at this point, you haven't even created any enemies, but doing this will be discussed later). Let's say you have made an enemy file, and wanted that enemy to be included in your game. To include the enemy in your game, press 1 to edit one of the enemy slots (0-250). By pressing 1, you are brought to a new screen that prompts you as to which enemy slot you wish to edit. For now, just type 0 and press ENTER- we'll work on the first slot right now. Once you have selected which slot you wish to edit, a directory will be displayed on the screen showing all the filenames of the enemy files in the current directory. Note that they have an .ENE extension (for enemy). You haven't created any .ENE files yet, but there should be some already there in the directory. You are prompted as to which enemy you wish to include in your game. Type in the filename without the .ENE extension, or just press ENTER for no change. Once you have done this, you are prompted as to what skill the enemy is. I hope you remember all the way back in the Board Editor when you assigned the board a skill level (if you don't you's better go back and read it- it's in the Board Information part). All you did in the Board Editor was assign the board a number- any number that would become the board's skill level. If you assigned the board a skill of 1, then the computer would only let the player fight enemies of a skill value of 1. This part here is where you decide which enemies have which skills. The skill of the enemy must correspond to the skill of the board where that creature lurks. That's easy enough. Just assign the enemy a skill here (any value you want), or just press ENTER for no change. Let's say you gave this enemy a skill of 1. That means that it is possible that the player will fight this very enemy on any board assigned a skill of 1. You can do this over and over again for as many as 251 enemies. All you have to do is learn how to create enemy files first (in time, in time). The last option in the Enemy Strength Editor is 3, which takes you back to the Main Fight File Menu. Choice 2- Edit Teammate Variables Select this option by pressing 2 at the Main Fight File Menu. This takes you to a new screen (Fig. 24). This screen allows you to set the conditions under which certain characters are on your team when you go into battle mode. There can be up to 51 teammates in one game, but only 5 at a time may fight in any given battle. Teammates are optional- your character can go through the whole game without one friend, but it can make things a lot more interesting if you have multiple characters fighting at once. You create these characters with the Fighting Editor, which hasn't been explained yet, but don't worry about that for now. All you need to know right now is that you need at least one teammate file (your main character) in order to fight, but you can have many more as well. This screen allows you to declare the conditions that must be met for certain characters to be on your team. Right now what you see is a list of slots that say: Teammate X- None On Team If Variable 0 (!) = 0 The X is the slot number. "None" is where the filename of the teammate will go, and the last few numbers will be explained in a moment. Before that, however, it is necessary to give a brief explanation of variables. Since you've only learned a little bit of the programming language so far, you haven't learned about variables (refer to the programming section of this manual for more details). Let's trash this word variable for a second, and think about something else. Imagine you had a shoebox. What could you put in it? Shoes? Money? It doesn't matter. You could put just about anything little inside a shoebox. Let's say you had a piece of paper with the number 800 written on it. You could put that in the shoebox, couldn't you? You could also put a piece of paper with words on it in a shoebox as well. Now, imagine you had hundreds, even thousands of shoeboxes. You'd never run out of things to put in them. The only problem is, how would you find something once you've put it in the shoebox and put that shoebox away with all the others? You'd never see it again! But what if you numbered every shoebox, and kept tract of what was in each on a piece of paper. You'd be able to find that thing you're looking for then. A variable is just a fancy word for a storage space- like a shoebox. You can out things in a shoebox and store them away. You can see what's in a shoebox. You could even take something out of a shoebox and put something else in it. It's the same way with variables. You can put just about anything in a variable, and, just like our shoeboxes, each one is numbered so you can find it, crack it open and see what's inside. With the programming language that comes with the toolkit, you have 2507 variables to work with. Each of these holds information, either a number, or a word. For now all you need to know is that there are 1506 variables that hold numbers. Each is assigned a number from 0-1505. Also, to show that they are variables that hold numbers, each label has an exclamation point after it (why not?). As an example, 5! would be the name of the 5th variable, and we know it holds a number, because it has a '!' after the '5' (actually, it's the 6th, variable, because 0! counts as a variable as well). In variable 5!, we could put any number. For example, we could put the number 1234 in variable 5! (this is like writing "1234" on a piece of paper and putting it in the 5th shoebox). Anyway, now that you know what a variable is, you can make some sese of this screen. Notice the statement "On Team If Variable 0 (!) = 0". All this means is that this particular player will be on your team if the number 0 is inside the variable 0!. To reassign these values, press 1 to edit one of the teammate slots. This takes you to a new screen which asks you which teammate you wish to edit. For now, let's just say we want to work on slot 0. Press 0 at the prompt. Now a directory of all the teammate (*.TEM) files is listed in front of you. We haven't made teammate files yet, so don't worry. All you have to know is that you can just type a filename here without the .TEM extension, or you can just press ENTER for no change. Next, you are asked which variable the condition rests on. That means that it's asking you for the number of the variable it has to check to see if this player is on your team or not. The default is 0!. I recommend using a different variable. Be sure to keep track of what information each variable contains! Just type in a variable like 100 here, or press ENTER for no change. Next, it asks you what value must be in that variable if this player will be on your team. Never, ever use 0!!! By default, every number variable is set to 0, so be careful! We've already said that the computer will have to check variable 100! to see if the player is on the team or not. Now we get to say what number the computer looks for. Just type in something like 5, or press ENTER for no change. If you typed in 5, that means this: Variable 100! will have to have the number 5 in it to have this guy on the team. Getting back to our shoebox analogy, this is similar to saying: Shoebox 100 better have that piece of paper with 5 written on it, or else you're not on my team! And what if the computer checks variable 100!, and 5 is not in it? The player isn't on the team. It's that simple. How does the 5 get there in the first place? You put it there with the programming language. I really recommend reading the section on programming before venturing any further into the fighting editor, because it deals heavily with variables. Anyway, if you're royally confused, just leave this alone for a little while, and once you've started with the programming, come back. As for the rest of this screen, press 2 to see the other teammate slots, and 3 to return to the Main Fight File Menu. Choice 3- Load File To load a file, press 3 at the Main Fight File Menu. This takes you into a new screen that has a directory of all the Main Fight Files (*.FGT) in the RPG directory. Type in a filename to load without the .FGT extension!, or type EXIT to return to the menu. Choice 4- Save File To save a file, press 4 at the Main Fight File Menu. You will be prompted as to the name you wish to save it as. Type in a filename (max. 8 characters with no extension), and press ENTER, or type EXIT to return to the menu. Choice 5- Return To Main Menu Press 5 at the Main Fight File Menu to return to the main menu. Clear Data(Option 3) From time to time your workspace may get crowded with facts and figures within the Toolkit, and you just want a clean slate to work with. You can do this by using the Clear Data command. Select this option by pressing 3 at the Main Menu. This brings you to a new menu that asks you if you really want to clear the computer's memory. Keep in mind that clearing the memory will erase any work currently in memory, so you may want to select option 2 to go back and save any data you may have (boards, programs, etc). If you wish to clear the data at this time, press 1 at the Clear Data menu. Exit(Option 8) To exit to DOS (or Windows), press 7 at the Main Menu. This will take you to a new menu asking if you really wish to quit. Keep in mind that if you quit to DOS, all data currently in memory will be lost. You may wish to go back and save your data (press 2- Return To Main Menu). If you wish to exit, however, press 1 at the menu. Run RPG Fighting Editor(Option 9) This option takes you to the RPG Fighting Editor- a Toolkit program that lets you create fighting scenarios for fighting in your games (these scenarios are controlled by the Main Fight File which was discussed a few pages back). By selecting 8 at the Main Menu, the RPG Fighting Editor program will start. This is a completely independent program, so running it means that all data in memory will be erased before it starts. This means that you may wish to save your work before selecting this. This option has no "are you sure?" prompt. Selecting it will immediately erase all data. Only select this if you are sure you have everything saved, or that you don't need what is currently in memory. The RPG Fighting Editor will be discussed in detail in the following sections. Your games don't require fighting sequences, but they make them more interesting. So far, you have learned enough to create your own simple games. As you will soon see, however, you have only touched the tip of the iceberg. The Fighting Editor Starting The Program You may start the Fighting Editor from the Main Toolkit screen by selecting it or by running it directly from Dos or Windows. There are a number of ways to start the RPG Toolkit Development System Fighting Editor. We have already discussed how to run it from the RPG Toolkit. To run it from DOS, first switch into the RPG directory (this was discussed on page 1). At the DOS prompt, type: RPGFIGHT to begin the program. To run the program from Windows or Windows 95, refer to page 1 for details on running from these systems, replacing the RPG filename with RPGFIGHT. Assuming you were successful in your attempts, you should now see a screen similar to Fig. 25. Press any key, and you will come to a new screen that asks what screen mode you're working with (identical to the one at the first of the RPG Main Editor program) this was discussed way back on page 2. Go there if you're lost. If not, type in your screen mode and press ENTER. Once you have selected a screen mode, you will be taken to the RPG Fighting Editor Main Menu (Fig. 26). This menu has the following options: 1- Edit Background 2- Edit Tile 3- Clear Data 4- Edit Teammates 5- Edit Enemy Files 6- Edit Special Move 7- Exit 8- Run Main RPG Editor Some of these options may be familiar to you, because some of them appear in the RPG Main Editor as well. There isn't really much new to learn in the Fighting Editor, but these options will be discussed in detail in a logical order in the following sections... Edit Background(Option 1) Select this option by pressing 1 at the Fighting Editor Main Menu. This will take you to the Background Editor Main Menu (Fig. 27). The menu has the following choices: 1- Edit Background 2- Save Background 3- Return To Main Menu These will be discussed later. First, I must explain what a background is. A background is similar to a board in the way it is made. Really, all a background is is a graphic screen that serves as a backdrop for your players to fight in. A background has no effect on game play; it just looks cool, and cool is what we want when we start to make a game. Choice 1- Edit Background To edit a new background or load a background, press 1 at the Background Editor Menu. This takes you into a screen that shows a list of all the background (*.BKG) files in the RPG directory. Seem familiar? It should, because it's the exact setup the Board Editor works on. To load a file, just type in the filename without the .BKG extension, or type NEW to create a new background. You can type EXIT to return to the menu. For now, just type NEW. This takes you into a new screen that asks you what the name of the background is. This will be the filename, so keep it less than 8 characters and do not include the .BKG extension. Once you have entered the filename, you are prompted what the background color will be. This option is identical to the same one in the Board Editor. There's no need to repeat myself- if you forget what it does, check back in the Board Editor section, or just press ENTER here. Once you've done all this, you will enter the Background Editor. The Background Editor, as you can see, is strikingly similar to the Board Editor, except that it's smaller (19 X 7 tiles). Take a look at Fig. 28. It's smaller to make room for the battle commands that will be in place when the game is played. Don't worry about that. The computer worries for you. To begin, press H at get a lowdown on all the commands used in the Background Editor. Doing this takes you to a help screen similar to the one for the Board Editor, except there are less commands (Fig. 29). You see that there are only drawing commands. That's good, because backgrounds are just big graphics- nothing more. Press any key to get back into the Background Editor. Now, let's start creating a background. Just as with the Board Editor, press S to select a tile to work with, and once you have done so, press SPACEBAR to place these tiles on the board. To erase a tile, position the cursor over that tile, and press E to erase it. The last command in the Background Editor is M, which takes you back to the Background Editor Main Menu. You load files just as you would with the Board Editor; that is, when prompted for a filename on your way into the Background Editor, type a filename (no extension) instead of typing NEW. Either start another new background, or finish the one you have started to make a nice looking one. Fig. 30 shows what a finished background might look like. Once you have finished your background, press M to return to the Background Editor Main Menu. The next section talks about how to save your file (though you probably have a good idea as to how it's done). Choice 2- Save Background To save the background currently in memory, press 2 at the Background Editor Main Menu. This will save your file as the filename you gave it at the start of the Background Editor. Ignore any error messages you might get- they affect neither the file you are saving nor the program's run time. Choice 3- Return To Main Menu To return to the Fighting Editor Main Menu, press 3 at the Background Editor Main Menu. Choice 4- Return To Current Background (not always there) If you have been working on a background and you have left the Background Editor by pressing M, this option appears on the menu. It allows you to return to the Background currently in memory and edit it. Select this option by pressing 4 at the Background Editor Main Menu. Edit Tile(Option 2) By pressing 2 at the Fighting Editor Main Menu, you are taken to the Tile Editor Main Menu. The Tile Editor for the Fighting Editor is identical to that for the Main RPG Toolkit Program. There's no need to repeat what it does here. If you forget, flip back to page 3. Edit Teammates(Option 4) The Toolkit allows you to create teammates for your main character that will aid him/her in battle. Up to 5 characters can fight at once. Don't worry about that. The computer decides who will fight. If you did what I told you to in that tip box way back at the Main Fight File, then the main character will always be guaranteed a spot in the fighting. You may want to have multiple characters and you may not. Whatever you choose, keep in mind that you must create at least one teammate file- the one that the main character uses. To create a teammate file, select 4 at the Fighting Editor Main Menu. This takes you to a new menu- the Teammate Menu (Fig. 31). This menu has the following options: 1- Edit Attributes 2- Save Teammate 3- Load Teammate 4- Return To Main Menu These options will be discussed in the following pages: Choice 1- Edit Attributes Press 1 from the Teammate Menu to edit the teammate's attributes. The attributes are just a bunch of statistics that help the computer construct a character when it comes time. You will see a new screen before you with a whole lot of statistical information (Fig. 32). Don't worry much about all the stuff on the screen. A lot of it is very similar, and there isn't really much to learn here. You see the following things displayed on the screen: -Teammate filename. -Official name of teammate. -Location of the teammate's experience variable. -Whether or not the teammate does special moves. -Location of the teammate's defence power variable. -Location of the fight power variable. -Location of the health power variable. -The at rest graphic. -The fight posture graphic. -The defensive posture graphic. -The unconscious graphic. Changing each of these things will be discussed in detail in the following pages... To change the filename of the teammate file, press A at the attributes screen. This takes you to a prompt and asks you what the new filename should be. Type in a new filename without the .TEM extension, or type EXIT to return to the attributes screen. The official name of the teammate is the name that is displayed to the player in battles. To change this name, press B at the attributes screen, and you are taken to another screen. At the prompt, type in the new name and press ENTER, or type EXIT for no change. The name can be as long as you want, but the computer will cut it down to 8 characters when the game is being played because of space limitations on the fighting screen. The experience variable of the teammate is just a variable name. Before you read any further, if you don't know what a variable is, flip back to page 29 for an explanation. To change the experience variable, press C at the attributes screen. This takes you to a new screen asking you what the new experience variable should be. The experience variable is the variable that holds a number that the computer uses as the teammate's experience level. The experience level is just a number that the computer uses to determine whether the teammate is experienced enough to do certain special moves or not. Throughout the course of the game, you can control what value is inside the experience variable through the programming language (and you'll have to). Don't worry right now. This is all covered in the programming section later on. To make things simpler, when a battle starts, the computer looks in the teammate file for the experience variable. Let's say the experience variable is 500! (the '!' is just to show that this variable holds numbers, not words). If the experience variable is 500!, then the computer will look at the value stored in variable 500!. Let's say that variable 500! contains the value 100. In this case, 100 is the experience level of the player. The computer then determines which special moves the player can do based on this experience level (for example, the player can do one move that requires experience 50, because the level is 100, but the teammate can't do a move that requires an experience of 150). Just remember that the value you put in here isn't the experience level, it's the variable that holds the experience level. Type in the variable that holds the experience value. Let's just say it's variable 500. Type in 500 and press ENTER, or type EXIT to return to the attributes menu with no change. Be sure to write down that variable 500! has the experience variable for this particular teammate. Always keep track of what every variable does so you won't get them confused!!! Also, keep in mind that the variable can be in the range of 0!-1500! (1501!-1505! are special reserved variables that are discussed in the programming section). Okay. Now that we're through that experience variable nonsense, the rest should be pretty easy (assuming, of course, that you understood what I said up there). The next command is a bit of a big one. Press D to change whether this teammate does special moves or not. If before this said 'Y', then we're fine. It'll just say 'N' now. If, however, it said 'N' before, we find ourselves in this new screen blinking our eyes and trying to figure out what happened (Fig. 33). Before I go and explain this new screen, I should probably tell you what a special move is (especially since I've been talking about them for awhile). In battle mode when the game is played, there are two ways to fight your enemy: Normal fighting, or using a Special Move. Normal fighting gets tedious after awhile, and it livens things up a bit if the player can do something really special that can take a lot of energy off the enemy (or hardly any- whatever you want). Special moves are just that- they are moves you create (this is discussed later) to give your players more fighting advantage and to make things look cool. That's all. This screen simply lets you assign the teammate different special moves. This screen shows the following things: -The graphic of the special move stance. -The official name of the special moves. -The special move power variable. -A list of 30 possible special moves assigned to this player. This is actually pretty easy to set up. First of all, let's change the special move graphic. This is the tile graphic that is put in place of the player on the screen that shows him/her doing their special move. It's just a tile graphic that shows your player doing something special. To change this graphic, press 1. This will take you to a screen that shows a directory of all the *.GPH files in the RPG directory. Type in the filename you want without the .GPH extension. Once you press ENTER, this filename will now be filled into the spot where it belongs on the special move screen. The official name of the special moves is the name that appears to the player while in battle. Each special move has its own name, but there is a menu heading in the battle mode that has the name of what the special moves are know collectively. By default, it's set to "Sp'l Move", which I'm sure you more observant types recognised to mean "Special Move". That name is okay, but hey, this is your game. Shouldn't you be allowed to decide what they're called? To change this name, press 2, and enter the new name at the prompt. Try to keep it less than 8 characters, because that's all the computer will show anyway when it comes time to fight. The special move power variable is the variable that contains the current amount of energy this teammate has to do special moves with. If you want (and you should, since it makes the game a little more challenging), you can make special moves cost your players energy. The amount of energy the player has is stored in the special move power variable. To change what this variable is, press 3. This will take you to a new screen that asks you what the variable should be. If you're kind of confused, this is that same kind of concept behind the experience variable. Type in the variable (let's say 208!), and press ENTER. Remember to keep track of what each variable does! You'll thank yourself later if you do. Now, do you see that big list at the bottom of the screen? That's a list of all the special moves the teammate can do. To add a special move to the list, press 4. This will take you to a new screen that asks you which special move slot you wish to edit (from 1-30). Just type 1 for now, or type EXIT to go back to the special move screen. Next, a directory of all the special move (*.SPC) files in the current directory (\RPG\) will be displayed. These are files that contain all the stuff a special move does, and you'll learn how to make them later. Before you get to type in a filename, you're asked what the minimum experience level of the player must be in order to use this move (remember the experience variable?). Type in a number- any number. If you type 100, then the computer will look in the experience variable for a value. If it's above 100, then the player can do this move, if not, then the player had better get some more experience first. You can just press ENTER for no change. Next you are prompted as to what the filename of this particular special move is. Type in a filename with no .SPC extension, or just press ENTER for no change. Once you've done this, you are taken back to the special moves screen, and now in slot 1, the name of the special move is there. Now that we've gone through all that, press 5 to return to the attributes screen. Okay, now that we're back at the attributes screen, everything should go nicely. The next option on the list is the defensive variable. Press E to change this. This takes you to a new screen that asks you what you want the new defensive variable to be. Type in a variable (from 0!-1500!), and press ENTER, or type EXIT to return with no change. As with the experience variable, this is a declaration of the variable that holds the defensive power value, not the defensive power itself. Throughout the game, defensive power is used to determine how well the teammate can defend himself from enemy attacks. The higher the defensive value, the better able the player is to withstand attacks. The way most RPG games determine this number is based upon certain types of armour or something the player is wearing. You'll learn how to control all of this through the programming language later on in the programming section. Also, write down which variable holds this value so you don't end up confusing the situation. Next, we'll change the fight power variable. Just like the defence variable, this is the variable which holds the fight power, not the fight power value itself. To change this, press F at the attributes screen, and you are prompted for a new variable. Type one in (in the range of 0!-1500!), and press ENTER, or type EXIT to return with no change. The fight power is a value that determines how much energy the player will take off enemies. The higher the number, the more will be taken off. The next and most important of all these variables is the health variable. This variable holds a number that is used to represent the player's health at any given time. As the enemy beats up the player, the health will decrease. When it reaches 0, the player becomes unconscious. To change the variable that holds the health value, press G at the attributes screen. At this screen, you are asked which variable holds the HP value. Type in a variable (from 0!-1500!) and press ENTER, or press ENTER for no change. Next you are asked for the variable that holds the maximum HP for the player. The value stored in this variable is the maximum HP allowable for this player. That way, when you give him/her more HP, you don't go overboard and have an invincible player with a million HP. Enter the variable that holds the max. HP and press ENTER, or just press ENTER for no change. As usual, write down which variables hold these values so you don't end up assigning them to some other player, too. Also, keep in mind that when you start the game, using the programming language you must put a value in the HP variable and the Max HP variable, because they're both automatically set to zero. If you don't your player's HP will always be zero, and he/she won't be able to fight. Alright, we're moving along quite well. The next four things on the menu are real no brainer stuff- really easy. These are the graphics that the computer uses to show where your player is on the screen in a fighting sequence. The first graphic is the "at rest" graphic. This is the graphic that is shown whenever the player isn't doing anything. You must have an at rest graphic. To change it, press H at the attributes screen. This takes you to a new screen that has a directory of all the graphic tiles (*.GPH) in the RPG directory. Type in a filename to use with no .GPH extension, or type EXIT for no change. The next three graphics are assigned in the very same way. To change the fight posture- that is, the graphic the computer uses when the player hits the enemy normally, press I at the attributes screen. Assigning this is just the same as assigning the at rest graphic. To change the defensive posture- the graphic that is used every time the player is hit by the enemy or defends him/herself, press J at the attributes menu. You assign this the same way you did the last two graphics. Finally, to change the unconscious graphic- that is, the graphic displayed when the teammate is unconscious, press K at the attributes menu. Assigning this graphic is the same as the last three you did. At last we come to the end of this attributes screen. To exit it and return to the Teammate Menu, press L. That brings us back, and believe it or not, we've just created an entire character. Choice 2- Save Teammate Once you have edited everything in the attributes screen, you'll want to save this teammate. To do this, press 2 at the Teammate screen. This will save the teammate as the filename defined in the attributes screen. Great. Now you have a teammate file, but how do you use it in a game? Look way back on pages 28-29 on assigning teammate variables and it should all come back to you. Choice 3- Load Teammate To load a teammate from the hard drive, press 3 at the teammate menu. This takes you to a new screen with a directory of all the teammate files in the current directory (\RPG\). Type in a filename without the .TEM extension, or type EXIT to return to the menu. Now the teammate is in memory, ready to be edited in that attributes screen. Choice 4- Return To Main Menu To return to the Fighting Editor Main Menu, press 4 at the Teammate menu. Edit Enemy Files(Option 5) So far we've talked about making files to create characters that will be on the player's team to fight enemies. In this section we'll discuss the actual making of an enemy for use in your games. To edit an enemy, select option 5 from the Fighting Editor Menu. Doing so will bring up a new menu (Fig. 34). This menu has the following choices: 1- Edit Graphic 2- Edit Attributes 3- Save Enemy File 4- Load Enemy File 5- Return To Main Menu Creating and using enemies are not nearly as hard or complicated as creating teammates. That's because teammates must be able to be controlled by a person. Enemies are controlled by the computer, though, so the enemies were designed to be easier to make. First of all, we must create a graphic for the enemy. This is discussed in the following section... Choice 1- Edit Graphic Okay. Creating enemy graphics is really easy. First of all, press 1 from the Enemy Menu, and you are taken to a new menu that asks you whether or not you wish to edit the enemy graphic against a background. When you edit an enemy against a background, the computer loads a previously saved background and lets you edit the enemy on top of it. This can be confusing, however, because you could get mixed up as to which tiles are actually part of the enemy and which ones are part of the background. For simplicity's sake, it may be convenient for you to not edit the enemy against a background for now. If, though, you are keeping careful track of what is on your backgrounds, or you are creating an enemy specifically for a certain background, you may wish to edit against an existing background. If you do, keep in mind that the graphics of the background are not considered part of the enemy file and are not saved with the enemy. If you wish to edit against a background, press 1. This takes you to a screen that shows a listing of all the background (*.BKG) files in the current directory. Type the name of the background you wish to edit against. This will take you into the graphics editor. If you don't want to edit against a background, press 2. This takes you directly to the graphics editor. To return to the Enemy Menu, press 3. Now you should be in what looks like the Background Editor. If you chose to edit against a background, there is a background graphic on the screen. If not, the screen is empty. Now all you do is put a few tiles down to represent an enemy. The controls for this screen are identical to those in the background editor. Remember- if you are editing against a background, the background graphic isn't saved as part of the enemy. When the program runs a battle sequence, the first thing it does is load a background. Then it loads the enemy graphic and puts it over the background. You should draw your enemy on the left side of the screen since the players are placed on the right side of the screen. Just put in some tiles to represent the enemy (Fig. 35). When you're done, press M to return to the Enemy Menu. Choice 2- Edit Attributes Attributes. You remember that word from the teammates, don't you? Don't worry, the enemy attributes aren't as complex as the teammate attributes. To edit the enemy's attributes, press 2 at the Enemy Menu. This takes you to a new screen that has the following information (Fig. 36): - The enemy's filename. - The enemy's name. - The enemy's Health Power. - The enemy's Special Move Power. - The enemy's Defensive Power. - The enemy's Fighting Power. - The program that is run upon defeat of the enemy. - Whether or not the players can run from the enemy. - 10 weaknesses. - 10 special moves. Alright. To change the filename of the enemy file, press A this prompts you as to what the new filename should be. Type in a name with no extension, or just type EXIT for no change. To change the enemy's name (the name that is used in the fighting sequences), press B at the attributes screen. This prompts you for a new name. The name can be as long as you want, but only the first 8 letters will be shown to the player (to conserve space on the screen). Type in a new name, or just Type EXIT for no change. In this screen, you are asked whether you want a set name or a variable name. A set name is a name that won't change, but the variable name is a name that is taken from a literal variable, and so may change. If you specify a Variable name, you must enter the variable number with NO $ SIGN! To change the enemy's Health Power, press C. This takes you to a prompt that asks you what the HP of the enemy is. Unlike the teammates, this is not referring to a variable. For enemies, all numbers like HP, DP, FP, etc. are not stored in variables like players that can be changed by you, the game maker, through the programming language. With enemies, you just type in a number, and the computer takes care of the rest. If you want the enemy's HP to be 100, type in 100 and press ENTER. That's it. No reference to variables at all. Just type EXIT to have no change. To change the enemy's Special Move Power, press D. This is the amount of energy an enemy has to do special moves. Every time a player or an enemy uses a special move, they must use up some of this power. If they don't have enough power, they can't do the move. Type in a new value, or just type EXIT for no change. Just like the HP, this is the actual number, not the number of a variable. To change the enemy's Defensive Power, press E. The defensive power is a number that determines how well an enemy can defend itself from attack. The higher the value, the better able it is to do so. Enter a new value, or just type EXIT for no change. To change the enemy's Fight Power, press F. The fight power is a value that determines how hard the enemy will hit a player when it does so. The higher the value, the more health it will take off the player. Enter a value here, or just type EXIT for no change. To change the defeat program, press G. The defeat program is a program written with the RPG Toolkit Programming Language that is run if the player defeats the enemy. This program is intended to give the player bonuses such as experience points when they defeat this enemy. When the enemy is defeated, this program is run, and when it is finished, the player returns to the board from which he/she came before entering the battle mode. Of course, you don't have to have a program here. Anyway, when you select this, a list of all the program (*.PRG) files in the directory is shown. Select a new file (with no extension), or type EXIT for no change. During a battle, the player may have an option to run from an enemy, thus ending the battle. To select whether or not the player can run from the enemy, press H. If the option was previously set to No, then you are taken to a new screen that gives a listing of all the program (*.PRG) files in the current directory. Here you are asked which program will be run if the players run from the enemy. A program may be useful to cause some sort of penalty to come upon the players if they run, so that they aren't constantly running from enemies throughout the game. For example, if a player runs from an enemy, a program could be run that would take an item from him if he did so. Of course, you don't have to have a program. Type in a filename (no extension), or type EXIT to return to the attributes screen. Now, then, to change enemy weaknesses, press I. The enemy may have special weaknesses to up to 10 special moves that might be performed upon them. If the enemy is ever hit by one of these special moves, it will take off more health than usual. It is not required for the enemy to have weaknesses, though. If you wish for the enemy to have weaknesses, though, once you have selected this option from the attributes screen, you are taken to a new screen with the prompt "Which Weakness (0-9)", or something like that. Press a number from 0-9 to indicate which weakness you wish to edit. Once you do this, you are shown a listing of all the special move files (*.SPC) in the current directory. In the next section, we will talk about making these special move files, but until then, just type in a filename (no extension), or type EXIT to return to the attributes menu. Just like the teammates, enemies can perform special moves that can be devastating on the player, thus making the enemy harder to defeat. An enemy can have up to 10 special moves, which is more than enough for 1 battle. Of course, the enemy doesn't have to do special moves, but it would be interesting if it did. To edit the special moves it can do, press J. This takes you to a new screen that asks you which special move you wish to edit (0-9?). Press a number from 0-9. Next, you are shown a listing of all the special move files (*.SPC) in the RPG directory. Type in a filename (no extension), or type EXIT to return to the attributes screen. Finally, to exit the attributes screen and return to the Enemy menu, press K. Option 3- Save Enemy File To save the enemy you have been working on, press 3 at the Enemy Menu. If you haven't given the enemy a filename in the attributes menu, it won't save. If this is the case, go into the attributes menu and give it a filename. Option 4- Load Enemy File To load an enemy, press 4 from the Enemy Menu. This takes you to a new screen with a listing of all the enemy (*.ENE) files in the RPG directory. Select a file to load with no extension and press ENTER. Once the file has loaded, you will be sent to the graphics editor and shown the enemy graphic. You may edit it, or just get back to the Enemy Menu by pressing M. From there you can edit the attributes. Option 5- Return To Main Menu To return to the Fighting Editor Main Menu, press 5. Option 6- Return To Enemy Graphic (not always there) If you have been working on an enemy graphic, and have returned to the Enemy Menu, you may return to the graphic by pressing 6. Edit Special Move(Option 6) Special Moves are offensive moves performed by the player that are invented by you. Special Moves can be used to take off more than the usual amount of health, or they can be used to restore health. Special Moves can also have a lot of cool special effects that make them even more special. To create a Special Move, press 6 from the Fighting Editor Main Menu. This takes you to a new menu (Fig. 36). It has the following choices: 1- Edit Program 2- Import Program 3- Edit Attributes 4- Save Special Move 5- Load Special Move 6- Return To Main Menu The choices are discussed in the following sections: Option 1- Edit Program When a Special Move is run, a program is run as well so that special effects can be splashed across the screen. Of course, you have to make this program yourself. You can do this by using the Programming Editor like was discussed a while ago. To enter the Programming Editor, press 1 at the Special Move Editor Menu. Remember- it strongly suggest that you use a word processor instead of the Programming Editor to create your programs. Be sure to save your programs with a .PRG extension, and to save them as ASCII, Text, Plain Text, or whatever it is you word processor calls it. Long program especially carry this recommendation. If you are writing little programs, though, the Programming Editor may be convenient enough to serve your purposes. I have already gone over how to use the Programming Editor. If you forget how, refer back to page 17 for all the details. Option 2- Import Program This option lets you import a program already saved to disk into this special move. This option was originally created to allow you to import programs that you have written using a word processor or text editor (as long as those files are saved as ASCII and have the .SPC extension). It can be used to import programs already created with the Programming Editor, however. If you wish to import a program, press 2 at the Special Move Menu. This takes you to a screen that shows you a listing of all the program (*.PRG) files in the current directory. Enter a filename with no extension, or type EXIT to return to the Special Move Menu. Once you have typed a filename, the program will load, and then you will be taken into the Programming Editor where a listing of the imported program is shown. Option 3- Edit Attributes So far, all we have done is create a program that will produce special effects when the Special Move is used. Currently, though, the Special Move will take no health off an enemy, and it has no name. To edit such attributes, press 3 at the Special Move Menu. This takes you to a new screen that has the attributes for the current move (Fig. 38). This screen shows you the following things: - The filename of the Special Move. - The name of the Special Move. - The Fight Power of the Special Move. - The Special Move Power Consumption. There aren't many attributes for a Special Move, which is why they are so easy to make. To edit the filename, press 1. Enter a new filename with no extension, or type EXIT to return to the attributes screen. To edit the name of the Special Move; that is, the name that they player will see when fighting, press 2. This takes you to a prompt that asks you what you want the name to be. Enter a new name, or type EXIT to return to the attributes screen. The name can be as long as you want, but in the action window of the fighting sequence, only the first eight letters will be shown to conserve space. (If the player wishes to do the move, however, the name will appear in another window in full). To edit the Fight Power of the move, press 3. The Fight Power is a number that determines how much health the move will take off an enemy based upon how well the enemy is able to defend itself. The higher the number, the harder the hit. Enter a new value here, or type EXIT to return to the attributes screen. Keep in mind that you are not entering the location of a variable like you did with the Teammate files. Rather, this is the actual value that will be used as the Fight Power. The next thing to edit is the Special Move Power Consumption. Since Special Moves can be used to give health to your players or take high amounts of health off enemies, you can make it so that each time a player uses this Special Move, he/she will have to "pay" for it with some of their Special Move Power (refer to page 40 for more details on this). Even enemies must abide by this law of power consumption when they do a Special Move. To change how much power using this Special Move takes off, press 4 at the attributes screen. This takes you to a prompt that asks you how much it takes off. Enter any value, but at least make it reasonable enough so that your players might possibly have enough power to use it. It can be 0 if you wish. Enter a new value, or type EXIT to return to the attributes screen. Believe it or not, but that's everything there is to making a Special Move. Press 5 from the attributes screen to return to the Special Move Menu. Option 4- Save Special Move To save the Special Move you have just created, press 4 at the Special Move Menu. Since you have already entered what the filename of the Special Move is in the attributes screen, it will just save the file. Option 5- Load Special Move To load a Special Move, press 5 at the Special Move Menu. This takes you to a new screen that shows a listing of all the Special Move files in the RPG directory. Enter a filename to load (no extension), or type EXIT to return to the Menu. Once you have entered a filename, the file will load and then you will be taken to the Programming Editor where a listing of the Special Move's program will be shown. Option 6- Return To Main Menu To return to the Fighting Editor Main Menu, press 6 at the Special Move Menu. Option 7- Return To Current Program (not always there) If you have been working on a program in the Programming Editor, and you returned to the Menu, this option appears. To return to the program you have been working on, press 7. Clear Data(Option 3) Select this option by pressing 3 from the Fighting Editor Main Menu. This option clears everything currently in memory. It works exactly the same as it does in the Main Toolkit Program. Refer to page 31 for more information. Exit(Option 7) This option allows you to exit to DOS (or Windows). Select it by pressing 7 from the Fighting Editor Main Menu. It works the same as it did in the Main Toolkit Program. Refer to page 32 for more information. Run Main RPG Editor(Option 8) This option allows you to return to the Main RPG Toolkit Program where you can edit boards and other components of the game you are working on. By selecting 8 at the Fighting Editor Main Menu, the Main RPG Toolkit Program will be invoked. All data in memory will be erased before this begins, so it is a good idea to save you work first. This option has no "are you sure?" prompt. Selecting this will immediately erase all data. Select this option only if you are sure that whatever is in memory is either saved or is information that you don't need. So far you have learned almost everything you need to know to create a pretty good game, complete with fighting sequences. You will want to let your players interact with other characters in the game, however, and now and then create special effects sequences. These things and more are achieved with the RPG Toolkit Development System Programming Language, called RPGCode. References to this programming language have been made all throughout his manual so far, and you have even learned a few commands (pages 20, 21). In the next section, RPGCode will be discussed in great detail. Once you have learned this facet of the Toolkit, you will wonder how your games ever got along without it, because RPGCode brings great flexibility to what you are able to do. Enough introductions. Turn the page, and let's get programming! Programming In RPGCode Introduction RPGCode is an extremely simple and flexible programming language designed specifically for use with the RPG Toolkit Development System. You will find that you can do almost anything you want with this language to make your games more interesting. The programs themselves can be created using the Programming Editor in the Toolkit, or you can use a word processor or text editor. If you do not use the Programming Editor, be sure to save your files as ASCII, text, plain text, or whatever your program calls it. Also be sure to save the files with the .PRG extension. Throughout this section, all commands are in bold print, just to show that they are commands and not text. If you are familiar with programming, you might want to just skim over the next section. Chances are you know everything that is discussed here already, but there are a few things unique to RPGCode dealing with such things as variable names and manipulation. If you have never programmed before, great. This way you will be starting on a new platform that will be built up specifically around RPGCode. There are small things unique to this language, and they won't seem as strange to you since you have no experience with other languages. Also, RPGCode is a simple language that will allow you to learn the basic concepts of programming, so if you ever desired to learn another language, particularly BASIC, it would be much easier for you. Whoever you are, I'm sure that you will find this language to be an invaluable resource in creating your own games. A Short Review This section contains a review of some things that you should already be familiar with in programming that was discussed previously in this manual. The simplest command in RPGCode is just typing text all by itself on a line of code. Here's an example: Text all by itself (how sad). Any time a program is run, and there is text all by itself like this, the text is displayed in the Message Window of the screen. The Message Window is just a box at the top of the screen that shows text like this four lines at a time. If there is more that four lines of text, the computer waits for the user to press a key, and the next lines are shown (Fig 39). This is the most basic of all commands. When you leave lines blank in a program, they are simply ignored. If you wish to have blank lines in the Message Window, just put the '@' symbol on a line all by itself. When the computer encounters this, it places a blank line in the Message Window. If you have a bunch of text lines together, the computer will place them in the Message Window four lines at a time. If there are more lines ahead, then the computer will wait for the user to press a key before displaying them. This means that if you have 5 lines of text, then the computer will show the first four, wait for you to press a key. When you press a key, the last line will be put in the Message Window, but since that's the end of the program, the Message Window will be erased from the screen and the board will be restored to the way it was before the program began. Than means that you will have no time to read the last line before it vanishes. To remedy this situation, put a bunch of @'s (blank lines) after the last line of text until you have more than 4 lines after the last line of text. This ensures that the computer will wait for the user to press a key. There is, of course, a better way of doing this, but for now just use this. A third command which you should know is the comment command. Any line of code that starts with a '*' will be ignored by the computer. This is called commenting your code. The idea is to leave little notes to yourself in the code to help you remember what the program does. Comments must appear on a line by themselves. These three commands were discussed back on pages 20 and 21. Remember linking programs to tiles on a board (page 14)? For all the programs in this section and any you make yourself, you must first link the program to a board in this way, and then create a Main File that will load that board upon startup. Then you must run the Translator so that you can play on that board. Programs are executed when the player walks into the tile that contains the program (see the Translator section for more information). The next section deals with variables; a subject that you should be somewhat familiar with by now. Variables And The Basics Of Programming Computers were first developed as a way of forecasting the weather. Really. This was because computers could keep track of many variables at once. Variables are things that could change and effect the way the weather would turn out. Back in those days, computers were supposed to be able to predict the weather years in advance. What do you know, it didn't work. But who cares about the weather? Eventually, people recognized that they could use this ability to keep track of variables and calculations in other things. And so today, we have computers everywhere doing everything. Variables are the most basic of all programming concepts. All a variable is is a storage place where you can put numbers or words for safe keeping. You must remember the example of a variable being like a shoebox back on page 29. You can use variables to hold information that you can use later on. In RPGCode, there are two types of variables: numerical variables and literal variables. Numerical variables hold numbers. There are 1506 numerical variables that you can use. That's just like having 1506 boxes to put numbers in. Just a storage space. These variables can be used to store things like the amount of money your player might have, the health of your player, the experience of your player, etc. Literal variables hold words and sentences. There are 1001 literal variables that you can use in RPGCode. They can be used to store things like the player's name, or something like that. I also like to call literal variables "strings" because they are actually strings of letters put together. In professional programming, this is what they are called. Remember that strings and literal variables are the same thing, because I use them interchangeably from now on!!! In RPGCode, we refer to variables using their number to indicate which one we are using. For example, the 5th numerical variable is referred to as 5! (That '!' will be explained). The 100th literal variable is referred to as 100$ (Not $100. I'll explain why you put the dollars sign after the number in a moment). For numerical variables, these numbers range from 0 to 1505 (that's 1506 variables). For strings (literal variables), these variable numbers range from 0 to 1000 (That's 1001 string variables). Now, a problem arises. How do you tell numerical variable 1 from literal variable 1? They bother have the same numbers, after all. For numerical variables, always include a '!' after the variable number, and for strings, always include a '$' after the variable. This means that when I refer to variable 1!, I mean numerical variable 1, and when I refer to variable 1$, I'm talking about string variable 1. Assigning Values To Variables All this information is great, but how do we use it? How do we put stuff in variables and how do we get it out again? Before I tell you, maybe you should brush up on a little math. I'm sure you remember variables from your days of math. Remember those little letters that were used to represent numbers? In math, you put a value into a variable like this: x = 12 Of course, that puts the value 12 in the variable x. Similarly, with RPGCode, you just put values into a variable using an equal sign: #1! = 12 The command above assigns the number 12 to the numerical variable 1!. But what's with that '#' symbol? The '#' symbol is used to tell the computer that you are using a command. Anything that comes after # is a command. If we didn't have the '#' there, then "!1 = 12" would be put in the Message Window as text. Putting the '#' there just tells the computer that we don't want it to put that line of code in the Message Window. In RPGCode, all commands have the '#' symbol in front of them. This is so the computer knows that they are commands, not text. Just like you always put a '*' before a comment, you must always put a '#' before a command. Also, there must be no space between the '#' and the command. That means that: # 1! = 12 Would not be valid. There must be no spaces between the # and the command!!! Okay, so now we can put numbers in numerical variables, but how do we put words in literal variables? Like this: #1$ = "Hello" Notice that there are quotation marks around the word being placed into variable 1$. You must always put quotation marks around text like that when you are dealing with variables. You can also put the contents of one variable into another. Consider these lines of code: * Program showing variable use. #1!=12 * Puts the number 12 in the variable 1! #2!=1! * Puts the value of variable 1! (which is 12) in * variable 2! * Here's an example using strings: #1$="Hello" * Puts the word "Hello" in variable 1$ #2$=1$ * Puts the word in variable 1$ (which is "Hello") in * variable 2$ * Now let's see what's in these variables: Variable 1! has a value of: #Show 1! Variable 2! has a value of: #Show 2! Variable 1$ contains: #Show 1$ Variable 2$ contains: #Show 2$ @ Notice that all commands are in bold. I will continue to do this because it helps us to see better which lines are commands and which are lines of text and comments. Lets' go through this program step by step to see what goes on. The first line is a comment, so we'll just ignore that. Line 2 has this command: #1!=12 This stores the number 12 in the variable 1!. The next command looks like this: #2!=1! What this does is take the value in variable 1!, which is 12, and stores it in variable 2!. Now both 1! and 2! each store a value of 12. Notice that the things to the right of the equal sign (1!) are stored in the variable on the left of the equal sign (2!). This is the way it always is. The next command assigns a word to a string variable: #1$="Hello" This takes the word "Hello" and stores it in the literal variable 1$ (it doesn't store the quotation marks). The next command looks like this: #2$=1$ This takes whatever is stored in the variable 1$ (in this case, "Hello"), and stores it in the variable 2$. Now bother 1$ and 2$ each contain the word "Hello". The next commands just show what is in these variables. You know that the text all by itself is displayed in the Message Window, but you don't know what the #Show command does yet. The next two lines of code: Variable 1! has a value of: #Show 1! Do this: First, the text "Variable 1! has a value of:" is placed in the Message Window. Next, the #Show command shows what is stored in the variable 1!, placing the number 12 in the Message Window. All the #Show command does is take whatever is in the variable next to it and shows it in the Message Window. #Show is just one way of taking values out of variables and doing something with them. It is important to note that #Show doesn't actually take the value out of the variable and put it on the screen- nothing takes the value out of a variable- it just copies the contents of the variable to the screen. The last lines of code just show what is in each variable, and the final '@' (Blank line) is placed there to force the computer to wait for the user to press a key before erasing the Message Window (you will notice that there are 9 lines of text all together including the '@', #Show commands, and the plain text commands- that's 2 Message Windows full and one extra line left over (the '@')). You can type in this program and then link it to one of the tiles in a board. Create a Main File to load that board, and then run the Translator to see what the program does (skip ahead to the Translator section for info on running the Translator). Variables And Math Variables can also be used to perform mathematical calculations. For example, what if you wanted to give a player 200 extra pieces of gold? You would have to add 200 to the variable that contains the amount of gold the player has. In math, variables are assigned mathematical values like this: x = 12 + 18 Assigns the sum of 12 and 18 (30) to variable x. In math, this is also valid: x = y + 80 Assigns the sum of y and 80 to the variable x. Let's say the value in y were 20. That would mean that x would be equal to 100 (20 + 80). In RPGCode, these operations are done like this: #1! = 2! + 10 #8! = 3! - 4! #857! = 857! + 200 The first line (#1! = 2! + 10) takes the value of 2!, adds 10 to it, and then assigns this answer to 1!. If the value in 2! were 20, then 1! would equal 30 (20+10). The next line (#8!= 3! - 4!) takes the value of 4! and subtracts it from the value of 3!. The answer is stored in variable 8!. So if 3! were equal to 10 and 4! were equal to 7, then 8! would be equal to 3 (10-7). The last line (#857! = 857! + 200) is a little peculiar. In math, you'd never get away with saying that x = x + 1. It simply isn't possible. In programming, it is, though. The above statement takes the old value stored in 857!, adds 200 to it, and stores the answer in 857!. That means that if 857! had the number 100 stored in it originally, then it would now become equal to 300 (100+200). With RPGCode, you can do the four basic operations: + (addition), - (subtraction), / (division), and * (multiplication). You can only do one operation at a time, though. That means that: #2! = 12! / 8 * 500 Would have to be broken down into: #2! = 12! / 8 #2! = 2! * 500 Also, when you add, subtract, divide, or multiply a variable with a non variable, the variable must always come first. So: #1! = 8 + 2! Is invalid. It should be written like this: #1! = 2! + 8 Also, calculations must always involve at least 1 variable, so: #1! = 8 + 8 Is invalid. It should be written: #1! = 16 Now then, let's put this to use. Here's a program that gives the player 200 extra gold pieces: * Program demonstrating variable manipulation. * In this program, 1! is used to hold the amount * of gold the player has. #1!=40 * Starts the player off with 40 gold pieces. Right now, the player has this much gold: #Show 1! #1!=1!+200 * Adds 200 to the gold variable. Now the player has this much gold: #Show 1! @ At the start of this program, the player is given 40 gold pieces, because 1! is used to store how much gold the player has. This is the command: #1! = 40 Next, the player is shown how much gold he has (which is 40) with these commands: Right now, the player has this much gold: #Show 1! Now, the player is given 200 more gold pieces (this command takes the value of 1!, which is 40, adds 200 to it, and then assigns it to the variable 1!, so in the end, 1! ends up being worth 240, when it equalled 40 before): #1!=1!+200 The last few lines just show how much money the player has now after 200 gold pieces have been added to the gold variable. The final '@' is put there so that the computer will wait for the player to press a key (you will notice there are 5 lines altogether including the #Show commands, the text and the @). Really, that's about all there is to know about variables (except for the special reserved variables 1501!- 1505! which will be discussed later). Branching And If...Then Branching So far you know how to store values in variables and print them on the screen, but so what? Here's where this stuff comes in handy, but before I really get into that, I must discuss branching first. Branching is just a fancy term for "going somewhere else". In your programs, you can skip around to different sections as much as you want. This is called branching. If you were to go to a house that you had never been to before, you would probably need the street address in order to find it. Of course, there would have to be a number or a sign or something on the house corresponding to the address you were looking for, otherwise you'd never find it. Branching in your programs is no different. In order for the program to branch to other parts of the program, you have to put Labels in your program. Labels are just like signs. They tell the program where to branch to. A label can be a word, a number, a sentence, anything. The only thing you have to remember is that lines with labels on them must start with a ':'. The ':' tells the computer that this is a label, just like a '*' tells the computer that there is a comment, and a '#' means there is a command. Here's an example of a label: :Label 1 The above line is a label called ":Label 1". When a program is run and the computer comes across a label, it just ignores it. It's only when you tell the program to go to a certain label that the computer pays any attention to these labels. Labels can also be used to comment certain parts of your program, since they are ignored. It is strongly recommended that you use the comment symbol ('*') to put comments down, though. Now that you know how to put labels in your programs, how do you branch to them? You use the #Branch command. #Branch commands look like this: #Branch (:Label name) The command above branches to a label called :Label name. This is all great in theory, but let's see a working example: * Program demonstrating the #Branch command * and labels. Line 1 Line 2 Line 3 #Branch (:skipped) Line 4 * "Line 4" is skipped because of the #Branch * command. :skipped Line 5 @ The above program starts by putting "Line 1", "Line 2", etc. in the Message Window. Once it has put "Line 3" in the Message Window, however, it encounters the #Branch command. This particular command tells the program to branch to the label :skipped. The program jumps down to the label :skipped, and then puts "Line 5" in the Message Window. Notice that the line "Line 4" is skipped because of the #Branch statement. This means that the following will be shown in the Message Window: Line 1 Line 2 Line 3 Line 5 If...Then Branching is fine, but what good is it? Here's where I introduce the most powerful command in RPGCode. The #If...Then command. #If...Then is used in every programming language in some for or another. This command is used to test if something is true. If it is, then a certain command is run (usually a #Branch command, but it can be any command). Here's an example of an #If...Then statement in spoken English: If I get to the zoo in time, then the monkeys will be freed. We use #If...Then statements all the time in our everyday life. Take the above example. I just used this one yesterday. What the above statement does, is test to see if something is true. It tests to see if "I get to the zoo in time" is true or not. If I did get to the zoo on time, then the condition is true, and the statement to the right of then is executed. In this case, since I got to the zoo in time, the monkeys were let free. If I didn't get to the zoo in time, meaning that the condition would be false, then the statement after the then wouldn't be run. In this case, I didn't get to the zoo in time, so the monkeys were not freed. We use this type of statement all the time in our everyday speech, and so does the computer every time you turn it on (you just don't see or hear it happening, because it's going on inside the computer). To the computer translating RPGCode, the statement looks like this: #If (condition) Then <#command> What is this condition the computer is testing to see if it's true or not? This is where variables come in handy. The computer checks if a variable is equal to something else, and if it is, then a command is executed. Here's an example: #If (1! = 12) Then < #Branch (:One Equals Twelve) > What the above statement does is check to see if the variable 1! has the value 12 in it. If it does, then the command #Branch (:One Equals Twelve) is executed, and the program branches to the label :One Equals Twelve, wherever that might be. If 1! doesn't equal 12, then the command in the "< >" brackets is not executed. You might find it useful not to include the Then part of the #If...Then statement. It isn't necessary, but it is recommended, because it makes the program easier for someone to read. Therefore, this example is valid and does the same thing as the above example: #If (1! = 12) < #Branch (:One Equals Twelve) > It works, but it sure looks ugly. That's why I stick with good old Then, because it makes things look nice. I will, however, be using these two methods interchangeably from now on to get you used to this aspect of the #If...Then command. #If...Then doesn't have to check if a variable is equal to something else, it can check other things as well. Using symbols other than '=' in the condition part of the command will yield different results. The following sections demonstrate the different symbols that you can use: Equal To (=) This tests if a variable is equal to another value. The command is only executed if the two values are equal to one another: #If (1$ = "Hello") Then <Hello to you, too.> The above command checks if the string "Hello" is stored in the variable 1$. If it is, then "Hello to you, too." is placed in the Message Window. Greater Than (>) This tests if a variable is greater than another value. If it is, then the command is executed: #If (1! > 40) Then < #Branch (:Another place) > In the above example, if the value stored in 1! were greater than 40, then the program would branch to the label :Another place. Less Than (<) This tests if a variable is less than another value. If it is, then the command is executed: #If (1! < 1000) < #Show 1! > If the value stored in 1! is less than 1000, then the value of 1! is placed in the Message Window (with the command #Show). Not Equal To (~) This tests if a variable isn't equal to another. If they aren't equal, then the command is executed: #If (1280! ~ 4) Then < #Branch (:Not equal) > If the value stored in 1280! isn't 4, then the program branches to the label :Not Equal. Using #Branch And #If...Then In Programs Now it's time to put what we've learned into a program. The following program is a program that sells things to the player, and won't sell them to him if he already has the item, or if he doesn't have enough money. This program uses everything we have learned so far, but it also has a new command, the #Get command. This command gets a value typed at the keyboard and stores it in a string variable. It will be explained more later. * A merchant program that sells items. * 1! will be used as the variable that stores * the amount of money the player has. * 2! tells the computer whether or not the player * has shopped at the store or not. 0 means he * hasn't. 1 means he has. * 1$ tells the computer whether or not the player * has a key. * 2$ tells the computer whether or not the player * has a sword. * First, let's give the player some money only * if they haven't shopped here before. #If (2! = 0) Then < #1! = 100 > * The above command sees whether or not the player * has shopped here before. If he hasn't then * 2! should equal 0, since 2! will be set to * 1 every time the player shops here. #2! = 1 * The above command makes sure the computer * remembers that the player has shopped here. * This is used in conjunction with the above * #If...Then statement. :Buying screen Hello, there. What would you like to buy? 1- A key (100 GP) 2- A sword (100 GP) 3- Nothing :Get a key #Get 3$ #If (3$="") Then <#Branch (:Get a key)> * The above group of commands gets a single * character from the keyboard buffer. If * no key was pressed (meaning that 3$ = "", or * nothing), then we branch back up to get a * character from the keyboard again. This continues * until a key is finally pressed (3$ no longer * equals ""). #If (3$="1") Then <#Branch (:Buy a key)> #If (3$="2") Then <#Branch (:Buy a sword)> #If (3$="3") Then <#Branch (:Thank You)> #Branch (:Get a key) * If they player pressed a key, then the program * goes onto this group of #If statements. * If he pressed "1" (3$="1"), then the program * branches to :Buy a key. * If he pressed "2" (3$="2"), then the program * branches to :Buy a sword. * If he pressed "3" (3$="3"), then the program * branches to :Thank You. * If he didn't press any of these choices, then we * branch back up to :Get a key to let him type * more keys until he types either 1, 2 or 3. :Buy a key #If (1$="Key") Then <#Branch (:Have)> * When a player buys a key, 1$ is set to equal * "Key". If 1$ already equals "Key", then the * player must own a key, so we branch to :Have. #If (1!<100) <#Branch (:No money)> * The key costs 100 GP. If the player has * less than 100 GP, then we branch to :No money. #1!=1!-100 * Here we take 100 GP away from the player. #1$="Key" * Here we state that the player has a key now. #Branch (:Thank You) :Buy a sword #If (2$="Sword") Then <#Branch (:Have)> * Here we check to see if the player already has a * sword. #If (1!<100) <#Branch (:No money)> * As with the key, we check to see if the player * has enough money. #1!=1!-100 * Here we take 100 GP from the player. #2$="Sword" * Here we state that the player now owns a sword. #Branch (:Thank You) :No money * This part of the program takes care of the player * if he has no money. What are you trying to pull? Get some money next time. * Here the merchant gets nasty with the player. #Branch (:press key) :Have * This is run if the player tries to buy * something they already own. You already have one of those! #Branch (:press key) :Thank You * This is run when the player buys something. Thank You, come again. #Branch (:press key) :press key * This is run at the end of every section of * programming. It wait for the player to press * a key before exiting the program, so we don't * have to play around with that '@' nonsense any * more. #Get 3$ * Put whatever was typed at the keyboard and save it * in 3$ (if anything was typed at all). #If (3$="") < #Branch (:press key) > * If nothing was pressed, repeat the process until * something was. * If something was pressed, then the above * condition becomes false, and the branch is never * executed, bringing us to the end of the program. The comments pretty much explain how the program works, so there's no need to repeat myself. If you don't understand the program at first, don't worry. Even though it uses commands you already know, it is somewhat confusing. Try going step by step through the program, tracing your way through it. That might help. If not, come back to this program after we've discussed programming a little longer, and it should make sense to you. Anyway, this was our first big program, and also our first useful program. You can see how a program such as this could be used in your games, and this program also introduces you to the concept of setting conditions. Before I go into that any further, though, it would be appropriate to explain the #Get command. The #Get command gets a key pressed from the keyboard buffer. It stores whatever value is currently in the buffer in a literal variable. If no key was pressed, then the value it gets is nothing (That is, nothing in quotation marks, or ""). Here is an example of the #Get command used to place whatever key was pressed into the variable 0$: #Get 0$ Usually, nothing has been typed at the keyboard, so the variable remains empty. That means that "" is stored in the variable. If, for example, the 'x' key were pressed, then "x" would be stored in the variable, but usually "" is stored because no key has been pressed. In order for the computer to wait until a key is pressed, we must set up a loop, or something that repeats forever until something else happens. This is done using the #If...Then and #Branch commands. Here's an example of a loop that waits until a key is pressed to stop looping and continue on with the program: :press a key * That's the label that we will branch to. #Get 108$ * Get the key that was pressed (if any) and store it * in 108$ #If (108$="") Then <#Branch (:press a key)> * Here's where the real work is done. If no key was * pressed (causing the value stored in 108$ to be * nothing, or ""), then we branch back to the top * and get the key that was pressed again. * This will continue until some key is pressed and * the value of 108$ is no longer "". The above example waits until a key is pressed before continuing with the rest of the program. From now on, a similar routine will be used at the end of every program to let the user wait until he/she is finished reading anything in the Message Window before the Message Window is erased and the program ends. You no longer have to add '@' symbols at the end of your programs anymore to ensure the computer will wait for a key press. This routine does that instead. Of course, we will still use @ symbols, but only when spaces need to be added in the Message Window. Setting Conditions Setting conditions means storing a value in a variable, and then testing that variable later on to determine whether an event occurred already in the game or not. A simple example of this is a chest. If your player opens the chest and takes the money, there isn't going to be money there next time, because he/she has already taken it. We have to set a condition, however, to let the computer remember that we've already taken the contents of the chest away. Here's an example program using the chest example: * This is an example of how conditions are set. * 1! is the money variable. * 2! is the condition variable. It equals 0 if * we've never taken anything from the chest before, * but 1 if we have. #If (2!=1) then <#Branch (:chest is empty)> * If the above condition has been set to 1, then * that means we must have already opened the chest. #2!=1 * Here's where the condition is set- now that we * have opened the chest, 2! now equals 1, meaning * the chest has been opened. You found 200 GP!!! #1!=1!+200 * Give the player 200 GP #Branch (:press a key) :chest is empty * We branch here if 2! equals 1, meaning we've taken * the gold from the chest before. The chest is empty! #Branch (:press a key) :press a key #Get 1$ #If (1$="") then <#Branch (:press a key)> * Pause until a key is pressed. In the above example, the first thing the program does is check the contents of the variable 2!. If the value is 1, then that means that this chest has been opened before, so the program branches to the :chest is empty routine. Since all numeric variables are automatically set to 0 whenever a new game begins, there is no way 2! can equal 1 unless the player opens this chest. This can be seen with the rest of the program. Let's say that when the player comes to this chest, 2! is set to 0. When the program starts, 2! is checked to see if its value is 1. It isn't, so the program continues on normally. The next line sets 2! to equal 1, though, so from now on, whenever the player opens this chest again, 2! will equal 1, and the program will branch to :chest is empty. This is one of the biggest reasons you must keep track of what each variable does. If you didn't write down somewhere that 2! was to be used to check whether or not the chest was empty, then you might use 2! in another program somewhere and its value might be set to 0 again. That means that the player could come back and get the gold out of the chest again even though it should have been empty. Setting conditions is one of the most powerful things you can do in an RPG game. They ensure that the player doesn't get stuff out of empty chests, that they don't fight the same boss enemies more than once, etc. You must keep in mind that you have to have a separate variable for each condition you set. Conditions may also be set using literal variables. This is because they are automatically set to nothing ("") at the first of a game, so you can put words in them to check later on. Here's the same example again, only this time it uses a literal variable to keep track of the condition: * This is an example of how conditions are set. * 1! is the money variable. * 2$ is the condition variable. It equals "" if * we've never taken anything from the chest before, * but "Empty" if we have. #If (2$="Empty") then <#Branch (:chest is empty)> * If the above condition has been set to "Empty", * then that means we must have already opened the * chest. #2$="Empty" * Here's where the condition is set- now that we * have opened the chest, 2$ now equals "Empty", * meaning the chest has been opened. You found 200 GP!!! #1!=1!+200 * Give the player 200 GP #Branch (:press a key) :chest is empty * We branch here if 2$ equals "Empty", meaning we've * taken the gold from the chest before. The chest is empty! #Branch (:press a key) :press a key #Get 1$ #If (1$="") then <#Branch (:press a key)> * Pause until a key is pressed. You can see how strings can be used in a similar, if not more descriptive fashion. Reserved Variables And Special Programs In an RPG game, there are two very special programs. These are the Starting Program and the Constant Program. Both are defined in the Main File (pages 23, 24). The Starting Program The Starting Program is a program that is run as soon as the game starts. As soon as the Main File is loaded, the Starting Program is loaded, run, and then the player starts on the first board. The Starting Program is used to create such things as title screens, opening sequences, and most importantly, to set variables that are vital to the game's progress. If you only do one thing with the Starting Program, make sure that you set variables such as your characters' health, experience, fighting power, defensive power, etc. Make sure that the variables you used are the same ones that you declared would be used for this purpose in the Main Fight File and in the Teammate files. The example below is a short Starting Program that briefly demonstrates this idea. Before I begin, however, I must say that this program assumes these things: - There is only one teammate (the main character) - This teammate is playing if 0! = 0 (see page 29). - The health variable of this teammate is 1! (page 42). - The max. health variable of this teammate is 2! (page 42). - The experience variable of this teammate is 3! (page 38). - The special move power variable of this teammate is 4! (page 39). - The fight power variable of this teammate is 5! (page 42). - The defensive variable of this teammate is 6! (page 41). All of the above variables must be set in order for the game to run smoothly (unless there is no fighting in the game. In that case, none need be set. Here's the program: * Sample Starting Program that sets variables to * their initial values for use in the game. This could be a title screen. * A title screen could be inserted here. :press a key #Get 1$ #If (1$="") <#Branch (:press a key)> * Wait for a key press. * Here we set the variables: #0!=0 * 0! is automatically set to 0, but this declaration * ensures that the main character will be on the * team. #1!=300 * The player starts with 300 health points. #2!=350 * The max. health allowable for this player is 350. #3!=100 * The player starts with an experience of 100. #4!=120 * The player starts with a special move power of * 120. #5!=50 * The fight power of this player is 50. #6!=75 * The defensive power of this player is 75. * All required variables are now set, but let's say * that variable 10! is a variable that holds the * amount of gold the player has. Let's start * him/her off with 200 gold pieces. #10!=200 If you were to start off with more than one player, then there would have to be declarations for each character. Also, when new teammates are added to the team throughout the game, these variables must be set for that player. Now do you see why you should write down what these variables are? If you didn't then you'd never know which ones were the health variable, or the experience variable, etc. Anyway, the title screen was nothing fantastic, but you can have really good title screens and opening story sequences using more advanced commands in RPGCode. All these commands are described in the reference section. Some good ones are: #Viewbrd, #Color, #Fade, #Mem, #Put, #Sound, #Text, and perhaps #Dirsav, and #Load for loading previously saved games. The Starting Program is intended mainly for setting necessary variables at the beginning of a game, so remember to do this, otherwise your fighting sequences won't work right. The Constant Program Another important program is the Constant Program. This program is run at any point in the game if a specific key is pressed (this is defined in the Main File, page 24). The Constant Program is used to show the inventory of items for the player, let him/her use items, load and save games, and quite to DOS. In fact, the only way that a player can quit to DOS is through a Constant Program. Below is an example of a Constant Program that allows the player to use an item to restore his/her health: * Constant Program Example. * Below are declarations of variables. 1! is the * health variable, 2! is the variable that tells how * many health potions the player has. 3! is the * max. health variable. * The declarations below wouldn't normally be here, * but they are included so that the program works * independently of a playable game: #1!=12 #2!=3 #3!=300 * Sets health to 12, number of potions to 3, and the * max. health to 300. :menu 1- Restore Health 2- Return To Game Current HP: #Show 1! * Puts a little menu in the Message Window. * Also shows current HP. :get key #Get 1$ #If (1$="") Then <#Branch (:get key)> #If (1$="1") Then <#Branch (:restore health)> #If (1$="2") Then <#Branch (:return to game)> #Branch (:get key) * Branches to different parts of the program based * upon what was pressed, branches to :get key again * if nothing is pressed, or a key that isn't 1 or 2 * is pressed. :restore health #If (2!=0) Then <#Branch (:not enough)> Restoring Health. Potions left: #Show 2! #1!=1!+100 * Add 100 HP. #If (1!>3!) <#1!=300> * If current health level is greater than the max. * health level (300) then the health level equals * 300. #Branch (:menu) * Return to the menu. :return to game #Get 1$ #If (1$="") Then <#Branch (:return to game)> * Wait for key press. #End * The #End command ends the program. :not enough You don't have any health potions! :wait for key #Get 1$ #If (1$="") then <#Branch (:wait for key)> #Branch (:menu) There isn't much new here, only the #End command. All this command does is end the program. You will find it quite useful. This is just a very simple Constant Program. Usually, Constant Programs will have a menu (usually more complex than the one in this example), and they will usually have choices to load and save your game as well as quit to DOS. They may also show a close up picture of your players as is usual in a traditional RPG. Of course, these options use advanced programming commands, so you will have to look in the reference section of this chapter to learn how to do these things. The #Run Command Usually Starting Programs and Constant Programs can become quite large. This can be a problem, since the maximum size a program can be is 400 lines due to memory limitations. There is a solution, of course, and that solution is the #Run command. The #Run command ends execution of the current program, and runs another, this way, instead of using #Branch commands to branch to large parts of the program, you can make these large portions into separate programs and use the #Run command to run them. Here is an example of using the #Run command: #Run "program.prg" The above command runs a program with the filename program.prg. You must always include the .PRG extension in order for this to work. The program below demonstrates using the #Run command with three programs: Main.PRG, Sub1.PRG and Sub2.PRG. The program doesn't actually do anything, but it's good as an example. Main.PRG: * Program demonstrating #Run commands in place of * #Branch commands. * HERE'S THE MAIN MENU: Main Menu: 1- Run Sub1 2- Run Sub2 3- Exit :get a key #Get 1$ #If (1$="") Then <#Branch (:get a key)> #If (1$="1") Then <#Run "sub1.prg"> * If this were 1 whole program, you might use * #Branch (:sub1) instead, creating a label called * :sub1 that does what the program Sub1.PRG does. #If (1$="2") Then <#Run "sub2.prg"> #If (1$="3") Then <#End> #Branch (:get a key) Sub1.PRG: * This is the program Sub1.PRG, called on by * Main.PRG. THIS IS SUB1.PRG!!! Press a key to return to Main.PRG :get a key #Get 1$ #If (1$="") Then <#Branch (:get a key)> #Run "Main.PRG" * When a key is pressed, we return to the Main Menu * Program. Sub2.PRG: * This is the program Sub2.PRG, called on by * Main.PRG. THIS IS SUB2.PRG!!! Press a key to return to Main.PRG :get a key #Get 1$ #If (1$="") Then <#Branch (:get a key)> #Run "Main.PRG" * When a key is pressed, we return to the Main Menu * Program. By breaking a large program up into smaller ones like this, we will not run out of memory. When Main.PRG is run, it waits for you to press 1, 2 or 3. If 1 is pressed, Sub1.PRG is run. If 2 is pressed, Sub2.PRG is run. If 3 is pressed, the program ends. The programs Sub1.PRG and Sub2.PRG display a message in the Message Window and wait for a key to be pressed. Then they run Main.PRG again. Reserved Variables A subject that deals somewhat with the Constant Program is the usage of Reserved Variables. Reserved Variables are special variables that holds values that you cannot change, but are changed by the computer. They are used to provide information to your program as to the room you are in, as well as the position of the player and the program in the current room. Reserved Variables are used just like any other variables, except you can't change their values (you can try, but the computer will just change them back again). The Reserved Variables are variables 1501!-1505!. Each one of these variables contains a value that may be useful to your programs. Here is what each variable contains: 1501!- The Room Constant value. 1502!- The player's x-position on the board. 1503!- The player's y-position on the board. 1504!- The current program's x-position on the board. 1505!- The current program's y-position on the board. The most useful of these variables is 1501!, the Room Constant value. Remember back on page 14 when we declared the Constant Value for each board in the Board Information screen? This Constant Value could be any number. The reason it is used is because it can be used by programs to determine if the player can do certain things on this board, such as save their game (in some RPG games, players can only save their games at certain points in the game). The Constant Value is used mainly by the Constant Program, since it is the program used to do things like save the game, and it is also the only program that is used on more than one board throughout the game, and so can change what it does based upon where it is run during the game. An example of using the Constant Value can be the decision of whether the program is allowed to save the game on this board or not. If the Constant Value is set to 0 (which is the default), then the program would save the game. Otherwise, it would not. The program below demonstrates this using a new command, the #Save command, which saves the player's progress in the game. * A program demonstrating usage of the Constant * Value. * This program would likely be used as part of the * Constant Program. #If (1501!=0) then <#Branch (:save the game)> #If (1501!~0) then <#Branch (:don't save)> * If 1501!=0, then it branches to a saving routine. * If 1501!~0 (doesn't equal 0), then it branches to * a routine that says it can't save the game. :save the game #Save "test" * Saves the player's progress in a file called * "Test". #End :don't save You can't save your game here. :get key #Get 1$ #If (1$="") Then <#Branch (:get key)> #End By using the current board's Constant Value, your programs can determine what they can and cannot do on any given board. I won't explain the #Save command here. Look in the Reference section for the whole news on #Save and its counterpart #Load (you may also want to look at #Dirsav). RPGCode Command Reference At this point, you have learned enough about programming in RPGCode that you can create very flexible programs. There are more commands in RPGCode, however, and many are very useful in creating special effects, or pretty much anything you could think of. All the commands for RPGCode are alphabetically listed and explained in detail in the following pages... @ Name: Blank Line Format: @ This command places a blank line in the Message Window. This command must be used instead of simply placing a blank line in your programs, because blank lines are ignored by the computer. It must appear on a line by itself. Example: A blank line will follow this line. @ There is a blank line above this. * Name: Comment Specifier Format: * Comment This symbol is used to tell the computer that a comment follows. Comments are ignored by the program, and are to be used as notes to yourself as to what the program does. Comments must appear on a line by themselves. Example: * This program was created 2/22/97 * It gives a message to the player. Hello, player! #Branch Name: Branch Command Format: #Branch (:label name) This command is used to branch, or skip to another part of the program. Throughout the program, you must create labels, which identify where the command is to branch to. Labels must appear on a line by themselves, and they have a ':' symbol in front of them. #Branch is used to skip through the program to these labels. #Branch is case sensitive, which means that the capital letters and spaces of the label name in the #Branch command must match up with the capital letters and spaces in the label name. Example: Line 1 Line 2 #Branch (:next line) Line 3 :next line Line 4 * The words "Line 3" were skipped, because we * branched to the label :next line before reaching * "Line 3". Related Commands: #Fbranch, #Run #Change Name: Change Program. Format: #Change "program.PRG" This command changes the program filename of the program currently running. Execution of the current program continues, but when the player touches the program tile again, the new program that was set with #Change will be run instead of the original program. This change remains in effect only during the time that the player is on the board. If the player leaves the board and then returns, the program tile will be reset to its original program. The filename that you specify must be in quotation marks, and it must have the .PRG extension. Also, you may not substitute the filename in quotation marks with a string variable. This command may be useful if the player must talk to a certain person on the board more than once during the course of the board. By using #Change, you can change what the person says each time by changing his/her program. Example: * An example of the #Change command. Hello, there. I am happy. #Change "another.PRG" I am still running the original program!!! * The initial program continues running * until its end, and then the next time the player * touches this program tile, the file "another.PRG" * will be run instead of this program file. Related Commands: #Gone, #Move, #Prg, #Run #Clear Name: Clear Screen. Format: #Clear The #Clear command clears the entire screen, making it entirely black. When the program ends, the screen is restored to the way it was before the program began (unless using the #Done command to end the program). #Clear can be used to clear the screen to prepare it for large menus, or to prepare it for story sequences in the game when other boards are temporarily placed on the screen in place of the current one. Example: * Clear the screen and place a new board there. #Clear * The screen is now black. #Viewbrd "another.BRD" * Place another board on the screen. Related Commands: #Color, #Fade, #Mem, #Put, #Return, #Scan, #Text, #Viewbrd #Color Name: Change Color. Format: #Color (color code) The #Color command changes the color of the text that will be displayed in the Message Window, as well as the color of the fadeout with the #Fade command, and the text that is placed on the screen with the #Text command. #Color also changes the color of the color sweep that goes across the screen before a battle. The color code is a number used to represent the color you wish to use. A list of all the color codes can be found in Appendix A. You may replace the color code with a numeric variable that contains a value that is one of the color codes. By default, the color is set to code 15 (white). This command has no effect with the text on CGA monitors. Example: * Example using the #Color command. #Color (15) Color code 15. #1!=4 #Color (1!) * Sets the color to 4 (which is the value stored in * 1!). Code 4 is red. Color code 4. :wait for key press #Get 1$ #If (1$="") Then <#Branch (:wait for key press)> * Wait for the player to press a key. #Color (15) * Reset color to 15 (white). Related Commands: #Fade, #Text #Delay Name: Time delay. Format: #Delay (time) #Delay pauses the game for a specified number of seconds, specified by time. The time is expressed in seconds, and can be a decimal number. You may not replace the time with a variable Example: * Displays text, then delays for 1.8 seconds Hello!!!! #Delay (1.8) Related Commands: #Wait #Dirsav Name: Directory of saved games. Format: #Dirsav #Dirsav shows a listing of all the saved games (*.SAV) in the current directory. These saved games are made by a player who has been playing a game and who has saved his progress with the #Save command. Example: * Program to load a saved game. #Dirsav #Prompt "Which do you want to load",1$ #Load 1$ Related Commands: #Load, #Save, #Prompt #Done Name: Done program. Format: #Done The #Done command ends execution of a program, but does not restore the screen to the way it was before the program began. If there is any text in the Message Window, it stays there. If you have put any graphics on the board, they stay there. The changes to the board remain in effect only for the time the player is on the board. If the player leaves and then returns to the board, it will be restored to normal. Example: * Program demonstrating the #Done command. * First, let's put some graphics on the board. #Put (5,5,"graphic1.GPH") #Put (8,8,"graphic2.GPH") * Usually, at the end of a program these graphics * would be erased and the board would return to * normal, but by using the #Done command, we can * force these graphics to stay. #Done Related Commands: #Clear, #Mem, #Prg, #Put, #Return, #Scan, #Text, #Viewbrd #Dos Name: Return to Operating System (DOS). Format: #Dos This command quits the Translator program and returns to DOS (or Windows). This is the only way your users can exit the Translator program, so be sure to include an option in the Constant Program which allows you to quit to DOS. Example: * Quit to DOS program. Press any key to quit to DOS... :get key #Get 1$ #If (1$="") <#Branch (:get key)> * Wait for the user to press a key #Dos Related Commands: #Reset #Empty Name: Empty all variables. Format: #Empty This command clears all variables, numeric and literal. Use this command wisely, otherwise all the variables in your game will be cleared. Example: * Clear all variables. #1!=12 Variable 1! before Empty: #Show 1! * Shows contents of 1! (which is 12) #Empty * Clears all variables. Variable 1! after Empty: #Show 1! * Shows contents of 1! (now 0). Related Commands: #Dos, #Reset #End Name: End program. Format: #End This command ends execution of a program, restoring the screen to the way it was before the program began. Also used to denote the end of a function block (used with #Fbranch). Example: * Program demonstrating #End :menu Press: 1- To see message 2- To end :scan #Fbranch (:get key) * Go to get key routine #If (1$="1") Then <#Branch (:message)> #If (1$="2") Then <#End> * In this case, #End is used to end the program. #Branch (:scan) :message Hello!!! #Fbranch (:get key) * Wait for key press #Branch (:menu) :get key #Get 1$ #If (1$="") Then <#Branch (:get key)> #End * In this case, #End is used to denote the end of a * function block. Related Commands: #Done, #Dos, #Fbranch, #Over, #Win #Fade Name: Fade out. Format: #Fade #Fade is used to "fade out" the screen. Actually, the screen is blotted out by a growing and shrinking box. The color of the fadeout is determined by the #Color command. Once the screen has faded out completely, the screen is completely clear, similar to the way it is using the #Clear command. Use #Return to restore the screen to the way it was. The screen will be restored to the way it was at the end of the program (except when the #Done command is used). Example: * Fade out the screen using a blue fadeout. #Color (1) * Sets the color of the fadeout to color code 1 * (blue). #Fade * Fades the screen using blue as the fadeout color. #Color (15) * Rests to color 15 (white). Related Commands: #Clear, #Color, #Return #Fbranch Name: Function Branch. Format: #Fbranch(:label name) This command is used in the same manner as the #Branch command to skip to other parts of the program. The section to which #Fbranch branches to is defined by the name of the label in parentheses. A corresponding label name must exist somewhere in the program (see #Branch command for more information on labels). The sections of program that #Fbranch branches to are called functions. By using the #Fbranch command, the program can jump to one of these functions and carry out the commands in the function. Once the program encounters the #End command or the end of the program inside the function, then the program branches back up to #Fbranch, carrying out the lines of code after it. Since the #End command inside a function will not end the program, you have to use the #Done command to end the program from within the function. In order to mimic what #End does, however, you must include the #Return command before the #Done command (This restores the screen to the way it looked before the program and then ends the program). See #Branch for more info on branching. Example: * Example using #Fbranch. This is the Main part of the program. #Fbranch (:key press) * The above command Function Branches to the section * of program called :key press. Once #End is * encountered in :key press, we return to here * automatically. #Fbranch (:function 1) * This command goes to the function called * :function 1, carries out the instructions in * :function 1, and then returns here automatically. We're back to Main! #Fbranch (:end of program) * This function branch will demonstrate ending the * program from within a function. A more efficient * way of doing things would be to have used the #End * command here to end the program. * H E R E A R E T H E F U N C T I O N S: :key press #Get 1$ #If (1$="") Then <#Branch (:key press)> * First we wait for a key press, then we #End this * function, causing the program to branch back to * the position from which this function was run * using #Fbranch. #End * This command doesn't end the program since it is * inside a function. Rather, it causes us to jump * back up to the place from which this function was * called using #Fbranch. * If this function were called using #Branch, * however, this would cause the program to end since * #Branch doesn't expect functions to jump back to * the position from where they were called. :function 1 Now we are inside function 1. #Fbranch (:key press) * Function branches to the :key press function, * causing us to wait until a key is pressed. #End * Jumps back to the position from where * #Fbranch (:function 1) was used. :end of program * This function demonstrates ending a program from * within a function. #Fbranch (:key press) * Function branch to :key press, waiting for us to * press a key. #Return * Restores the screen to the way it was before the * program began. #Done * Ends the program. If in each of these situations, #Fbranch were replaced with #Branch, the program would end when #End were encountered from within a function. This is because using the #End command does not end a function called by #Branch, since #Branch is not used to call functions, it is simply used to branch to another part of the program and stay there. If #End were encountered in a routine called by #Branch, then the program would end. You can also see how #Fbranch can be used to "create" your own commands. In the example above, #Fbranch (:key press) was used as the "command" to wait for a key to be pressed. This acts like a command, because after the :key press function is run, the program executes the command after #Fbranch (:key press), just like commands are executed one after the other. Related Commands: #Branch, #Done, #End, #Reset #Fight Name: Fight Command. Format: #Fight (skill, background.BKG) The #Fight command is used to initiate a fight from within a program. Using this command ends execution of the program. The skill is the skill level of the enemy to fight. This skill level was determined in the Main Fight File (page 28). Once the battle is initiated, the computer randomly selects an enemy to fight of that skill level. The second argument in this command, background.BKG is the background against which the battle will take place. This filename must not be in quotation marks, and must include the .BKG extension. The skill level may be replaced by a numeric variable holding the skill level, and the background.BKG may be replaced by a literal variable holding the filename of the background to fight against. This command is useful in initiating fights with "bosses" in the game, either by stepping on a tile that leads to the boss's chamber, or by creating a character on the screen that you talk to and then fight. In order to fight one specific enemy, there must be only one enemy of a certain skill level. For example, if you wished your player to fight an enemy called Enemy.ENE, this particular enemy would have to have its very own skill level. Let's say Enemy.ENE has a skill level of 28. In order for this enemy to be fought, he must be the only one with skill 28. This is because when the computer randomly selects an enemy to fight out of all the enemies with a skill of 28, this is the one it will choose every time since it is the only one with a skill level of 28. Example: * Example using #Fight * We will use a variable to substitute the * Background filename. #1$="bground.BKG" Press any key to begin the fight... :key press #Get 0$ #If (0$="") Then <#Branch (:key press)> * Wait for user to press a key. * Now we'll start a fight with someone of skill 49: * Let's also make the graphical sweep before the * fight color code 1 (which is blue). #Color (1) #Fight (49,1$) * Starts a fight with an enemy of skill 49, against * a background called Bground.BKG (the contents of * 1$). This command also ends the program. Related Commands: #Color #Get Name: Get key. Format: #Get literal_variable$ This command takes whatever is currently in the keyboard buffer and assigns it to a literal variable (1$, 2$, etc.). If nothing has been typed recently, then the keyboard buffer will be empty, and nothing will be assigned to the literal variable (the variable will have a value of "", or nothing). Usually, nothing has been typed, so you will have to keep #Branching to this command every time the variable equals "" until it has a value in it. The #Get command puts only one character in the literal variable, or one key press. It is useful for creating menus. If the player presses one of the arrow keys, the string "UP", "DOWN", "LEFT" or "RIGHT" will be stored in the variable, so that you can use the directional arrows in your programs. Example: * Example using #Get. :key press * We will keep branching to this label until the * literal variable doesn't equal "". #Get 1$ * Assigns whatever is in the keyboard buffer to 1$. #If (1$="") <#Branch (:key press)> * If nothing was pressed, branch back up to * :key press and read the keyboard buffer again. * If something was pressed, then 1$ won't equal "", * so we won't branch back to :key press. Instead, * the program will continue to this section. You pressed: #Show 1$ * Show what the user pressed. * Now wait for another key press before ending the * program. :wait for key #Get 2$ #If (2$~"") Then <#End> #Branch (:wait for key) * If the value read from the keyboard buffer is not * equal to nothing (2$ ~ ""), then the program ends. * Otherwise, the value must equal "", so we branch * back to :wait for key. * This isn't the way we have been doing this wait * for key command, but it's good just to get used to * the not equal to (~) symbol for #If...Then. Related Commands: #Branch, #Fbranch, #If...Then, #Prompt #Godos Name: Perform a Dos command Format: #Godos "dos command" This command performs a Dos command then returns to your game. This can be used to run outside programs that display graphics screens or other commands. Dos command is the command to perform, and cannot be substituted with a variable. Example: * Perform Dos command dir #GoDos "dir" That was the directory! @ @ @ @ Related Commands: #Dos #Gone Name: Gone command. Format: #Gone This command ends execution of the current program and removes it from the board. From then on, whenever the player steps on the tile where the program used to be, nothing will happen. This change is only in effect during the time the player is on this board. Example: * Example of the #Gone command. Farewell, cruel world!!! * Now wait for a key press: :key press #Get 1$ #If (1$="") Then <#Branch (:key press)> * Now to erase this program: #Gone Related Commands: #Change, #Move, #Prg #If...Then Name: If...Then condition testing command. Format: #If (condition) Then <command> #If...Then is a special command that tests if a variable contains a certain value or not. If it does, then a command is executed. Including Then in the command is optional, but it makes the command much easier to read. The #If...Then statement is thoroughly explained starting on page 63. #If...Then can test for four different things: equal to (=), greater than (>), less than (<), and not equal to (~). Here are the formats for each: #If (variable = value or variable) Then <command> #If (variable > value or variable) Then <command> #If (variable < value or variable) Then <command> #If (variable ~ value or variable) Then <command> Example: * Example showing all forms of the #If...Then * command. #1!=12 #0$="Hello" #2!=400 * Set up some variables to work with. #If (1!=12) Then <1! equals 12!!!> * If the value in 1! equals 12, then "1! equals * 12!!!" will be displayed in the Message Window. #If (0$="Hello") <#Show 0$> * If 0$ contains the word "Hello" (which it does), * then the command #Show 0$ is performed, which * shows the contents of 0$ in the Message Window. #If (1! < 2!) Then <#Text (1,1,"1! is < 2!")> * If the value of 1! (12) is less than the value of * 2! (400), which they are, then "1! is < 2!" is * displayed at screen position 1,1 using the #Text * command. #If (1! ~ 2!) <1! doesn't equal 2!> * If the value in 1! (12) doesn't equal the value in * 2! (400), then "1! doesn't equal 2!" is placed in * the Message Window. #If (1! > 2!) Then <1! is greater than 2!> * If the value in 1! (12) is greater than the value * of 2! (400), then "1! is greater than 2!" is * displayed in the Message Window. * Since 12 isn't greater than 400, this message * isn't displayed. :get key #Get 805$ #If (805$="") Then <#Branch (:get key)> * If nothing is in they keyboard buffer, and, * therefore, 805$, then we branch to :get key. Related Commands: #Branch, #Fbranch, #Get #Load Name: Load a saved game. Format: #Load "filename" Throughout the game, the player has the ability to save his/her progress using programs that use the #Save command. In order to play these saved games, however, a program must be run that uses the #Load command to load a saved game. The filename used is the filename of the saved game. When RPGCode saves a game, it adds a .SAV extension to the filename. When you load these files, do not include the extension, because the program adds it for you. Also, filename may be substituted by a literal variable, so that the user can type in a filename using the #Prompt command, have that filename saved in a variable, and then use that variable to load the saved file. #Load ends execution of the current program, and ends the current game. When the #Load command is used, the player is taken to the board from which he/she saved their game, and all variables, literal and numerical are assigned the values that they held when the game was saved. Example: * Example using #Load #Clear * Clear the screen. #Text (1,1,"Saved games on drive:") * Put a heading at position 1,1. #Text (1,2,"") * Position the cursor at 1,2. #Dirsav * Show a directory of all saved games on the drive. :prompt for filename #Prompt "Which game do you wish to load",1$ * Prompt for which file is to be loaded. what the * user types is stored in 1$. #If (1$="") Then <#Branch (:prompt for filename)> * If nothing was typed, then prompt the player * again. #Clear * Clear the screen. #Text (1,1,"Loading saved game...") #Load 1$ * Load the filename stored in 1$. Related Commands: #Dirsav, #Prompt, #Save #Mem Name: Put a scanned tile from memory on the board. Format: #Mem (x pos, y pos, memory location) This command places a tile on the board that has been saved in memory with the #Scan command. X pos is the x position (horizontal) on the board grid on which to place the tile. This is a value from 1-19. Y pos is the y position (vertical) on the board grid on which to place the tile. This is a value from 1-11. Both of these values may be replaced with a numerical variable. The memory location is a number of either 1 or 2 stating which tile from memory you wish to place on the board. Since there are two possible memory locations in which to store these tiles with the #Scan command, there are only two from which you can get these tiles. This number may not be replaced with a variable. Example: * Example showing the #Scan and #Mem commands. #Scan (3, 8, 2) * Take the tile at location 3,8 and store it in * memory position 2. #1!=1 #2!=1 #Mem (1!, 2!, 2) * Place the tile in memory position 2 at screen * position 1,1 (these are the values stored in 1! * and 2!). Related Commands: #Put, #Scan #Midiplay Name: Play Midi file Format: #Midiplay "filename.mid" This command sets the music player program to play the file filename.mid. This filename must include the .mid extention, and cannot be substituted for a variable. The song will begin playing at the end of the currently playing song. Example: * Using #Midiplay to change the music #Midiplay "drums.mid" * Sets the music program to play the file drums.mid Related Commands: #Midirest #Midirest Name: Rest Midi player. Format: #Midirest This command causes the Midi Music player to rest- playing no music. This happens once the current song playing has ended. Example: * Plays a song then causes the music to stop. #Midiplay "drums.mid" #Midirest Related Commands: #Midiplay #Move Name: Move program location. Format: #Move (x pos, y pos) This command continues execution of the current program, but moves it to a new location on the board. This means that when this command is used, the next time the player steps on the tile where the program used to be, nothing will happen. If, however, the player steps on the tile that the program was assigned to with the #Move command, then the program will run again. The x pos and y pos are values stating where on the board the program will be moved to. These are the x and y coordinates of the new location. The x value ranges from 1-19, and the y value ranges from 1-11. Both may be substituted with numerical variables. The command remains in effect only during the time that the player is on the board. Example: * Using the #Move command #Move (3,8) * Moves this program to the new position 3,8. This program has moved. :get key #Get 1$ #If (1$="") Then <#Branch (:get key)> Related Commands: #Change, #Gone, #Prg #Newplyr Name: New player. Format: #Newplyer "filename.GPH" This command changes the player graphic to the graphic saved as filename.GPH, or the character animation saved as filename.CHA. When including this filename, you must include the .GPH or .CHA extension. Also, you may not substitute the filename with any variables. This command remains in effect until changed with another #Newplyr command. Example: * Change the player graphic. Out with the old... #Fbranch (:get key) #Newplyr ("player.GPH") * Loads the graphic "player.GPH", and puts it in * place of the player graphic. In with the new!!! #Fbranch (:get key) #End :get key #Get 1$ #If (1$="") <#Branch (:get key)> * Since this function is at the end of the program, * we don't need to include the #End command to end * the function. The end of the program works just * the same as #End in a function. Related Commands: #Mem, #Put, #Scan #Over Name: Game Over. Format: #Over This command displays a "Game Over" message, waits for the user to press a key, and resets the game to the startup program. If a program is going to initiate a "Game Over", you may wish to add special effects using other commands, instead of using #Over. To reset the game to the startup program after doing these special effects, use the command #Reset, instead of the #Over command. Example: * Oh, no! Your game is over! #Over * Displays a Game Over message, waits for a key * press, and then resets the game to the startup * program. Related Commands: #Reset, #Win #Prg Name: Change Program Location. Format: #Prg (program number, x pos, y pos) This command moves the program assigned to a certain program number to a new location on the board. The program number for all programs is defined in the Board Editor in the Program Info screen (page 15). The program number is a number from 0 to 9 which represents which program you are dealing with from the Program Screen of the Board Editor. The x pos and y pos value are the x and y coordinates on the board where you wish to place the program. The x value is a number from 1-19, and the y value is a number from 1-11. Program number, x pos and y pos can all be substituted with numerical variables. Also, any change you make with the #Prg command remains in effect only for the time the player is on this board. This command is intended for placing programs on the board that weren't there before. In the Board Editor, you can assign a program slot a filename, but you can leave its coordinates on the board at 0,0, meaning that it isn't on the board. Using the #Prg command, you can change those coordinates to a location on the board, so that the program exists there. This can be useful when you are setting and testing conditions (page 69), because if a certain character is supposed to be on the board only in certain parts of the game, you can test the condition that tells the program if the character is supposed to be there or not, and then move the program from location 0,0 onto the board. You can also put a graphic on the board for this new character using the #Put command. This is demonstrated in the following example: Example: * This program assumes that the program assigned to * slot 0 in the Board Editor has a filename, but is * currently at position 0,0. It also assumes that * the player is supposed to be on the board if the * variable 80!=0. #If (80!=0) Then <#Branch (:character is on board)> #End * If the player is supposed to be on the board (if * 80!=0), then we branch to a routine that puts the * player there. Otherwise, the program ends. :character is on board #Put (12,8,"graphic.GPH") * Puts a graphic for the character on the board at * 12,8. #Prg (0,12,8) * Moves the program assigned to slot 0 to 12, 8 on * the board. Related Commands: #Change, #Gone, #Mem, #Put, #Scan #Prompt Name: Prompt command. Format: #Prompt "prompt question",variable This command prompts the player with a question, and assigns whatever the player types to a variable (either numerical or literal). Also, prompt automatically puts a question mark at the end of the prompt question. The prompt question is a question that is asked of the player. This question appears in the Message Window. The variable is the variable to which the player's response is saved. It can be either numerical or literal. Example: * This gets the player's name. #Prompt "What is your name",1$ * This puts the words "What is your name" in the * message window, and automatically puts a question * mark at the end. The program waits for the player * to type something, and then assigns the response * to 1$. I know your name. It is: #Show 1$ * Shows the contents of 1$ (which is what the player * just typed). :get key #Get 2$ #If (2$="") Then <#Branch (:get key)> * Waits for the user to press a key before ending. Related Commands: #Get #Push Name: Push player. Format: #Push "Direction" This command causes the player to walk in the specified direction. As usual, the player will not be able to walk through solid tiles, and will walk underneath under tiles. Direction is the direction for the player to walk. Valid directions are: N or North S or South E or East W or West This command is useful in creating small story sequences where your character walks around. This may not be replaced with a variable. Example: * Moves the player N,S,E,W #Push "N" #Push "South" #Push "East" #Push "W" Related Commands: #Mem, #Put, #Scan, #Viewbrd #Put Name: Put graphics tile on board. Format: #Put (x pos, y pos, "graphic.GPH") This command loads a graphics tile and places it on the board at the specified position. This graphic will remain on the board only for the duration of time that the player is on the board. X pos and y pos are the x and y coordinates on the board where the graphic is to be placed. The x value ranges from 1-19, and then y value ranges from 1-11. Both can be substituted with numerical variables. The filename of the graphic to load, graphic.GPH, must be a valid filename, and must include the .GPH extension. It also must be enclosed in quotation marks. This filename may not be replaced with a variable. Example: * Puts a graphic at 12,11 #Put (12,11,"tile1.GPH") * Places the graphic saved as "tile1.GPH" at * position 12,11 on the board. Related Commands: #Mem, #Scan, #Viewbrd #Random Name: Generate random number. Format: #Random (maxnumber, destination!) This command generates a randome number within the specified range. Maxnumber is the highest possible number the computer can choose, and so the computer will generate a nimber between 1 and Maxnumber. This may not be subsititued with a variable. Destination! Is the destination variable, a numerical variable. The random number generated is stored in this variable. Example: * Generates a random number between 1 and 100 * and puts the number in 1! #Random (100, 1!) * Puts the random number in 1! #Show 1! * Show the number #Wait (1$) * Waits for the user to press a key. Related Commands: #If...Then #Reset Name: Reset to the startup program. Format: #Reset This command resets the game to the first, loading and running the startup program and then beginning on the first board. Example: * This program resets the game. Restart game. Are you sure (Y/N) :get key #Get 1$ #If (1$="y") Then <#Branch (:restart)> #If (1$="n") Then <#End> #If (1$="") <#Branch (:get key)> #Branch (:get key) * See if the player really wants to do this. :restart #Reset * Ends execution of program, and rests game to * beginning, running the startup program. Related Commands: #Over, #Win #Return Name: Return Screen. Format: #Return This command restores the screen to the way it was before the program began, erasing all graphics placed on the board, and removing the Message Window. This is often used in conjunction with the #Clear command, which clears the screen. Example: * Example that clears the screen and then restores * it. #Clear The screen is cleared. Press a key... #Fbranch (:press a key) * Branches to a function that waits for a key press. #Return * Restores the screen to the way it was before * #CLEARing it. #Done * Ends execution of the program, but does not * restore the screen to the way it was before the * program began (the #Return command already did * that). :press a key #Get 1$ #If (1$="") Then <#Branch (:press a key)> #End * The last #End denotes the end of the function, not * the program. Related Commands: #Clear, #Done, #End, #Fade, #Mem, #Put, #Scan, #Text, #Viewbrd #Run Name: Run Program. Format: #Run "program.PRG" This command ends execution of the current program, and loads and then runs another program. This command can be used to shorten up large programs by breaking them up into smaller sections (see page 76 for more information on doing this). Also, if your program is too big for the RPGCode environment limits (400 lines), then on the last line, you can use a #Run command to load another program that picks up where the last one left off. The filename, program.PRG, must always be enclosed in quotation marks, and it must include the .PRG extension. Also, you may not substitute this filename with any variable. Example: * Program that runs another one. I'm in program 1!!! Press a key to run program 2. :key #Get 1$ #If (1$="") <#Branch (:key)> #Run "another.PRG" Related Commands: #Branch, #Change, #Fbranch, #Load, #Save #Save Name: Save player's progress. Format: #Save "filename" Throughout the game, the player has the opportunity to save his/her progress to disk, so that they can continue playing the same game at a later date. The #Save command allows you to do this. The filename can be any valid filename, but it must not have an extension. The computer automatically adds a .SAV extension to every game it saves an loads. Also, the filename may be substituted with a literal variable, so that the player can type in a filename to save their game as, and have that filename stored in a variable with the #Prompt command. Then, using that variable, you can save their progress under that filename. #Save's counterpart, #Load, is used to restore saved games. Example: * Example using #Save #Clear * Clear the screen. #Text (1,1,"Saved games on drive:") * Put a heading at position 1,1. #Text (1,2,"") * Position the cursor at 1,2. #Dirsav * Show a directory of all saved games on the drive. :prompt for filename #Prompt "Enter a filename to save as",1$ * Prompt for which file is to be saved. What the * user types is stored in 1$. #If (1$="") Then <#Branch (:prompt for filename)> * If nothing was typed, then prompt the player * again. #Clear * Clear the screen. #Text (1,1,"Saving game...") #Save 1$ * Save the filename stored in 1$. Related Commands: #Dirsav, #Load, #Prompt #Scan Name: Scan a graphics tile. Format: #Scan (x pos, y pos, memory location) This command scans a tile on the board, and saves an image of that tile in one of two available memory locations. That image may be placed on the board using the #Mem command. X pos and y pos are the x an y coordinates on the board of which tile you wish to scan. The x position ranges from 1-19, and the y position ranges from 1-11. Both mat be replaced with numerical variables, if so desired. The memory location is a number from 1 to 10, that chooses which memory location the image is to be saved to. There are ten possible memory locations: 1 through 10. This value may not be substituted with a variable of any kind. Example: * Scans a tile at location 12,8 and then puts the * stored graphic at position 5,5. #Scan (12, 8, 1) * Stores an image of the graphic tile at 12,8, and * stores it at memory location 1. #Mem (5, 5, 1) * Puts the stored image in memory location 1 at the * board position 5,5. Related Commands: #Mem, #Put #Send Name: Send player to new board. Format: #Send ("board.BRD", x pos, y pos) This command loads a new board, and puts the player at the x and y coordinates specified on the board. This continues execution of the current program as well. This command can be quite useful when you place doors in the middle of the board somewhere, and a program is needed to send the player to the next board (because manually, the player only moves to another board by moving to the edges of the board. This command allows the player to go to any board from any position on the board). The filename, board.BRD, of the board to which the player is being sent must be enclosed in quotation marks, and must include the .BRD extension. The x pos and y pos are the x and y coordinates where the player will appear on the new board (x ranges between 1 and 19, while y ranges between 1 and 11). None of the above values may be replaced by variables. Example: * An example of a door program that sends the player * to another board when the player walks into the * door. #Send ("another.BRD", 5, 5) * Sends the player to "another.BRD", and places them * at position 5,5 on that board. Related Commands: #Viewbrd #Show Name: Show variable contents. Format: #Show variable This command displays the contents of any numerical or literal variable in the Message Window. The contents of the variable must appear on a line all by themselves. Variable is any variable, numerical (in the range of 0! - 1505!), or literal (in the range of 0$ - 1000$). Example: * Example of the #Show command. #1!=400 #0$="Hello" * Puts the value 400 in the variable 1!, and the * string "Hello" in the variable 0$. #Show 1! #Show 0$ * Outputs contents of 1! (400), and 0$ ("Hello") to * the Message Window. :Key press #Get 1$ #If (1$="") Then <#Branch (:Key press)> * Wait for user to press a key. Related Commands: #Get, #Prompt, #Text #Sound Name: Play sound over PC speaker. Format: #Sound (Frequency, Duration) This command plays a sound of a specified frequency over the PC speaker for a set amount of time. This command is intended more for creating sound effects than music. The Frequency is a value from 37 to 32767. It is a hertz value. For those of you who don't know what a hertz value is, it is simply a value that measures how high or low pitched a sound is. The lower the number, the lower pitched the sound is. The higher the number, the higher pitched the sound is. The Duration is a value in the range of 0 to 65535, and it tells the computer how long to play the sound for. One second is equal to a duration of 18.2. Both the Frequency and Duration may be substituted with numerical variables that hold these values. If you wish to play short musical tunes, here are the frequency values for each note: Note Frequency A 879 A# 932 B 987 C 1046 C# 1108 D 1174 D# 1244 E 1318 F 1396 F# 1479 G 1567 G# 1660 In order to get the frequency value for these notes at different octaves, you must multiply or divide these numbers. Each time you move up an octave, multiply the frequency value by 2 (ie. C at the next octave would be 2092, or 1046*2). Each time you move down an octave, divide the frequency by 2 (ie. C at the octave below the one shown above would be 523, or 1046/2). Example: * Program that plays a sound that goes up and then * down in frequency. #1!=100 :play again #Sound (1!,1) * Plays the frequency stored in 1! for a * duration of 1. #1!=1!+1 * Add 1 to the value stored in 1! #If (1!<200) Then <#Branch (:play again)> *If the value stored in 1! is less than 200, then we * will go up and play the frequency value stored in * 1!. :go down #Sound (1!,1) * Plays the frequency stored in 1! for a duration of * 1. #1!=1!-1 * Subtract 1 from the value stored in 1!. #If (1!>100) Then <#Branch (:go down)> * As long as the value stored in 1! is greater than * 100, we will jump up to :go down, and play the * value stored in 1!. Related Commands: None #Text Name: Show text anywhere onscreen. Format: #Text (screen x pos, screen y pos, "text") This command is useful, because it allows you to write text on the screen outside the Message Window. It also allows you to place the values in variables anywhere onscreen. The screen is divided up into 40 columns by 25 rows of text positions. You tell the computer where to place the text onscreen by specifying the screen x pos and screen y pos. These are values that are the x and y coordinates on the screen to place the text. The x position may be a value from 1 to 40, and the y position may be a value from 1 to 25. To keep the screen from scrolling up, and erasing some graphics, though, you should keep your y values in the range of 1 to 23. Note that the screen x and y coordinates are not the same as the board x and y coordinates. The board is divided up into a grid of 19 X 11 tiles, while the screen is divided up into 40 X 25 text positions. Wherever you specify the text to be using the x and y coordinates, there is where the text will be placed. The screen x pos and screen y pos can be replaced with numerical variables which hold x and y values. Whatever text you wish to put onscreen must be in the place where text is in the above example. It must be surrounded in quotation marks. If you wish, you may just put two quotation marks together with nothing in between (ie. ""). This causes no text to be placed on the screen, but it positions the text cursor at a particular spot on the screen, so that when you use commands like #Dirsav, the output will begin at this point on the screen. All text you put onscreen will be the color specified by the #Color command. You may also show variables anywhere on the screen. This is done by substituting the text with a variable (either literal or numerical). These variables must not be surrounded in quotation marks, though. Any text you place on the screen is erased when the program ends, unless you use the #Done command to end the program. Example: * Examples using the #Text command in different * situations. #Clear * Clear the screen. #1!=100 #188$="Hello, player" * Set up some variables that will be displayed later * on. #Text (1,1,"This is text") * Puts the line "This is text" in the upper left * hand corner of the screen (position 1,1). #Color (1) * Sets the text color to be blue (color code 1). #100!=1 #101!=2 #Text (100!,101!,"Hello!!!!!") * Puts the text "Hello!!!!!" at x position stored in * 100! (1), and the y position stored in 101! (2). * The word will be blue. #Text (3,8,1!) * Puts the value stored in 1! (100) at screen * position 3, 8. #Text (3,9,188$) * Puts the string stored in 188$ ("Hello, player") * at screen position 3,9. #2!=16 * The following example shows how you can use the * #Text command along with the #Color command to * fade in a line of text. This requires an EGA * monitor, though. :fade in #Color (2!) * Sets the color to the value stored in 2!. #Text (5,5,"Fade in") * Puts the words "Fade in" at text position 5,5 in * the color specified by the #Color command. #2!=2!+1 * Adds 1 to the value of 2!, which is used to store * what color the text will be written in. Color * codes 16- 30 are shades of grey that go from black * (code 16) to white (code 30). This creates a fade * in effect. #If (2!<31) Then <#Branch (:fade in)> * As long as the color variable is less than 31, * then we will continue to fade in. #Color (15) * Reset the color to white (code 15). #End Related Commands: #Color, #Dirsav, #Show #Tiletype Name: Change Tile Type. Format: #Tiletype (xpos, ypos, "type") This command is used to change the type of a tile on the board to Solid, Under or Normal. You simply specify the x and y position on the board (xpos, ypos) and specify the tile type in quotations. Vaild tile types are: SOLID or S - Change tile to solid. UNDER or U- Change tile to under. NORMAL or N- Change tile to normal. In order for this command to take effect after the program has ended, you must use the #DONE command instead of #END. Example: *Change the tile at 1,1 to UNDER #Tiletype (1,1,"Under") #Done Related Commands: #Done, #Put #Viewbrd Name: View Board. Format: #Viewbrd "board.BRD" This command loads a board, and displays it on the screen, but once the program has ended, the board is erased, and the game goes back to the board it started the program from. This command is used to display large pictures that could be drawn in a board file, or to show memory or story sequences using boards and moving "player" graphics around using the #Put, #Scan, and #Mem commands. The filename of the board to display, board.BRD, must be enclosed in quotation marks, and must include the .BRD extension. You may not substitute variables for this filename. Example: * Example that shows a board, moves a "player" * around, and then returns to the current board. * In order for this program to work, you will have * to create a board file named "Another.BRD", and a * graphic tile that looks like a character called * "Char.GPH". I remember those days well... Press any key to view the memory sequence. #Fbranch (:press a key) * Branch to the function that waits for a key press. #Viewbrd "another.BRD" * Places the board "another.BRD" on the screen. #Scan (10,5,1) * Stores the tile at 10,5 in memory position 1. #Put (10,5,"char.GPH") * Puts a "player" graphic at location 10, 5 on the * board, called "Char.GPH". #Scan (10,5,2) * Saves that player graphic at memory location 2. * Now we'll move the player around a little... * First, we put down the old tile that was there * before the player got there... #Mem (10,5,1) * Now, we put the player graphic at the tile beside * that one, so it looks like he's moving, but first, * we have to save what the tile he's about to step * on looks like... #Scan (9,5,1) #Mem (9,5,2) * You see how we could move this graphic around a * bit, but I don't have time for this... Press any key to end the memory. #Fbranch (:press a key) #End :press a key #Get 1$ #If (1$="") <#Branch (:press a key)> * Wait for key press. #End * This ends the function block, not the program. Related Commands: #Mem, #Put, #Scan, #Send #Wait Name: Wait for key press. Format: #Wait (destination$) This command waits for the user to press a key and stores the pressed key in a string variable (destination$). If the player presses one of the arrow keys, a string is stored such as "UP", "DOWN", "LEFT" or "RIGHT". See #Get for more information on this. Example: * Wait for a keypress, store it in 1$, * and display it on the screen at 1,1 #Wait (1$) * Wait for the keypress #Text (1,1,1$) * Put the contents of 1$ at position 1,1. #Wait (1$) * Wait for a keypress before ending the program. * Try pressing the arrow keys in this program. Related Commands: #Get, #Prompt #Wav Name: Play Wav file. Format: #Wav "filename.WAV" This command plays a WAV sound file. Specify the WAV filename to load with filename.WAV. This may not be subsitituted with a variable. This command requires a soundcard. This command makes use of the standalone program ASWAV.EXE, the Awesome Software Wav player. If your game plays Wav files, make sure you include this small program with your game, and put it in the same directory as all of your game files. Example: * Play the file letsgo.wav #Wav "letsgo.wav" * Plays the wav file. Related Commands: #Midiplay, #Midirest, #Sound #Win Name: Win the game. Format: #Win This command displays a "You beat the game" message in the Message Window, waits for the player to press a key, and then resets the game to the startup program. This command is used to tell that player that he/she won the game, but you may wish to create more interesting victory sequences, using the #Viewbrd command, as well as other graphic oriented commands to show a story sequence for what happens once the game has been beat. You may also show credits with the #Text command. Once the victory sequence has been completed, you may wish to use the #Win command, or you may want to use the #Dos command to quit directly to Dos, or use the #Reset command to return to the startup program without displaying the "You beat the game" message. Example: * Alright, you beat the game!!! #Win * Ends execution of the program, and resets the game * to its startup program. Related Commands: #Over, #Reset, #Viewbrd Final Notes On RPGCode If you have read everything in the reference section, then you are an expert on programming in RPGCode. You may wish to see some of these examples used in real games, however. Experimenting is fine, and you should examine the programs that are used in the example game that comes with the Toolkit. Occasionally, you will get an error message on the screen if there is an error in your programming. All error messages are displayed somewhere around the Message Window, and after that, the line where the error occurred is displayed in the Message Window. The error messages usually are quite straightforward in telling you what you have done wrong, but if you can't see what is wrong, first look at the example format of the command in question in the reference section of the manual to see if it matches up. Often an error occurs if you forget the '#' symbol before a command (actually, this will put the command you want executed in the Message Window, which is annoying). Also, if you get an error, it may be because you used the wrong type of variable in a command, or the command wasn't looking for a variable at all. In any event, expect errors. There's no way you'll never encounter an error (I hope there are no errors in the example programs in this manual, but there very well may be). When you first start creating games that use programs, start out small and get a feel for the individual commands before you go on to a full fledged game that widely uses concepts like setting conditions, and using some of the more vague of the commands (such as #Fbranch). RPG Translator Playing Your Games Introduction Finally it's time to see what we've accomplished. At this point you have enough knowledge to create a fairly impressive RPG. Now it's time to actually play it, and more importantly, debug it, as your RPGCode programs will probably have bugs. The RPG Translator is the key program which allows you to play your RPG games. You can run this program by selecting it from the Toolkit main selection screen, or by running the programRPGTRANS.EXE. Fig. 1 shows the opening screen. More than likely you will be taken to the opening screen before anything else. At this screen you are prompted to enter the filename of the main file which is your game. Enter this filename, and your game should start. Midi Music And Windows If your game uses Midi music, it requires Windows 3.1 or higher and a soundcard. If this is the case, you must run the program RPGTRANS.EXE from Windows, or run with while Windows 95 is running. The Midi files are played one after the other like a soundtrack. If a room specifies a file to be played, it will play it as soon as the current file is done playing. The files to not stop in between. Also, to ensure that a file will continue to be played even after it has ended, make sure you include that filename in all the boards you wish it to be played on. The Toolkit makes use of the file Midi.EXE, the Awesome Software Midi Player, to play the files. This program requires Windows and that's why a game that plays music requires Windows to run. When you have quit the translator, the current song will continue to play until its end when Midi.exe will unload itself from memory and return to Windows. Autorun and Running The Translator program will automatically run a game with a main file entitled Main.gam. If such a filename exists, then the opening screen will not be shown. Instead, the file Main.gam will be run automatically, just as a standalone RPG would. Autorunning is useful once your game is completed, but until then, it is a good idea to not name your main file Main.gam, simply for the sake of debugging your game. You may also create multiple games. In such a case, none must be entitled Main.gam, otherwise that is the only one that will be run each time. Once the game starts, either by autorunning or you specifying which game to run, the first thing that will happen is the execution of the startup program. This program usually has a title screen, as well as the option to load a saved game or start a new one. It is also used to show opening cinema sequences and to set all teammate health variables for fighting. It is extremely important that if your game has fighting sequences that you set all HP, DP, FP, etc variables for each teammate in the startup program. For more information on the startup program, see the programming section of this manual. Once the startup program has ended, your main player will start the game on the opening board. The game is in progress! To move around, use the arrow keys on the keyboard. All programs you set on the board are run when you walk into them. Assuming they have no bugs in them, everything should run smoothly. If you want to run the constant run-time program, hit the key on the keyboard which you assigned to it. When you create the run-time program, be sure to include important options such as Quit to Dos, to allow players to quit the game from a menu. If your runtime program doesn't have a Quit to Dos option, then the only way the player can exit your game is pressing Alt-X on the board screen. At this point, the way you proceed is really up to you- it's your game. You should, however, walk around with your player testing out program files and making sure the linked boards work properly. Usually a new game is very prone to bugs that you must find and correct. Fixing Bugs No game is perfect on its first run. Even professionals hire people to play their games to find all the mistakes they've made. The RPG Toolkit eliminates many of these bugs by having much of the players' actions already coded and debugged. However, there will come points where your player can't walk in places he/she should be able to. Your RPGCode programs will often not do exactly what you want them to do on their first run. And worst of all- the game may lock up. All of the above problems do have remedies, and it's easy enough to find out why something is going wrong. It's fixing it that causes problems. I have listed here a few problems you may encounter and some possible solutions. Problem 1- I can't move to the next board. Solution- Sometimes you may be playing a game and your character will move to the edge of the board and will not be able to move onto the next board. When this happens, there may be a number of reasons: - There is no link to the next board. To check this, go into the board editor in the program RPG.EXE and load the board in question. Check the board information by pressing I. Check the links. There may be one missing, or the filename that the link points to may not exist. - It may be that the tile to which the player will move to on the next board is solid. If this is the case, then the player will not move onto the solid tile on the next board. To check this, load the next board in the board editor and check the tile to which the player should go to by pressing ENTER. If the tile is solid, change it to Normal or Under. Problem 2- My character graphic is just a black box with a blue line through it. Solution- This happens when you have not specified a player graphic, or the graphic which you have specified is not found on the disk. To fix this, go to the opening board in the Board Editor, and press I. In the board information screen, change the player's graphic filename. Problem 3- My runtime program won't run Solution- You may be pressing the wrong key. Check the Main File in the Main File Editor in the program RPG.EXE to see which key is correct. Also, the filename of the program may not exist, or the program may not do anything in the first place. In this situation, check the program itself to see what it actually does. Sometimes including a little #Sound statement at the very first of the runtime program will allow you to at least hear if the runtime program is being run each time you try it. Problem 4- One of my programs just isn't working right Solution- This is by far the worst problem you will encounter. Programs are rarely perfect the first time they are run. Usually, if there is a problem with the way you use a command, the Translator will tell you what the problem is when you run the program. This is one of the hardest problems to fix because there is no cut and dry method of determining if the program is doing something wrong. The best solution is to load the program in a text editor or the Program Editor and start at the top line, and trace through its steps in your mind. Maybe a variable isn't being given the correct value, maybe something is branching or fbranching to the wrong place in the program. The only way to fix this problem is to look through the programming code yourself. Problem 5- The game locks up Solution- In almost every case, lock ups are due to mistakes in RPGCode. You will probably find that lock ups only occur when you run a program. This is easily fixed. Just look at the program causing the lock ups in a text editor or in the Programming Editor, and look for any loops that may continue on into infinity. Here's an example: * An infinite loop that will lock up * your computer. DO NOT run this!!!! :Top #Branch(:top) In the above example, the program will continue to branch to the label :Top forever, and so the computer will lock up. The only way to get your computer back after it locks up is by resetting your computer (or, if you are running under Windows or Windows 95, hit CTRL-ALT-DEL, and you will be given the option of shutting down the program). If you find anything that loops forever, put in some way for it to break out of the loop, such as in this example: #1!=1 :Top #1!=1!+1 #If (1!<12) Then <#Branch (:Top)> *Once the variable 1! Has a value of 12, the loop will no longer continue. Locking up will almost always be caused by something like this. There are times, though, that for some reason a program will just lock up for no discernable reason. This is true of the RPG Translator. If the program seems to lock up for no reason, it is probably caused by the program itself. It may even be caused by your computer, due to faulty internal configurations or other reasons. If this persists, contact Awesome Software with a bug report. Problem 6- I can't enter fighting sequences, or I get a Game Over the moment I enter them. Solution- This will happen if: 1) There is no fighting allowed on the board OR in the game (check the Main File and the board file itself). 2) The chances of getting in a fight have been set astronomically low (ie, if the chances of getting in a fight are 1 in 200,000). Check the Main File. 3) The background file, enemy file, or teammate files do not exist. Create these files! 4) There are no enemies with the same skill level as is set by the board- create enemies with the proper skill level. 5) You have not set HP variables or the variables upon which your player depend are not set. Set these variables with the startup program. It may also happen that the variable required for your teammate to be on your team is not set. Set this in the startup program, and check it in the Main Fight File. Expect to find lots of bugs in your games, especially in the larger ones. The only way to fix them is to check all the settings you have made for the board you are on, the programs on the board, etc. It may take a little time, but it's worth it! Extended Tools Introduction The RPG Toolkit Development system has a number of extended tools- utility programs to help in game development. These programs are: SEARCH.EXE, FLIP.EXE and ROTATE.EXE. You may run these from Dos or Windows, or you can select them from the Toolkit Main Menu. Search.exe One of the most useful programs is Search.exe. This program searches a game and records all the files that the game uses. Once you run this program, you will see the main screen (Fig. 5). Press any key, and you will be taken to a screen which asks you for the filename of the Main File to search. Enter a filename (no extension), or type EXIT to quit. You will next be asked for a filename to save the search results to. Select a name and press Enter. The searching process will begin. The program starts by reading the Main File, then the starting board and "walks" through the game, keeping track of all the files the game uses. This will take some time, depending upon the size of the game. Once it is done, it will tell you and then you can exit back to Dos or the Toolkit Main Menu. The search results are saved in the filename you had specified. You can view this file with a text editor or word processor. This file contains all the filenames which the game uses. This can be useful when moving files to another directory that belong to a specific game. Note: Search is not entirely reliable. Depending upon the complexity of the game, it may miss a few files. You should be able to tell which ones these are by playing the game, and seeing the ones it missed. Also, search cannot dissect a really huge game due to memory limitations. Flip.exe and Rotate.exe I will explain these to programs together, since they are similar. These programs each to fairly simple things: Flip flips a GPH graphic tile over and Rotate rotates a GPH graphic tile 90 degrees. This is useful when creating large graphics that span many tiles and are symmetrical. This way you only have to draw one half, flip the graphics you have, and you will have the whole picture. Both programs work basically the same way. You are prompted for a filename of a graphic to flip or rotate, and then you are asked for a filename to save the new graphic to. Then you will see your results and you will be asked if you want to flip or rotate more graphics. Selecting No will quit the program. Concluding Comments Now you know everything there is to know about the RPG Toolkit Development System. I thank you for trying out this product, and hope you make many interesting games with it. Following are a few Appendices that are used basically for reference. Your should be able to find answers to any questions about the toolkit in this manual. If not, contact Awesome Software at its website. Appendix A -Color Codes- Although you can use the LIB command in the Tile Editor, knowing the color codes can be a lot faster than searching through the library. If you use the EGA graphics mode, the Toolkit will simulate a 256 color palette, even though there really are only 16 colors. This is useful because when future versions of the Toolkit are released which support more colors and higher resolution graphics, version one will still be able to use tiles created by these newer versions. Basic EGA 16 Color Palette: 0- Black 1- Dark Blue 2- Dark Green 3- Cyan 4- Red 5- Purple 6- Brown 7- Light Gray 8- Dark Gray 9- Light Blue 10- Bright Green 11- Bright Cyan 12- Pink 13- Bright Purple 14- Yellow 15- White If you distribute your games, be sure to include the file 256to16.pal, which is the file that allows the EGA mode to simulate a 256 color palette. Appendix B Distribution Notes The RPG Toolkit Development System was created with the intent of allowing people to create and distribute their own games. The following are the restrictions imposed upon distributing your games: You may not sell your games, or distribute them for commercial purposes. If you wish to do this, you must obtain a licence from Christopher B. Matthews, creator of the RPG Toolkit Development System. You may distribute any graphics tiles that come with the Toolkit. You may distribute your games with the executable file RPGTRANS.EXE only. While the RPG Toolkit is shareware and you may distribute the entire Toolkit freely for non commercial purposes, for distributing games, RPGTRANS.EXE is the only file you are permitted to distribute. The filename of RPGTRANS.EXE shall not be changed or modified in any way. You should include the file 256to16.pal for proper color coding. Your games must include a proper disclaimer identifying that neither Christopher B. Matthews nor Awesome Software will be held responsible or liable in any way for damages incurred by the use of this software, and that the user assumes full responsibility for the use of this software. You would do well to include this for yourself as well. The software may not be modified or changed in any way. You may not reverse-compile, disassemble, decompile, or otherwise change this software in any way. If you wish to distribute your games, you may want to move all the game files into a separate directory called Files or something, and in the main directory have the files RPGTRANS.EXE and 256to16.pal. This makes the directory structure a lot more tidy. To run your game from the first directory, you can create a batch file to do this, something like what's below: @echo off Cd files ..\rpgtrans Cd .. You can name this batch file something like Game.Bat, or whatever, and run it directly from Dos or Windows. Also, if your game uses Midi music, then it will require Windows 3.1 or better plus a soundcard. You must include the program MIDI.EXE plus the file VBRUN300.DLL with your game. Place these files in the directory that holds all of the game boards, graphics, etc. If your game makes use of Wav sound files, you must also include the file ASWAV.EXE (the Awesome Software Wav Player). Include this file in the same directory as all of the other game files. Here's a list of all the game file types: .BRD Board files. .GPH Graphics tiles. .CHA Character animation. .MID Midi music file. .WAV WAV digital sound file. .GAM Main game file. .FGT Main filght file. .TEM Teammate file. .ENE Enemy file. .BKG Fighting background. .PRG RPGCode program. .SPC Special move. .SAV Saved game. Happy Gaming!

Help Files for RPG Toolkit v1.4

whatsnew.doc

midi.doc

order.doc

rpg.doc