Developing VB Games

By Trent Jackson

Recently, I have spent some considerable time searching through PSC’s library of
game submissions. Upon viewing, almost all of the 600 or so submissions, which date
back from 1999 to now, a number of impressions and, ‘final conclusions’ about making
games will be forever left engraved in my mind. Most of the submissions all share one
similar thing in common. Any guesses? Well, mostly, they’re all unfinished projects.
Some of them, shamefully unfinished since they are actually quite good. For someone
who comes across these submissions and, is just starting out with VB, it’s all very bad
news because it causes serve procrastination.

It makes them possibly ask themselves, why so many incomplete projects? Is the
language simply no good for making games? Truth be known, I once thought that VB
was neither intended nor practical for making games with. I was wrong. Lacking the
required essential knowledge with the language, and not knowing how to do things the
right way very quickly imposed this conclusion. Very few books actually promote VB
game programming. Even fewer explain the benefits of using API calls. Out of interest,
some of the latest commercial quality games have been written in a variant of Basic.
3D games that will astound you. All written in Basic. Blitz Basic that is…

I recently took a quick glance at the Blitz language only to make one very, almost
immediate conclusion. Why would you bother with it if you have Microsoft’s Visual
Studio! First impressions with Blitz reminded me of QB. Quick Basic for DOS. There’s
no physical objects to click on, no form of any visual aspects whatsoever. Making a
game in Blitz looks to be twice as more involved than doing it in VB. Having said that,
some of the games that evolve out of Blitz are incredible! I’ve seen them with my own
eyes. If these games can be developed in Blitz, why can’t they be done in VB? Answer
is they can! Admittedly, Blitz does support the insertion of assembly code along with a
favor towards polymorphism. But still, it’s a variant of Basic with commands that share
almost identical syntax to VB…

Some incredible Blitz Basic games can be seen at www.imphenzia.com

Techniques Used For Making VB Games

1. Pure VB, OOP ‘Object Orientated Programming’

2. BitBlt and or StretchDIBits, API ‘Application Programming Interface’
3. Direct X

Games that are developed without bare minimal API necessities or Direct X
ingredients turn out to be very disappointing. VB by itself, without any other
externals is not possible for quality video game development. Unless your
intentions are to just mess about and have a bit of fun, don’t even give pure VB
programming a milliseconds thought for when it comes to making games. Don’t
get me wrong, if you’re new to VB, sure play around with all the objects, move
them around on the screen and learn from it.
But just don’t expect to make any sort of decent game by relying solely on these
objects. The objects that I’m referring to are the image & picture box controls.
Whilst they are entirely more than adequate for displaying almost all types of
graphic, placing multiple instances of them on the screen and trying to move
them about causes nothing but a whole lot of disappointing flicker. Part of the
reason for this is lack of vertical synchronization with the monitor. These objects
were never designed to be shifted around on the screen at varying speeds within
a video game. A host of API solutions exist which are specifically designed for
this purpose. They work reasonably well. More on this later…

Implementation Stages

Arguably, the best way to program, and if you’re any good at it, is to just dive
straight in and code it. I personally feel this to be entirely non-applicable to
making games. Normally turns out a mess if you adopt this approach. My advice
and the rules that I currently follow; paint a clear, crystal like image In your mind
of exactly what you want. Think it through, question its integrity at all possible
angles, most importantly; don’t over complicate it at the start. Build on it as you
progress. Trying to clone games is the hardest. If the game’s extremely good,
you have set yourself a very high target to live up to.

1. Game type i.e. (platform or shooter? horizontal or vertical?)

2. Concept (purpose of the game)
3. Title (the name says it all)
4. Complexity (reality check, can I really do this?)
5. Layout (visualization of what it will all look like)

I think most video game projects fail because people bite off more than they can
chew. Settle for something modest to begin with, learn from it and watch it grow!
It’s a tall order for average people like myself to deliver the ‘top-notch’ goods for
when it comes to video games. I have about 5 years of experience with VB and
only just quite recently that I can say that, I can make an O.K. game. Few people
start off with making Quake, Tomb Raider style games. Often though, I think
many people however place these high expectations on themselves only to be
very disappointed with the end result. As the saying goes, quality, not quantity!
60 finished O.K games are far more worth their value than 600 unfinished ones.
Even if there’re simple but at least playable and completed ones, there’s much
greater value in them. Always finish something that you start. No matter what!

Desired Ingredients

So, to break it all down, what physical elements do you need to make game?

1. Background graphics
2. Background music
3. Sound effects
4. Sprites & Animation
5. Coded Procedures
6. Error handling
7. Input handling
8. Speed regulation
Graphical Hurdles

