Lesson 1

GL (very) Basic Tutorial

aka "so, you want to write a game, do you?"
© 2008 PeeJay

Lesson 1 - Starting Off

So, where do we begin on creating our game? Well, the first place with any game design is to have an idea, but, as anyone will tell you who writes games, that is all you need. I think of writing a game the same as most authors think of writing a book - when they set out, they have a basic plot, but nothing else - they don't know what their hero is going to do until they are writing it. I'm a little like that when writing a game; I'll have an idea for an outline of a game, code that bit, then think about something else I'd like to add, and so on and so forth. Of course, if writing a remake of a classic game, that doesn't apply as much, but doing an original game, that is the method I adopt.
Of course, there is no right or wrong way - it is whatever suits you. If you want every last detail pre-planned before you even switch your computer on, then good luck to you - I can't work like that, but I'm sure a lot of people can. I need to visualise something to spark my imagination - some people can let their imagination run away with them without needing that inspiration.
In this instance, though, I am merely writing the bones of a game - no fancy stuff, so I have a very clear idea of what I am going to write. So, what are we going to do? Well, we're going to do a game involving moving around the screen shooting baddies that come in from the sides of the screen. We'll have multiple shots on the screen at once, 8 directional fire, a simple scrolling background, animated baddies, and sound effects. Sound good? Well, okay, so it's not earth shattering by any means - but only 25 years ago, 8 directional firing was actually a huge selling point!
So, let's make a start - look at the source code and read this along with it - at the moment it doesn't do much at all, but it will - believe me!
GLBasic lets you leave lots of blank lines in your code and ignores them, but it can make it far easier to see what's going on! Also, the tab key allows you to tab things out - again, it can help enormously, especially for seeing where you are in a loop.
So, line by line, we have:
// --------------------------------- //
// Project: Lesson One
// Start: Friday, February 01, 2008
// IDE Version: 5.154
// --------------------------------- //
the // tells GL to ignore what comes next - it used to be known as a REMark - it is handy for making notes to yourself.
SETSCREEN 640,480,1
this tells GL to set the screen resolution to 640 x 480 and full screen running - that can all be altered (see the help for more details). Note, the demo version of GL will only allow a maximum size of 640 x 480.
Here is a very useful command for adding a speed limit to your game. In order to stop games running too fast on powerful computers, we can tell GL how many times to update the screen - in this instance, 60 frames per second. Don't worry if the game is running on a really slow machine - it will still work okay - it merely acts as a speed limit, so the game will go no faster than this speed.
You can also forget about these 2 commands and just open the menu "Project/Options" and set the startup screen size and refresh rate in a dialog.
Now for a trickier one:
This tells the computer that for the next graphics we load into the program (sprite of font - see later), that the colour with Red, Green and Blue values of (0,0,0) - ie, black, will be transparent. This means that when we draw them on the screen, we will be able to see the background through any black pixels.
GLBasic by default has this set to RGB(255,0,128) for sprites and RGB(0,0,0) for fonts.
LOADSPRITE "player.bmp",0
Now we load the graphic into memory, in this case, it is a small picture of a man. Around the man is black, so this will not be drawn. Note, at this stage, we are not drawing the man - just loading it into memort ready to be drawn. We have given it a number - 0 - so from now, if we draw sprite 0, it means that image.
GLOBAL px=300
GLOBAL py=220
Now, because we want our player to be able to move around the screen, we must be able to keep track of where on the screen he is. So, we will call the co-ordinates px and py (for player x position on screen and player y position.)
Now the next line is trickier, it is the start of a WHILE ..... WEND loop. We have the command
It is pretty much self explanatory. Given it is the start of a loop, it is marking the start of the loop and will continue the loop until KEY(01) is true. KEY detects keypresses on the keyboard, and, if you check the keycodes utility in the tools part of the IDE, you will find that 01 is the Esc key. So, it is literally saying, start a loop, and continue to loop back to here until the user presses the Esc key, then jump out of the loop. Easy, huh? So, what comes next?
Aha - this isn't a command. This is actually calling the function that will be written - functions are a subroutine that can be called at any time. You can also pass variables to, and get information sent back from functions - but more on that in a later lesson.
This marks the end of the loop, started with WHILE
This simply terminates the program.
Now we come to the function itself - started with FUNCTION and finished with ENDFUNCTION
This draws the image stored in sprite number 0 at the co-ordinates px along the x axis, and py along the y. Note, the x axis is horizontal, and starts at 0 for the extreme left. The y axis is vertical, and starts at 0 for the very top.
But hold on, haven't we just drawn the picture? Why do we now need to tell the computer to show the picture? Well, this is because GL Basic uses a system called "double buffering" - what it actually means is that when you draw a picture, it is drawn to an "invisible screen" (the backbuffer) and you can't actually see it until you show the back buffer (move it to be the front buffer, hence the term double buffering.) You might be wondering what the point is of doing that. Well, since displaying the back buffer is instant, but if you have a lot of things to draw, it may take a few milliseconds to draw them all, without using the back buffer, it is possible that the monitor would refresh it's picture halfway through you drawing your screen, and this leads to flicker. By using double buffering, it eliminates flicker.
Do make sure, though, when you have finished drawing the objects on your screen, you use SHOWSCREEN - otherwise they will just be drawn to the back buffer, and you won't see anything!


That's it - end of lesson number 1. Try it out - run it. You should see a man in the centre of the screen. You can't do anything yet, apart from pressing Esc to quit, but it's a start - and it will be easy to get things going from here, believe it or not.
Download the source code and media files for this lesson.
Previous Lession
Next Lession