Some interest has been shown on the Liberty BASIC Forum in game creation. Since this may be the only niche I can fill in this wonderful LB community I'm going to give the article-writing machine a whirl. In this series of Beginning Game Programming articles I am going to present to you the "game outline" that I use with my high school students. After explaining the different areas of the outline we will begin putting meat on the outline with new features being added and explained in subsequent articles. Each new article will build upon the last We will only use native LB commands and strive to solve each problem in the simplest and shortest way possible.
At the onset, I am no guru but I do enjoy trying to solve problems. I am a high school technology teacher and have been "trying" to teach BASIC programming to my students over the past two years. I use games because students are interested in them and are more motivated by them than with traditional programming curriculums (I'm more motivated by games, too). As with my students, when the helpfile says it as good or better than I, I will refer you to the helpfile. The helpfile and Alyce's Mastering Liberty BASIC 3 have become my two best friends when trying to solve LB problems. Feel free to contact me with any problems you are having. I am continually learning, if you aren't then you need to check your pulse, so I don't always know the best way but I'm open to better ways (just don't flame me in the process, I hate it when people do that).
Now for the games we will be making, yes I said games, as in two. There are so many possibilities that I've had a hard time deciding on a single game to make in these articles and also I wanted to try and appeal to as many people as possible. The games will be of the arcade type. We will be working on both games simultaneously, as they both will serve to demonstrate the same principles but in different ways (hopefully). The first game will be a shooting gallery were you get points for shooting different targets such as ducks, cans, bottles, balloons and others. The second will be a submarine command game where you are the sub, trying to blow up the ships on the surface and enemy subs in the deep while avoiding their attempts to blow you up. We will start out slowly, at the end of this first lesson we will only have our backgrounds up and the sprites that we are using sitting statically on the screen. But after that the possibilities will be endless.
There is one other topic that I want to address before we dive into the outline. My students always set out to design and create the next greatest Playstation, GameCube or Nintendo game. With LB you can create some very good and fun games, but it was not designed to create the graphic intensive games we have come to expect in the commercial market. So don't expect anyone to come to your door offering you money for one of your games anytime soon (If by some miracle this does happen be sure to mention my name). If you are serious about learning programming Liberty BASIC is a great first language, many people still use it even after they have learned some of those "high powered" languages. Think simple and start out simple.
| Menu |
I have found it extremely helpful when working with my students to have a framework to build upon, much like a frame upon which you build a house. Without the outline you get a patchwork of code that is hard to debug and follow. The outline also keeps your code organized and neat. Another advantage is that it will help us know where to put new code into a program.
Now let's look at the Game Outline, this file is included in the files section:
Outline for Setting Up Liberty BASIC Games
'I. Window Setup 'II. Load Bitmaps 'III. Initialize Variables 'IV. Setup Sprites 'A. Set Background 'B. Add Sprites to the Window - addsprite 'C. Set Initial Location of Sprites - spritexy 'D. Set other Sprite Attributes 'V. Initialize Timer, set no less than 56 'VI. Initialize Keyboard and Mouse Events 'VII. Timer Branch 'VIII. Quit Branch - unloads bitmaps and closes windows 'IX. Branches called by Mouse and or Keyboard - user entity movement 'X. Subs Called by Timer Branch
I. Window Setup - we place any code that has to do with our game window window type, window size, window location, graphicboxes, statictext, etc.
II. Load Bitmaps - we use the loadbmp command to load all of the bitmaps we will be using in our game.
III. Initialize Variables - we list all of our variables and their initial values. This helps you keep track of what variables you are using and their names.
IV. Setup Sprites - we setup our background and then perform all initial operations on the needed sprites such as adding them to the window, beginning location, scale, orientation, speed of movement, etc.
V. Initialize Timer - we turn the timer on and tell it what branch label to call each time the timer fires.
VI. Initialize Keyboard and Mouse Events - this is where we tell the program to look for keyboard press, mouse movement or clicks and what branch labels go with each.
VII. Timer Branch - This lists all of the subs that we want to happen automatically each time the timer fires.
VIII. Quit Branch - Contains the code to end our program.
IX. Branches called by Mouse and or Keyboard - this is the location where we place all of the code that is called by the mouse or keyboard events.
X. Subs called by Timer Branch - This is where we place the subprograms called by the timer branch.
At times there may be things that don't fit neatly into the outline but usually you will find a "best place" for them. I'll be sure to make comments about things that do not fit and tell you why I placed them where I did.
| Menu |
If you go to the help file and in "Index" type in "window types", information on all of the different kinds of Liberty BASIC windows will appear. For our games, will be using a basic window with a graphicbox. Any controls, such as buttons, statictext and the graphicbox, will be placed in the basic window. Our graphicbox will be smaller than our window - this will allow the other controls to be placed in the window without being covered up by the graphic box.
Now open the 1stWindow.bas file in your Liberty BASIC edit window. Run the program, , to get an idea of what the code here does. Figure 1 is the program that should come up when you execute the code. Look at the code and read the comments by each line. I've placed comments by each line in an effort to explain to you what each line does. I just want to make a few additional comments here about this particular file.
Note: Be sure to close the running program with the "close" button, , before trying to run another program.
Looking at the code, notice that my window is 20 pixels taller than my graphicbox. Also notice that the graphicbox's Y is 20 pixels from the top corner of the window. This allows the statictext to be seen; otherwise the graphicbox would cover up the static text. Further experimenting will reveal to you that the graphic box will cover up any other control that is placed within the graphicbox's designated area. So, to solve that problem we simply drop the graphicbox down.
Secondly, I want you to notice that we have used the turtle graphic commands to paint the background black (try different colors here such as red or blue) and then captured that black background and made it into a bitmap to use as the permanent background for the program. You can type in different colors other than black and experiment with them. Be sure to close each program, , that you are running before trying to run another one that you have made changes to.
Lastly, we went ahead and set up the timer and timer branch just like we would have for a game. At this point one drawsprites command would have drawn the background but we will be adding moving sprites in the next lesson so, we have gone ahead and prepared our outline for that eventuality.
Now, load 2ndWindow.bas. The difference here is the background. Run the program, , and see what I mean (Figure 2). Here we have loaded a bitmap into memory and then called it with the background command. Close the running program, , before moving on.
The only difference between 1stWindow.bas and 2ndWindow.bas is the background. In 2ndWindow.bas we loaded an unmasked bitmap into memory, subBG.bmp, and then we told the background command to use that bitmap as the background.
| Menu |
Now we are getting to the fun part, adding our sprites to the games. First, a little commentary on sprites; If you are totally unfamiliar with sprites I would suggest that you go to the LB Helpfile and under Sprites read all of that material. If you need further help on making and masking sprites I have two demonstration files located at my website: [http://jdexchange.jeff-davis.k12.ga.us/~rryles/] Go to the "Downloads" section, download and run the following two files: Sprite In Paint.exe and Sprite Masker.exe.
I am including the bitmaps that I will be using with these articles with the newsletter so it will not be necessary for you to re-create them. They are just quick bitmaps that I threw together in paint though. So if you are so inclined you are welcome to make your own (that way you will not have to give me credit if you decide to do more with these games and share them with others).
Now, back to our games. The goal here is to simply get our bitmaps to show up on our background. There are four LB commands that allow us to do this and we have already used two of them. Those commands are loadbmp, addsprite, spritexy and unloadbmp. For each of the games I am going to add two of the sprites and on your own you are to add the remaining sprites to each game. Next month I'll include the solution to this assignment. I am going to use the SubCommand game to show you how to include the sprites but you will do the same to add sprites to both games.
Load the 2ndWindow.bas file into your LB editor. Go up to File and SaveAs.
In the File name: box type in SubCommand1.bas and save it. (You can also do this with the 1stWindow.bas file and save it as ShootGallery1.bas later.)
Under each section of the outline add the code as you see it below to make that section code in your game look like what you see below.
Referring to Figure 3, loadbmp loads the bitmaps into memory. The first name we give is the name that we will use when calling the bitmap with the addsprite command. The second name with the bmp extension is the name of the bitmap as it is stored on our drive. It is easiest to keep the LB program and all associated files such as sounds and bitmaps in the same folder. If they are not in the same folder then you will have to give the location of the files that you are calling. So, for simplicity keep them all in the same folder.
Now referring to Figure 4, the addsprite command takes sprites that you have loaded into memory and places them on the designated graphicbox or graphic window. Notice that it seems like we have given the name of the loaded bitmap twice for each sprite we are adding. Actually we are cloning the loaded bitmap. The first name is the name we are giving the clone and the second name is the name of the bitmap we are cloning. This is useful if we wanted 10 subs in our game that looked like "goodsub" then we would only load "goodsub" once with loadbmp but add it 10 times to the window 10 times with addsprite. We would then addsprte sub1 sub; addsprite sub2 sub; addsprite sub3 sub; ...etc. We would have 10 subs that looked alike but they would all have different names allowing us to manipulate each differently.
In Figure 5 we are setting the X and Y locations of our sprites We use the spritexy command for this. We give the clone name and then the X and Y coordinates of the sprite. In case you are wondering the upper left corner of our graphicbox is X0 Y0. Anywhere to the right of the corner or down from the corner is a positive number. X is the horizontal (horizon) axis and Y is the vertical (up and down) axis. X is always first and Y second just like in the alphabet (hope you don't have to sing the whole alphabet song to figure that out).
The last thing we need to do here is to unload our bitmaps from memory with the unloadbmp command. Remember that this releases memory that we have used for use by other programs.
You should now be able to run, , your SubCommand.bas program. Your screen should look like Figure 7 below. If not, or if you run into errors go back and make sure you have typed in the code correctly.
Once you have your graphicbox displaying your sprites like the Figure 7 above go back and add the following sprites to the SubCommand1 program:
Though your bitmaps will be in different locations your graphicbox should look similar to Figure 8 when you run your SubCommand1.bas program.
Be sure to save your work frequently.
Now in the ShootGallery1.bas add the following sprites:
and place the board.bmp at X0 and Y244.
Though your sprites will not be in the same locations you should
see the following sprites as in Figure 9.
| Menu |
Whew! I hope this wasn't too much for you the first go around. But, we are now well on our way to making our games a reality. In the next issue we will see about getting our sprites moving and moving a few sprites with the keyboard and mouse.