It seems clear to me that making games is not just about programming. You
need to have other skill sets as well. Namely the ability to draw. Sure you can
always rip graphics from other games, perhaps even modify them to suit your
requirements. But, this takes away a significant amount of credit to the game if
it turns out to be good. Not to mention also that it’s a violation of copyright laws
that would obviously restrict the game to personal use or at best non-profitable
distribution. This would of course depend on the source of the graphics. Taken
from 20-year-old games I’d say there would be little concern. From something
more recent, undoubted lawsuits would be the result if the game were sold.

There’s just as much effort in designing graphics as there is with programming

the game. I have just recently spent about 2 solid hrs drawing a jet ski for my
next video game project. There’s 3 ways to generate graphics for games.

1. Bitmaps, jpegs, gifs, generated from graphics packages.

2. Code drawn graphics at run time using pixels, circles, lines etc…
3. Character maps.

In times gone by, graphics for games were drawn pixel by pixel by dedicated
teams of professional people. True, much easier nowadays with the aid of
modern graphics packages like; QuarkXPress, Illustrator, Indesign and so on.
Still very time consuming though. Prior to 1990, character maps were used
extensively throughout because of memory restrictions. Character maps are kind
of like a text font in my understanding. Possibly, the reason why they are often
called text graphics. Character maps consume less storage space because of
their low resolution. Some of the characters in the extended ASCII set have block
characters, which are primarily directed towards generating memory conservative
graphics. Also, having the graphics laid out in a map, in separated pieces allows
for extensive reusability. There are a lot of very smart algorithms that are behind
the successful usage of character maps.

Physical Design

Once you know the type of game that you want, and you have the concept in
tact, you have decided a name for it, you have a clear mental visualization of the
layout for it, you’re ready to put pen to paper! With the graphics that is!

Figure 1 Figure 2

Design the graphics first. This not only gives you more time to think about the
game but rather an opportunity to build your confidence up for the coding side of
it. Hype yourself up for the amount of action that you intend to have if it’s going to
an action packed game. Do the graphics and do them well. If you settle for
second best in the early stages then, chances are you’ll settle for further second
best solutions in the later stages. Set your goals marginally higher than what you
really expect to achieve. You’ll come off somewhere in between. Lastly, allow
yourself time limits to enforce on any particular task. Set a deadline for it all.

I personally use a package called QuarkXPress for most of my graphics work.

Using a combination of shapes and textures to produce the image that you see in
figure 2. Then I export the image to Photoshop where it gets pixilated and further
re-touched. The output is satisfactory and more than sufficient enough for my
intentions with it. Few more sessions in Photoshop will render vast improvements
of higher graphical detail and clarity. I create the required masks in Photoshop
like you see in figure 1. Using masks allows us to clip out the background, ‘white
area’, so that the background graphics in the game can be preserved.
This is achieved by first placing the mask on the screen, then by registering the
actual image on top and applying logical AND to the colours, we successfully clip
out the background area of the image.

After completion of all your graphics, start focusing some thought towards other
physical elements that include; screen dimensions, animation, and character
behavior. Namely character movement. Arguably, decided screen dimensions
should occur before actually drawing up the graphics. But, as good luck would
have it, modern versions of Photoshop make it easy to resize your images to suit
changed requirements. Within reason, you can reduce or enlarge without loss of
quality. During the stages of actual coding you may need to ‘tweak’ their size to
overcome any unfortunate oversights with the initial design.

Screen Dimensions

Games which use large screen dimensions of (1024 x 768) along with (200 x
200) sprites will be nothing but a huge disappointment when run on much less
than todays very latest performing systems. As a general rule of thumb, I have
found that (600 x 400) is a good choice. Now, I’m not necessarily talking about
screen resolution, but rather the amount of occupancy of the screen that your
game will take up. You can define in your game a playable area of (600 x 400)
without having to resort to changing the resolution of the users monitor. This is
extremely annoying and puts your user at risk with their other applications.

Character Animation

