REALbasic Sprites
Volume Number: 16
Issue Number: 8
Column Tag: Programming
By Erick J. Tejkowski
Develop powerful games in minutes
Game programming has long been a tradition of highly specialized source code,
libraries, and programming trickery, strictly for übergeeks. Until now. Armed with a
copy of REALbasic and this article, you will be writing your own games in no time at
all.
For high-speed games, it is customary for programmers to use special code to draw at
high speeds (often referred to as "blitting" routines). This stems from the fact that the
native drawing routines available in the Mac Toolbox are too slow for fast drawing,
such as that required by animation. Beginners will be glad to learn that REALbasic has
these abilities built in. With only a few lines of code, a programmer can attain
high-speed sprite-based animation. Add a few more lines of code and you have a game.
REALbasic takes care of all the nasty drawing routines behind the scenes and lets us
focus on the elements of the game. This article will demonstrate animation and game
creation using REALbasic sprites. By the end of the article, you should be able to
complete a small arcade-style game.
Building the Sprites
Begin the game project by opening your favorite resource editor. For our purposes,
the free ResEdit from Apple will do just fine. Create a new file and name it
"Resources". This is the only name REALbasic understands for resource files added
directly to projects in the IDE, so be sure to spell it correctly. In this new resource
file, create three resources of type 'cicn' and change the ID# to 1280, 1290, and
1300 respectively by selecting the Resource:Get Resource Info menu. In cicn #1280,
create a graphic for the hero of our game. In cicn #1290, draw an adversary. Finally,
cicn #1300 contains a picture of a projectile. For this example, we will use an
airplane theme. By now, you should have something that looks like Figure 1.
Figure 1. The Sprite Graphics.
Now that the sprite graphics have been created, save the Resources file and start
REALbasic.
Building the Project
When REALbasic starts, a new project is created automatically. Drag the newly created
resource file into the project. Now, open Window1 and drag a StaticText , a PushButton
, and a SpriteSurface control onto the window. The StaticText will display the results
of the game (i.e. win or lose), the PushButton will start the game, and the
SpriteSurface will control all of the animation and game play. Figure 2 shows the
completed interface.
Figure 2. The Completed Window1 Interface.
Once the interface has been built, double click Window1 to open the Code Editor. With
the Code Editor opened, create the Properties in Listing 1 by selecting New Property
from the Edit menu.
Listing 1. Window1 Properties.
BadguySprite(10) as Sprite
GoodGuySprite as Sprite
GunSprite as Sprite
gunvisible as Boolean
NumOfBadGuys as Integer
leftEdge as Integer
topEdge as Integer
Sprite properties are pictures that can be controlled by a SpriteSurface. We will need
10 sprites representing the attacking enemies, one representing the hero, and one
used for the gunfire that the hero can shoot. The Boolean variable gunvisible will allow
us to turn the gunfire on and off. The integer NumOfBadGuys , as one might expect, will
keep track of the number of BadguySprites remaining. The final two integer variables
(leftEdge and topEdge) will be used to center the SpriteSurface on the screen.
In addition to these properties, create three methods named InitSprites,
ClearAllSprites, and RemakeGun by selecting New Method from the Edit menu. The
InitSprites method will initialize all of the sprites defined in Listing 1. Open the Code
Editor to the InitSprites method and enter the code from Listing 2.
Listing 2. The InitSprites Method.
Sub InitSprites()
dim p as picture
dim i as integer
//init the good guy
p=app.resourceFork.getcicn(1280)
GoodGuySprite=SpriteSurface1.NewSprite(p,32,32)
GoodGuySprite.x=300
GoodGuySprite.y=435
GoodGuySprite.group=1
//init the gunfire
p=app.resourceFork.getcicn(1300)
GunSprite=SpriteSurface1.NewSprite(p,32,32)
GunSprite.x=-200
GunSprite.y=467
GunSprite.group=2
gunvisible=false
//init the bad guys
p=app.resourceFork.getcicn(1290)
for i=1 to 10
BadguySprite(i)=SpriteSurface1.NewSprite(p,32,32)
BadguySprite(i).x=rnd*600
BadguySprite(i).y=rnd*200-250
BadguySprite(i).group=3
next
NumOfBadGuys=10
End Sub
The InitSprites method demonstrates how each of the Sprites is created. First, the
icons created earlier are opened into a Picture object. Next, the NewSprite method of
SpriteSurface1 is called, passing the Picture, and Width and Height of the Picture as
parameters. Once the Sprite has been created, its X and Y positions are initialized. The
SpriteSurface will measure 640x480, so the GoodGuySprite will begin life
somewhere near the bottom middle of the screen. The gunfire starts off as not being
visible (i.e. gunvisible=false), so we assign its X postion somewhere off the screen
(GunSprite.x=-200). Later, when we want it visible to the user, we will simply move
it to a positive X position. The ten BadguySprites will begin at random X positions and Y
positions somewhere between -250 and -50, making them initially invisible. This
will change later, however, when they move down the screen towards the
GoodyguySprite. The last thing to notice here is the Group property of each of the
Sprites. The Group number is used for detecting collisions. Sprites with the same
Group number will not collide with each other. Sprites with different Group numbers
produce collisions. Now, when we talk about producing collisions, what this really
means is that the Collision Event of the SpriteSurface will be fired. For now, it is
sufficient to know that the GunSprite and the BadGuys have different Group numbers so
that they may collide. Further, the BadGuySprites have a Group number that is
different from the GoodguySprite, allowing them to collide.
Since all good things must come to an end, we need to include some code to destroy
everything we have created. Open the Code Editor, navigate to the ClearAllSprites
method, and enter the code in Listing 3. During the execution of the game, we may need
to kill a sprite (e.g. when GunSprite and badguySprite collide). Therefore, we should
not assume that all sprites will always be around. This is the reason we check for nil
status of a sprite before trying to kill it. If we try to kill a non-existent sprite, an
error will result causing the application to crash.
Listing 3. The ClearAllSprites Method.
Sub ClearAllSprites()
dim i as integer
//kill the GoodguySprite
if GoodGuySprite<>nil then
GoodGuySprite.close
end if