| Developing KNP
Code |
 |
My pa always said, 'A
computer game is nothing more than a program performin' small sequences of
instructions to complete some tasks'. I was never really sure what he meant by
that. But my pa would go on and say, 'Mind you, tasks must be
strung together to mean something to the player of the game'. And jus' as if I was deaf or
somethin' he would keep sayin', 'It's important to realise that a game is
made up of lots of very simple instructions re-used over and over and over again'. Yep, I
remember him sayin' that to me most every mornin'.
The idea for the game
needs to be broken up and looked at in detail, asking yourself how exactly each part is
going to work. It is not just a question of "How do I get the computer to do
that?", it's more a question of "What EXACTLY do I want the computer to do for
me at THAT moment in time".
Now next to playing
the banjo, shootin' things is a hillbillies favourite pastime. My neighbours
needed to have
a shootin' computer game developed, so here is an example of developing code to fit a main
idea.
Jethro wanted to write a shooting game using balloons as targets, and a gun sight where
the mouse pointer is. We can skip such things as title screens and intros, because the
game-play is our main concern. The balloon might emerge from the bottom of the screen and
float upwards until out of view, with a cross-hair following the mouse arrow. When the
mouse button is pressed, the cross-hair could turn into a sparkling star to give the
impression of firing.
[1] ALWAYS MOVE BALLOONS UP THE SCREEN
[2] IF MOUSE BUTTON PRESSED THEN CHANGE CROSS-HAIR TO STAR
This might be Fred's first two lines of code, and are both correct. But what was described
will not happen yet, for what happens when Fred releases the mouse button? The cross-hair
is still a star! So maybe another line to take care of that event:
[3] IF MOUSE BUTTON IS RELEASED THEN CHANGE CROSS-HAIR BACK
If the single balloon keeps moving up until it is no longer visible, there will be nothing
else to shoot, so another line of code must be created to make some more balloons to shoot
at:
[4] EVERY TWO SECONDS CREATE A BALLOON BELOW THE SCREEN
We have managed to break a simple description into four lines of code, and we certainly
have a better understanding of what will happen. There are still more details, which will
break up this program even more. Where exactly are the balloons being created? We are
changing the image of the cross-hair, but it is not following the mouse pointers
co-ordinates. Won't the balloons look rather strange moving in a perfect vertical line up
the screen, opposed to their natural gliding and swaying motion.
[4] EVERY TWO SECONDS CREATE A BALLOON BELOW THE SCREEN
[4][a] EVERY TWO SECONDS RANDOMLY
PICK A NUMBER FROM 0 TO 640
[4][b] AND THEN CREATE A BALLOON
[4][c] AND THEN MAKE THE BALLOONS X VECTOR = RANDOM NUMBER
[4][d] AND THEN MAKE THE BALLOONS Y VECTOR = 500
As you can see, task [4] can be split into four sub-tasks that need to be done. If it was
possible to just type the description of task [4] into the computer and it could run, the
computer might make all sorts of decisions you may not have wanted. Like creating it in
the same X position every two seconds. It may create the balloon so far down below the
screen that it would never be seen again. It is not for the computer to decide the outcome
of a program, it's your decision. You control every task and nothing creative is left to
the computer. By specifying the four sub-tasks in task [4] you are describing exactly what
you want. And that is programming.
The rest of the main tasks can also be broken up and given more detail, but this is just a
small demonstration of a balloon being shot at. There is not even the code handling when
the player actually hits the balloon. This approach does not change no matter how big the
game is. You start with large manageable tasks that you want the computer do run, and you
cut them up and divide them until each action is known.
As techniques go, this is the one you'll need first. You have a game idea, and you even
know what the various parts of the game will look like. By turning these game tasks into
something the computer can understand involves many more decisions, and you'll be facing
some brick walls on the way.
One of the pitfalls for amateur game writers is simply not knowing what the computer can
and cannot do, and such knowledge can only come from experience. Something as basic as
moving a balloon up a screen is child-easy for some, but a genuine problem for others.
These are not jibes against your intelligence or natural talent, they are problems. Even
the most experienced programmer encounters problems everyday when coding. They are to be
met with vigour and determination. Treat them as one more challenge to out-fox. Solving a
problem is a joyous and vitalising sensation, and there is nothing quite like it.
Back
To Top
|