Animation can be achieved with as little as two images. This is more than enough
In most cases. Using ridiculous quantities of images for animation is completely
unnecessary. Assuming that there are only a few different images, the human
eye starts to preserve this as one still like image at more than about 20 or so fps,
running animation at 20 fps would require at least 10 very distinctly different
images in order to have any ‘real effect’. Ideally your game will run at about (10-
20 fps) and your animation between (2-5) fps using (2-5) different images. The
reason that TV console games run so high at 50 fps is because of the TV’s
vertical 50Hz. It has to be matched, synchronized if you like. Most of the frames
are simply repeated the same. The rate of animation is nowhere near this since
very few games use more than a few or so images for character animation.
Of course, another consideration is graphical movement. 50 fps would be just
fine if the frames only changed by 1 or 2 pixels each time. Way, way too fast for
characters that were incremented by 5 or 10 pixels. The animation of only a few
different images would go entirely unnoticed. For PC games that you don’t want
to spend 10 years drawing up graphics for, scrolling speeds of 10 fps and
animation speeds of 2 fps are just fine. I have seen a few games where the
biggest complaint about them is being slow. Mainly because the increment of
movement was not enough. At 10 fps, incrementing something across the screen
one pixel at a time, it all looks terribly slow. Yes, at first thought, If the computer
has the performance, simply increase the frame rate. Or, make the wiser choice
of increasing the increment of movement. This way, the game will be more
compatible with a wider range of machines. Slow and fast, everyone will get to
play it. Don’t over do it though, too large an increment just doesn’t look right.

Character Behavior

Directly along side of animation is the character’s behavior. When the game
receives player input, be it from the keyboard or joystick, something normally
tends to happen. The player’s character may jump, move left or move right, or
alternatively, surrounding sprites may start to chase the player. These are all
considerations that require immense thought. Animation and character behavior
is in my humble opinion what truly makes modern video gaming. It’s where all
the excitement of the game exists. Timing plays a key role mostly. Everything
must be synchronized, from player input right through to scrolling the scenery.

Speed Regulation

Possibly the most common problem that most VB games have is the lack of
speed regulation. Here’s a commonly seen statement; ‘runs at perfect speed on
my computer, PIII 866 MHz, but the game’s unplayable on yours, P4 3.0GHz’.
Not any more! Part of the solution is to use the ‘timegettime’ API. The other part
is program structure. Never use VB’s timer control for games. Instead, implement
one base delay, if you need counters and procedures executed at set intervals,
pre-scale variables from this base. For example; base delay is 100mS and you
wish to increment a variable every 5 seconds. To do this you use a pre-scaler
which triggers this variable after a count of (50 x 100mS) = 5 seconds. Now, this
variable may be used to perhaps flash a message on the screen every 5 seconds
or, move a sprite around. VB’s timer control has a lot to be desired. In actual fact,
multiple instances of this control fail!!! There’s a time and a place for this control
and it’s certainly not for games. Other than that, code is far, far easier to follow
when you have only one, very distinct central delay.

timegettime API Allows For Smooth Arcade Like Games

Here’s a practical example of a tried, true and tested procedure that uses the
timegettime API to provide a pretty nifty speed throttle that does a lot more than
you may first think….
Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Public Declare Function timeGetTime Lib "winmm.dll" () As Long

Public Function Speed_Throttle()

'//
Base_Delay = 100
Time_Taken = (timeGetTime - Time_Sample_mS)
If (Time_Taken < Base_Delay) Then Sleep (Base_Delay - Time_Taken)
Time_Sample_mS = timeGetTime

End Function

The base delay will always be 100mS no matter what! The speed throttle does a
nice job of balancing the amount of time that the Sleep API needs in order to
maintain a delay of precisely 100mS. The Sleep in effect does the actual delay
but for how long exactly is all dependant on the return value of the timegettime
call. In greater depth, if a frame takes 20mS of time to process then Sleep will be
executed with 80mS. On a faster system this same frame may take just 5mS.
therefore Sleep will be issued with 95mS of time.

There’s more than meets the eye to the advantages of this procedure. Windows
and API calls can be unpredictable sometimes with how long certain processes
take. This is called latency, or better know as lag. The speed throttle provides all
the necessary compensation for this, providing that this latency is no greater than
the base. 100mS of lag would almost be unheard of, which makes the throttle
extremely superior when you consider its outright sheer simplicity. One of the
main reasons that a lot of games don’t run smooth and consistent is because of
this latency. Fluctuations of just a few mS in delay can ruin a games playability.

Coding Structure

Break procedures down into as many sections as you possibly can. Keep the
code minimal, tight and efficient. The use of Static variables highly promotes well
organized, less confusing code, which require variables that share a similar
purpose to be repeatedly used with the same name. Of course Dim them if their
value doesn’t need to be retained at the end of the procedure. For example; if I
choose to use a variable named ‘animate’, and it’s a requirement in a number of
procedures, plus its value must be retained, simply Static it in each procedure
instead of resorting to Public or Global alternatives which will require unique non-
conflicting names for each and every use. Static variables may be a tad more
memory hungry but, the extra clarity that your code will gain is well worth the
trade off. Also, despite many peoples belief, DoEvents is absolutely positively no
threat whatsoever to the performance of your program. Placing it in a condition
will likely consume more resources than you think you might be saving. However,
how you use it in your program makes all the difference. You need but only one
occurrence of it. Using multiple occurrences is unnecessary. Plus, too, placing
DoEvents before and after rendering to the screen will result in a lot of flicker.
Main Loop

