Developing KNP Code

Hill Billy

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

VISIT AN AREA IN OzEdweb

Technophile.City    The.Time.Machine     The.Tree.House    Lessons.Index      Assessment.Instruments     Maps     Power.Point     Proforma     Links     Gallery     Games     Humour      Prizes     WebRings     Soapbox     Search.Engines     Site.Map

.

             Search OzEdweb By Keyword   

.CLICK ME TO VIEW FRAMES ALL RIGHTS RESERVED  OZEDWEB--VIRTUAL OZ  HOME..