Do While Game_Over = False

DoEvents
Play_Field.Cls
Call Flash_High_Score(True)
Call Scroll_Background(True)
Call Poll_User_Input
Call Level_Control
Call Background_Jumping_Fish
Call Speed_Throttle
Loop

A lot of good games use the approach like the one shown above. I feel this to be
the most logical way and agree with it all mostly. One tight main loop, which
yields to all of the appropriate calls. The sequence of these calls can be critical.
Really depends on the game. But one thing’s for sure, DoEvents first, wipe the
screen next if you’re using an API based approach, branch accordingly to what
else is required in the game…

Coding Style

Widely agreed upon is the fact that ‘Select Case’ arguments are far superior to
using ‘IF’ conditions. Not only will you gain additional speed in your program, but
the overall improved readability, and clarity of your code will really surprise you.
Of course, not everything is feasible to do with ‘Select Case’, but normally the
main structure of a procedure can be easily handled with its use. Inside this main
structure you can place your additional code that may contain a combination
of almost anything. IF’s, Do’s, any mathematical expressions, you name it. While
a tad more complex than using IF’s for conditions, alternative Boolean algebra
expressions are well worth the extra effort. You will gain extra speed and much
less required code. Consider the following…

Instead of this
IF Player_X < 100 Then Player_X = Player_X + 1

Do this…
Player_X = Player_X + (Player_X < 100) * - 1

Inside the brackets is the actual condition. The Player_X variable will always be
incremented by 1 on the condition that it’s less than 100. You can also place a
host of many different conditions inside the brackets which may include other
variables that maybe outside the scope of what you’re actually incrementing.
There’s no need to use IF’s for such simple things. Don’t make things complex
when they don’t need to be. Restrict IF’s for other more complex scenarios.

Sprites

There is no exact, official definition for a sprite. The terminology for it is extremely
broad and quite confusing. Arguably, traditional sprites were developed to quickly
composite a collection of individual pieces together from character maps that
gave the illusion of one actual image. Most commonly, nowadays with more
modern video games, sprites refer to separate images that are integrated into the
background scenery. The characters that you see moving around on your screen
are in fact considered as sprites. Nintendo refer to sprites as objects that store
screen coordinate information for obvious collision detection purposes. This is far
closer to my first initial suspicions. Another synonym for sprite is BOB’s, or Blitter
Objects. I personally perserve sprites as graphical objects.

For you, as a Visual Basic programmer, a sprite should represent something that
that’s a way in which you can collate a collection of one or more graphical
images and screen coordinates together into one neat package. You essentially
create the sprites by blitting the images to the screen and keeping tabs on their
exact location by either using Type variables or, by using objects like VB’s shape
or Line to constantly track / monitor their location on the screen.

Collision Detection

By using VB’s internal shape object we can constantly monitor the graphics by
tracking their movement. When the images on the screen are moved, the shapes
move in the exact same manner. When required, the shapes can be passed to a
collision detection procedure for checking. The shape object is perfect for this
since it has all the directional and size properties that we need. X-axis, Y-axis,
height and width parameters that will need to be set to match the size of the
image. This method helps with debugging since you can make the shapes visible
and watch them move in the exact same accordance as the images. Obviously,
at any other time the shapes visible property will be set to false. If some of the
graphics need to be rotated, VB’s line object will do nicely.

Public Function Sprite_Collision(Player As Object, Target As Object) As Boolean

'-------------------------------------------------------------------------------
'This is quite comprehensive, checking all 4 corners and also to see if the '
'sprite is inside another which may occur if one is much larger than the other '
'-------------------------------------------------------------------------------
'//
Dim Player_X1 As Long
Dim Player_X2 As Long
Dim Player_Y1 As Long
Dim Player_Y2 As Long
Dim Target_X1 As Long
Dim Target_X2 As Long
Dim Target_Y1 As Long
Dim Target_Y2 As Long
'//
'wall locations player and target
Player_X1 = Player.Left 'left Wall
Player_X2 = Player.Left + Player.Width 'right Wall
Player_Y1 = Player.Top 'top Wall
Player_Y2 = Player.Top + Player.Height 'bottom Wall
'//
Target_X1 = Target.Left 'left Wall
Target_X2 = Target.Left + Target.Width 'right Wall
Target_Y1 = Target.Top 'top Wall
Target_Y2 = Target.Top + Target.Height 'bottom Wall
'//
'-----------------------------------------------------------------------------
'all 4 corners, sprite to sprite '
'-----------------------------------------------------------------------------
If ((Player_X2 >= Target_X1) And (Player_X1 <= Target_X2)) And ((Player_Y2 >=
Target_Y1) And (Player_Y1 <= Target_Y2)) Then
Sprite_Collision = True
'//
'-----------------------------------------------------------------------------
 'sprite inside sprite?, check all 4 corners again, sprite to sprite '
'a sprite inside another sprite occurs when on is much larger than the other '
'-----------------------------------------------------------------------------
ElseIf ((Target_X2 >= Player_X1) And (Target_X1 <= Player_X2)) And ((Target_Y2 >=
Player_Y1) And (Target_Y1 <= Player_Y2)) Then
Sprite_Collision = True
End If

End Function

Using the ‘With’ statement makes is easy to track the location of your images.
Whenever the image moves, ‘With’ is used to set the shapes new parameters.

For example;
With Game_SCRN.PlayerSprite
.Left = PlayerX + 8
.Top = PlayerY + 25
.Width = 72
.Height = 32
.Refresh
End With

I have just moved the player’s image by 10 pixel, both vertically and horizontally.
Straight after doing this I now need to pass these new coordinates to the shape
object, which out of interest is a rectangle for this image. You could use a circle
or a square if this is deemed more suitable for the type of image you’re using.

Notice the offset of 8 for the .left property and 25 for .top? Reason for this is
to center the shape inside the image. Also, some of it’s to allow tolerance. I.e. the
boat has to be well and truly touching the snake before they lose a life in the
game. Offsetting is something that you need to play around with and tweak to
suit the individual game. Best way to do this is to make the shapes visible and
adjust the offset by visual trial and error. No rocket science with this, just a simple
tried, true & test method that works. Dramatically reduces development time too.

Figure 3

In figure 3, VB’s shape object can be seen placed over the image. Depending on
what exactly is happening in the game, the size of the shape may need to be
adjusted to favor the inner region of the image. Otherwise false triggers from the
collision detection may result. In some cases you may need to use 2 or more
shapes to prevent this. With the image shown in figure 3, two shapes could be
used to provide almost near perfect collision detection.

Here’s how…

Figure 4

With the only added complication of having to update the parameters of 2 shapes
whenever you move the image, collision detection accuracy is more than
adequate enough for most games. Of course, even more shapes could be added
for even further desired precision, I think it’s really uncalled for. Especially when
you consider that you’ll probably move the image with increments of at least 5
pixels at a time. The bottom shape in figure 4 only overlaps the image by a few
mere pixels. Plus, most images that you will use will be far more symmetrical.

DirectX or API ?

Personally, I have never as such made a game using Direct X. I do know all its
strengths and I also know its weakness. The further in depth that I travel with VB
the more I’m starting to favor the possibilities of implementing it within a game.
I see using Direct X as something of questionable practicality. The questions you
need to ask yourself in attempts of deciding as to if you need it or not are…

1. Is the game 3D?

2. How complex are the graphics for?
3. Does the targeted audience have the computing power for it?

I have seen two similar like NES emulators that both share almost identical code
with the exception that one uses Direct X and the other implements an array of
API’s to do most of the work. In terms of performance, they’re almost on par. The
graphics are neither 3D nor complex in any of the NES games. With the Direct X
emulator, I see this as a waste of resources with power that will never be fully
unleashed. I will reserve my final conclusions about DirectX until I actually have
the chance to fully use it within a completed project.

There are a number of restrictions with relying solely on API’s. Especially with
sound. I have seen no real easy way of being able to channel through multiple
occurrences of different sound effects. In other words, ‘mixing’. Direct X allows
you to easily mix music and sound effects with minimal code. I see the biggest
weakness of Direct X as being compatibility. There are too many versions of it
that will undoubtedly restrict your game to a limited audience.

Playing The Game Is All Part Of It

In the final stages of developing a game, there’s a lot of time that’s required to
ensure that your users get the most possible entertainment out of it. The only
way to do this is to play it. On a trial and error basis, you’ll need to tweak things
as you play. If you don’t enjoy playing it, chances are then, neither will your
audience. As the old saying goes, “don’t feed someone else something to eat
that you wouldn’t eat yourself” A big, big part of it all really is playing the game.