Kid's Programming Language (KPL) is carefully designed to make it easy for beginners to learn to program, but all the things that make KPL easy for beginners also make it easy for anyone who wants to code fun stuff fast. Missile Command is our loudest, most colorful, and most complex retro KPL example — and if you really need proof that KPL is a lot more than just a beginner language, playing this game will do it. Missile Command was coded in KPL by Larry Serflaten, a KPL MVP who has contributed a dozen open source games or programs to the community.

Here are some fun historical links about Missile Command, which Atari released in 1980:

http://www.klov.com/game_detail.php?letter=M&game_id=8715

http://www.atariprotos.com/2600/software/missilecommand/missilecommand.htm

The Wikipedia link describes how a legendary high-score run of over six hours ended when the three players got bored and went to the pub! It also mentions that the chip running the 1980 game had a clock speed of 1 MHz — some of us are running chips with a clock speed over 3000 times as fast now! That's 12 doubles of clock speed in 26 years, which ironically is a little slow in Moore's Law terms.

Just the Interesting Stuff, Please

This article will assume some programming skill, and rather than explaining every line of code in the KPL program, will focus on key techniques or algorithms which will be useful as you develop your own games:

• User-defined structures
• Mouse handling
• Proximity functions
• Implementing smart AI
• Cool end-of-round experience

I will also not repeat topics covered in previous Coding4Fun articles, so if this is the first you have read about KPL and you'd like to catch up on them, they were published in this order:

This Missile Command article will make the most sense if you have installed KPL version 1.1, which includes MissileCommand.KPL in the Games folder. The ideal way to start, of course, is to load MissileCommand.kpl in the KPL IDE, click "Run the program," and play it a few times before examining the code. Prepare to be impressed!

KPL 1.1 is available as a freeware download from http://www.k-p-l.org/download.htm. KPL does have a dependency on the .NET Framework 1.1, and the KPL install will automagically download and install the Framework if it is not already installed on your machine. If you already have KPL installed and Missile Command is not in your games folder, this indicates you don't have the latest version of KPL. For Missile Command and other reasons, it's good to upgrade to 1.1.

User-Defined Structures

MissileCommand.kpl uses user-defined structures in a couple of ways. We'll use the http://en.wikipedia.org/wiki/OnomatopoeiaKaboom structure as our example:

Structure Kaboom
    Size As Decimal        // Current blast size
    Tick As Int            // Start time
    Busy As Bool        // Still exploding
    X As Int
    Y As Int
End Structure

In the code below, from method DoExplosions(), xpl is an instance of the Kaboom structure, and used to represent and animate an explosion. This code, processed in a polling loop as it is, causes the explosion to expand outward, and then collapse in size as it fades. As you can see, there's nothing unusual about referencing a structure or the fields within it:

MoveTo(xpl.X, xpl.Y)
// Calculate size based on time from detonation
xpl.Size = Sin((Clock - xpl.tick) / 400.0) * kBlastSize
            
// Draw sky (to erase explosion)
If Clock - xpl.Tick > 550 Then
    siz = Sin((Clock - xpl.Tick - 120) / 400.0) * kBlastSize
    Color(ColorScheme[kSky])
    Circle(siz, True)
    xpl.tick = xpl.Tick + 25
End If

// Draw explosion
If Clock - xpl.Tick <  1200 Then
    Color(BlastColors[Flash])
    Circle(xpl.Size , True)
End If
            
// Stop
If Clock - xpl.Tick > 1300 Then
    xpl.Busy = False
End If

Mouse Handling

KPL 1 does support a simple event model for mouse handling:

// MOUSE INPUT
Method MouseInput(Event As String, X As Int, Y As Int, Button As Int )
    If Event = "ButtonDown" Then
        If Y > kOriginY And Y < (kTargetY - (kBlastSize / 2)) Then
            ShotX = X
            ShotY = Y
        Else
            AddSound(8, 200, "PowerDown.wav")
End If
    End If
End Method

Method MouseLock(Event As String, X As Int, Y As Int, Button As Int )
    // Used to refuse mouse input during scoring phase 
End Method

In Method PlayLevel(), these mouse event handlers are alternately set to enable and disable processing of the mouse clicks:

SetMouseEvent("MouseInput")


. . .




// Mouse input locked out for score tally
SetMouseEvent("MouseLock")

Proximity Functions

Proximity testing is an important enough technique that we thought we'd make an example of it here, particularly since this demonstrates a few other points worth noting in KPL:

Function NearExplosion(X As Int, Y As Int) As Bool
Var rsl As Bool
Var idx As Int
Var len As Int = ArrayLength(Blast)
Var dx As Decimal
Var dy As Decimal
Var hyp As Decimal

    // Returns True if X, Y is near any explosion
    For idx = 1 To len
        If Blast[idx].Busy Then
            dx = Blast[idx].X - X
            dy = Blast[idx].Y - Y
            hyp = Sqrt(dx * dx + dy * dy) * 2
            rsl = rsl Or (hyp < Blast[idx].size)
        End If
    Next
    Return rsl
End Function

First and most obvious is that proper functions are supported and useful in KPL in the usual way, as a method that returns a value. In this case we return a simple Boolean value of whether or not the (X,Y) location is within the blast radius of any of the explosions that are currently happening on the screen.

Note the use of ArrayLength(), itself a KPL system function which returns an integer value indicating the length of the specified array.

The line below does a classic hypotenuse calculation to get the distance between the (X,Y) point and each explosion. Remember a² + b² = c²?

hyp = Sqrt(dx * dx + dy * dy) * 2

Sqrt() is another KPL system function, of course, for calculating the square root of a specified value. The * 2 added to the equation allows the hypotenuse distance calculation (a radius measurement) to be compared correctly against the blast size (a diameter measurement). We could have used (hyp < (Blast[idx].size/2)) on the second line instead.

Implementing Smart AI

Here's a cool quote (and cool challenge!) from the original Missile Command developers:

"These little diamond-shape guys can evade your explosions. The only way you can kill them is if the explosion starts out right on top of them. Programming that was the hardest part. They had to be intelligent because the little guy had to look around on the screen to see what he had to avoid and he had to figure out the best path to go around what there was to avoid. Of course, if I made it too smart, then the player couldn't kill it and they'd be guaranteed instant death. So it had to be a fine line between smarter than the dumb missiles, yet not totally unkillable."

John McCarthy coined the term "artificial intelligence" at a 1956 conference, the first ever devoted to the topic of machine intelligence. It's obviously a stretch to have one term span from our KPL code for incoming drones all the way to Deep Blue, the IBM computer that beat a chess grand master. We'll stick to our guns, though, while acknowledging that some games require a lot more artificial intelligence than others!

Working on game AI is, for many programmers, one of the most fun challenges in game development: figuring out an algorithm that can reliably crush a human opponent. Muah ha ha! As the quote points out, though, it's also a critically important game design point not to overdo it if you actually want people to play your game! Proof of the point is how Gary Kasparov avoided a rematch after Deep Blue kicked his butt! Moral of the story: your game AI will require testing and adjustment — and you'll always want to aim for a playable point that's hard enough but not too hard.

The AI in Missile Command directs the "drones," the small triangles which will intelligently pick and move toward the nearest live target, avoiding nuclear blasts that are in their path. The methods PickNearestTarget() and MoveAwayFromBlast() are unsubtle mathematical algorithms with descriptive names (good programming practice, that), so the one we will instead examine is MoveTowardTarget():

Method MoveTowardTarget(Drone As Ordinance)
Var trg As Int
Var mov As Decimal[3] = {-1.0 * kDroneSpeed * Speed, 0.0, 1.0 * 
  kDroneSpeed * Speed}

    trg = kTargetsX[Drone.Index]
    Drone.DY = Speed * kDroneSpeed
    
    // Screen boundries
    If (Drone.PX < 3) Then
        Drone.DX = mov[3]
    End If
    If (Drone.PX > 697) Then
        Drone.DX = mov[1]
    End If
    
    // Very occasional directional change
    If Random(1, 50) = 21 Then 
        Drone.DX = mov[Random(1, 3)]
    End If
    
    // Occasional direction change toward target
    If (Random(1, 10) = 7) Or (Drone.PY > 380) Then     
        If Drone.PX > (trg + 5) Then
            Drone.DX = mov[1]
        End If
        If Drone.PX < (trg - 5) Then
            Drone.DX = mov[3]
        End If
    End If
End Method

Note how the unpredictability in the algorithm is based on x-axis movement, which can be a little to the left, no movement along that axis, or a little to the right. When the Drone has proceeded far enough down the screen to get close to its target — (Drone.PY > 380) — it will begin to move more directly toward the target. Until then, based on two uses of Random(), the movement of the drone will have a considerable random element. Experimenting with those uses of Random() specifically, and more broadly with this algorithm, will give you a sense of the playability impact of very subtle algorithmic changes. Keep that original quote in mind from the Missile Command developers 26 years ago: "It had to be a fine line between smarter than the dumb missiles, yet not totally unkillable."

End-of-round Scoring

Missile Command was actually the first arcade game ever to use an end-of-round pause for scoring. If you have good speakers on your computer when you play it, you'll see that the KPL version does a loud and impactful recreation of the original end-of-round. Turn it up!

Consider the usefulness of the short break provided by an end-of-round experience. You give the player a short breather and you extend the length of time they play the game, while you keep their attention and interest. Heck, if you do that with as much impact and volume as Missile Command does, you are giving them a minor adrenalin jolt even while they're getting a break. End-of-round scoring isn't appropriate for all games, but it is for many.

Below is the TallyScore() method in MissileCommand.kpl. It's ideal to print this out and consider the code alongside the screen as the end-of-round is being processed. SetFont() is worth noting, as is AddSound(), which is a user-defined method we will also show below:

Function TallyScore() As Bool
Var s As Int 
Var x As Int
Var more As Int 
Var scr As Int 

    SetFont("Arial", 18, True, False, False)
    Pen(False)
    
    // Tally missiles
    x = 200
    For s = 1 To 3
        While Silo[s] > 0
            Silo[s] = Silo[s] - 1
            Score = Score + (Bonus * 5)
            scr = scr + (Bonus * 5)
            DrawSilo(s)
            DrawMissile(x, 160, True)
            DrawScore(True)
            ScreenPrint(150, 150, scr)
            AddSound(10, 0, "mortar1.wav")
            RefreshScreen()
            Delay(80)
            x = x + 12
        End While
    Next

    // Tally cities
    x = 215
    LiveTargets[5] = False
    scr = 0
    For s = 2 To 8
        If LiveTargets[s] Then
            more = more + 1
            scr = scr + (100 * Bonus)
            Score = Score + (100 * Bonus)
            EraseCity(s)
            DrawCity(x, 205)
            DrawScore(True)
            ScreenPrint(150, 200, scr)
            AddSound(10, 0, "mortar2.wav")
            RefreshScreen()
            Delay(300)
            x = x + 60
        End If
    Next
    
    // Add bonus cities
    scr = 0
    LiveTargets[5] = True
    While (City <= Score) And (more < 6)
    
        x = Random(2, 8)
        While LiveTargets[x] = True
            x = Random(2, 8)
        End While
        scr = scr + 1
        more = more + 1
        City = City + kCityBonusTrigger
        LiveTargets[x] = True
        EraseCity(x)
        DrawCity(kTargetsX[x], 436)
    End While
    
    // Print ADDED message
    If scr > 0 Then
        AddSound(10, 1, "MessageBeep.wav")
        Color(ColorScheme[kMissile])
        If scr = 1 Then
            MoveTo(265, 300)
            Print(scr + " CITY ADDED")
        Else
            MoveTo(250, 300)
            Print(scr + " CITIES ADDED")
        End If
    End If
    
    // Let player see it a while
    Delay(2000)

    Return (more = 0)
End Function

AddSound() is a method worth noting because it is easily reusable for other games. It allows sounds to be prioritized as they are played, and it allows sounds to be played for a specific duration before they are replaced with another sound:

Method AddSound(Layer As Int, Duration As Int, File As String)
// Plays sound based on priority, and lets them last for some duration
    If (Layer >= Priority) Or (Clock > Hold) Then
        PlaySound(File)
        Priority = Layer
        If Duration > 0 Then 
            Hold = Clock + Duration
        Else
            Hold = -1
        End If
    End If
End Method

What's next?

You know by now I like teasers, right? How does 35 KPL-simple instructions sound, to fly a 3D spaceship model through an interstellar skyscape? KPL version 2, which is now in beta, lets you do exactly that, and a whole lot more. Check it out:

And the code:

SwitchTo3D()
        
Define cam As Camera
Define frameTime As Decimal = 0.0
        
Define sky As Skybox3D
sky.LoadMesh( "cell.x" )
sky.Scale( 5, 5, 5 )
        
Define ship As Model3D
ship.LoadMesh( "Fighter.x" )
ship.MoveTo( 10, 10, 10 )
        
While Not IsKeyDown( Escape )
        
    Define startTime As Decimal = TickCount()
    Define moveAmount As Decimal = 5 * frameTime
            
    If IsKeyDown( Left ) Then
        ship.TurnLeft( moveAmount )
    End If
            
    If IsKeyDown( Right ) Then
        ship.TurnRight( moveAmount )
    End If
            
    If IsKeyDown( Up ) Then
        Ship.TiltUP( moveAmount )
    End If
            
    If IsKeyDown( Down ) Then
        Ship.TiltDown( moveAmount )
    End If
            
    Ship.Forward( MoveAmount * 5 )
            
    cam.PointAtModel( Ship )
            
    RenderFrame()
            
frameTime = Math.Min( 0.01, (TickCount()-startTime)*0.001 )

End While

How's that for Coding4Fun? If you would like to know about our future plans for KPL, send e-mail to mailto:%20jon@kidsprogramminglanguage.com. Thanks to Coding4Fun for this chance to publish a fun series! And thanks to all of you for reading, blogging, and spreading the word!

Have you seen the previous articles here at Coding4Fun about KPL, the Kid's Programming Language? The overview is here, and the article on KPL Pong is here. KPL is not just for kids; it's for anyone who wants to code fun stuff fast. Proving the point, this is the second of a series in which we are recreating classic video games in KPL code—in this article, Asteroids! Asteroids is a big step up from our Pong example—a lot more code here. Next in the series, by the way? Missile Command—just like the old days!

(Click image to zoom)

Here are some fun historical links about Asteroids, which Atari released in 1979:

http://en.wikipedia.org/wiki/Asteroids

http://www.klov.com/game_detail.php?letter=A&game_id=6939

http://www.oilzine.com/features/features_details.asp?ID=49

KLOV.com is, of course, the Killer List of Videogames. Check out this historical highlight from the Wiki:

"In March 2004, Portland, Oregon resident Bill Carlton attempted to break the world record for playing an arcade version of Asteroids, playing over 27 hours before his machine malfunctioned, ending his record run. He scored 12.7 million points, putting him in 5th place in the all-time Asteroids rankings. In November 1982 Scott Safran set the still unbroken record of 41 million points."

Oilzine's article entertainingly describes how, in 1961, MIT's Tech Model Railroad Club got their hands on a DEC PDP-1 "minicomputer"—famously small because it was only the size of a large car! —and used it to invent Space War, the first precursor to Asteroids. One of them also invented the first joystick just so they could play this game! Talk about Coding4Fun!

Besides Asteroids, Atari also released Basic Programming in 1979—a fun predecessor to KPL. On the one hand, this description of graphical programming support back then makes KPL look pretty good:

"Graphics" - contains two colored squares that can be manipulated by your program.

On the other hand, this makes one think: we could program Atari consoles in 1979?! 27 years later, and now no one can program their consoles? Run my own KPL games on my Xbox or Xbox 360 or PS2 or PSP or Nintendo? And in February, when KPL v 2 lets me do easy 3D game programming, and use game controllers? I guess if we can't program our consoles now, it's because no one really wanted to do that, right?

Sorry, back to Asteroids now. Asteroids.kpl is a lot larger than Pong was, with over 1000 lines in the KPL file, but many of those are white space or comments. As with all KPL games and programs, it's open source, and available for download

Just the interesting stuff, please

This article will assume some basic programming skill, and rather than explaining every line of code in the KPL program, will focus on key techniques or algorithms which will be useful as you develop your own KPL games:

• Creating new animated sprites
  
  
• "Stamping" a starfield as a background
  
  
• Calculating directional vectors
  
  
• Adjusting game speed based on frame rate
  
  
• Finding a safe hyperjump spot
  
  
• Controlling game playability

I will also not repeat topics covered in previous articles, so if this is the first you have read about KPL and would like to catch up on them, they were published in this order:

Kid's Programming Language

Kid's Programming Language: Pong!

Kid's Programming Language: Christmas Tree Shooter

This Asteroids article will make the most sense if you have installed KPL, and downloaded and unzipped the Asteroids program underneath your KPL install folder. The ideal way to start, of course, is to load Asteroids.kpl in the KPL IDE, click "Run the program," and play it a few times before examining the code.

KPL itself and Asteroids.kpl are available as freeware downloads from: http://www.kidsprogramminglanguage.com/download.htm. KPL does have a dependency on the .NET Framework 1.1, and the KPL install will "automagically" download and install the Framework if it is not already installed on your machine.

Creating New Animated Sprites

Graphical sprites are easily animated in KPL by using animated GIF files. An animated GIF is a GIF file with multiple "frames" in it, plus supporting data about whether to loop the animation, and how long to display each frame before switching to the next. KPL allows programmatic control of those behaviors, giving you a lot more flexibility than "hard-coding" this in the image file, but for a GIF which you want to animate for use on a web page, for instance, you need that control to be explicitly included in the GIF itself.

There are various shareware and freeware animated GIF editors available, so I won't recommend just one. The basic process is the same for each: when you create a new animated GIF, you add "frames" to it, and you load in the image file to use for each frame. You also tell it how long to display each frame. The animated image we used for Asteroids was of the ship itself—we wanted to give it a minor "pulsing" effect to help it stand out better against the classic Asteroids black-and-white screen. Here are each of the frames used, as well as the final animated GIF. We started with the image used for Frame 1 as the base image, and used MSPaint.EXE to modify it slightly to create the images for Frames 2 and 4. Frame 3 is the same image as Frame 1.

Frame 1	Frame 2	Frame 3	Frame 4	Animated GIF

Here's the KPL code which loads and controls the timing of the pulsing ship image:

    LoadSprite( "Ship", "AnimatedShip.gif" )
        
    Define Timeline As Int[4]
    Timeline[1] = 100 // 100 milliseconds is 1/10 of a second
    Timeline[2] = 100
    Timeline[3] = 100
    Timeline[4] = 100
        
    // Tell KPL to automate it for us, using the timeline 
    // we created above. True tells KPL to loop the animation.
    SetSpriteAnimationTimeline( "Ship", True, Timeline )

"Stamping" a Starfield as a Game Background

Lots of games are set against a starfield, so here's the KPL code from Method DrawStars() that randomly creates and "stamps" a starfield as the background for Asteroids:

    Define I As Int
    Define Scale As Decimal
        
    Clear( Black )
    ClearSprites()

    LoadSprite( "Star", "Star.gif" )
    ShowSprite( "Star" )
        
    For I = 1 To (ScreenWidth()/4)
        MoveSpriteToPoint( "Star", Random( 1, ScreenWidth()), Random( 1, ScreenHeight()) )
        Scale = Random( 1, 100 )
        Scale = Scale / 100.0 - 0.1
        ScaleSprite( "Star", Scale )
        StampSprite( "Star" )
    Next
        
    UnloadSprite( "Star" )

The code randomly moves the sprite "Star" around the screen, randomly resizing it each time using ScaleSprite(). At each location, it uses StampSprite() to make it a permanent part of the screen background. This is much more efficient than actually creating and maintaining 500 separate Star sprites, and enables KPL to redraw the background automatically as well.

Note the use of ScreenHeight() and ScreenWidth(). Since this game is best played "Maximized," ScreenHeight() and ScreenWidth() are system functions used throughout the program to make the display match the user's screen resolution. In this example, we even adjust the number of stars displayed based on the user's ScreenWidth(), so the starfield density is similar across all screen resolutions.

Calculating Directional Vectors

Directional vectors are the basis for nearly all aspects of Asteroids gameplay, including the movement of the asteroids, the movement of the ship, and the path of fired missiles. A directional vector is easily represented as the combination of some amount of movement along the x axis and some amount of movement along the y axis—and so the Point structure is a good way to record and work with Vector data:

    Structure Point
        X As Decimal 
        Y As Decimal
    End Structure
    ...
    Define piOver180 As Decimal = (3.14159 / 180.0)
    ...
    Function CalculateVector( Heading As Decimal ) As Point
    
        Define Result As Point

        Heading = (Heading - 90)
    
        Define theta As Decimal = (Heading * piOver180) * -1
        Result.X = Cos( theta )
        Result.Y = Sin( theta ) * -1
        
        Return Result

    End Function 

This is getting into interesting trigonometry, because we must in order to handle directional vectors. piOver180 is a pre-calculated constant that defines "radians per degree." The Heading is in degrees, but the Cos() and Sin() functions take radians as a parameter, so (Heading * piOver180) converts the Heading from degrees to radians for those calls.

Since the "forward" direction of our ship and missile sprites is actually straight up, we subtract 90 from our heading before we perform the vector calculation. And since computer coordinates' y axis increases downward instead of upward, we also multiply by -1.

Adjusting Game Speed Based on Frame Rate

The range in the performance characteristics of computers capable of running KPL is pretty amazing: from eight-year-old machines with no graphics accelerator running Windows 98 to brand-new gaming-optimized 64-bit machines. Moore's Law suggests that some computers running KPL will literally have fifty times as much performance as others. It's critical to accommodate a machine's performance characteristics in any game, or else the range of computers capable of playing it will be greatly limited, and the game will quickly become unplayable as new, faster computers become available.

Asteroids.kpl keeps track of a "frame time" and uses it to adjust the game speed as needed. This declaration at the top of the file defines the variable used for this adjustment:

    // Tracks the amount of time it took to draw the last frame, 
    // which is used in calculating how much to move every sprite
    // during each pass through the main game loop.
    Define secondsPerFrame As Decimal = 0.0

Code in the main program loop in Method Main() constantly recalculates this value:

    // Keep track of frame count and frame start time for animation
    // calculations
    startTime = TickCount()
    BeginFrame()
      
    ...

    // Keep track of the amount of time it took to draw this frame,
    // as this value is used to determine the amount of movement for
    // the various animation calculations.
    endTime = TickCount()
    secondsPerFrame = (endTime - startTime) * 0.001

And here is the function that is used to adjust movement distance based on the secondsPerFrame value. Note that the return value from Min( 85, AmountPerSecond * secondsPerFrame ) can never be more than 85, so that even on slow computers it is the maximum distance moved in pixels. This can result in choppy rather than smooth movement, but at least allows the game to be played:

    // AdjustForFrameRate allows the game objects to move at roughly 
    // the same speed on computers of any speed, although on slower 
    // computers which take longer to draw individual frames the 
    // amount of movement per frame will be higher, and the 
    // animations will be a little choppier. This is why on very 
    // slow computers it may look like the animation is "dropping 
    // frames", since the ship moves in bigger increments to     
    // compensate for the slow frame rate.
    Function AdjustForFrameRate( AmountPerSecond As Decimal ) As Decimal
        Return Min( 85, AmountPerSecond * secondsPerFrame )
    End Function

Finding a Safe Hyperjump Spot in Real Time

The Hyperjump button, "H", will instantly engage the Hyperjump computer, popping your ship momentarily out of spacetime while it computes a safe location to return to spacetime—and saving your butt from that incoming asteroid! When you, the human ship captain, fail to engage Hyperjump quickly enough to save your ship, the Hyperjump computer takes over for you, instantly engaging and saving the ship. Each time this happens, the ship and shields take a beating, though. More than a few times and you and your ship aren't going to make the jump in time, and the two of you will be a yucky splat on the windshield of some nameless asteroid spinning silently along its monotonous path through the cold vastness of space. Grim! That Hyperjump spot algorithm better be a good one!

The challenge for this one is implementing an algorithm that can do this in real-time, given that dozens of asteroids and dozens of fragments can be spinning and moving across nearby space. Not an easy problem. This is a great example of the difference between the way human brains work and computer brains work. It's fairly instantaneous to any of us when we look at an Asteroid field where the largest open space—and therefore the safest spot—is located. Computers can't do that nearly as easily as we can.

The first algorithm I thought about, with the priority being that I needed something to work in real time, was as follows: quickly calculate, for every asteroid displayed, how far it is from all other asteroids. Whichever asteroid is farthest from all other asteroids, hyperjump the ship to just "behind" that asteroid, based on the asteroid's trajectory. This was a pretty cool solution, and did indeed work in real time; but it ended up being much more complex code, and having some quirks that made me go with this simpler approach:

Method JumpToSafeSpot()
    
    Define Safe As Bool = False
    Define I As Int
    Define Distance As Decimal
        
    While Not Safe
            
        // Pick a random screen location, not too close to the edge
        Ship.X = Random(100,ScreenWidth() - 100)
        Ship.Y = Random(75,ScreenHeight() - 75)

        // Update the status bar message to show why time (might) 
        // be stopped
            Status("Timespace escape! Hyperjump computer seeking safe jump coordinates!")
            
            Safe = True
            I = 1
            // While the spot is still safe and we haven't 
            // checked all asteroids
            While Safe And I <= MaxAsteroids
                // Calculate the distance from this asteroid. 
                // The + 40 uses the centerpoint of the 
                // asteroid for the calculation. Note there is
                // no SQUARE() function or ^2 operator in 
                // KPL v 1 - there will be in KPL v 2 – so we
                // just multiply
                Distance = Sqrt(((Asteroids[I].X + 40 - Ship.X) * (Asteroids[I].X + 40 - Ship.X)) + ((Asteroids[I].Y + 40 - Ship.Y) * (Asteroids[I].Y + 40 - 

Ship.Y)))
                // If it's closer than 200 pixels, this is not 
                // a safe spot
                If Distance < 200 Then
                    Safe = False
                End If
                // Increment I to check the next Asteroid
                I = I + 1
                // If the spot still seems safe, we'll 
// check the next asteroid
            End While
            // Clear the status indicator - if we then try 
            // another spot, this will cause a "blink" effect so 
            // you, the ship captain, on hold outside of 
            // normal spacetime, know the hyperjump computer 
            // is still working on the problem...
            Status("")
        End While
        
        // We will not exit this method until the ship has been 
        // placed at a safe location. My testing shows this is
        // rarely more than a blink, but since this is based on
        // Random(), and since the screen can get crowded, it can
        // take a second or more. This is not ideal, but it is 
        // simple - and the "escape from timespace into a 
        // hyperjump" story is a pretty good rationalization! :D
    End Method

Controlling game playability

Playability obviously ought to be the point of any game. The more playable a game is, the more fun people have with it, the more times they play it, the more they tell the friends about it, the more magazines and websites tell people about it, the more famous you become as a game developer, the more money you make, the more bizarre obsessions and personality quirks you can indulge in, etc., etc. I'm not thinking of any specific examples when I say that.

These are some of the reasons why it's important to consider playability from the beginning, and to implement playability controls as "parameters" in the program so they can be easily adjusted by the programmer to make the game as playable as possible. The other advantage of doing this, as discussed in previous articles, is that parameters that are tweakable make it easy for players to adjust gameplay themselves—if they have access to code, as they do with KPL programs. Some people like games faster, some slower. And since they'll be doing that in KPL code, they'll be polishing some programming skills along the way.

Asteroids.KPL does this with numerous gameplay parameters. Changing these values can pretty drastically change the way the game plays:

    Define MaxHyperJumps As Int = 3 // initial jumps, you get more

      // jumps as a bonus, see below
    Define ShipLives As Int = 3 // initial ships,  you get more ships
        // as a bonus, see below

    // Asteroid Settings
    Define MaxAsteroids As Int = 30 // max number of asteroids on the 
      // screen at once
    Define AsteroidLoadSpeed As Int = 500 // wait time in 
      // milliseconds for each set of 
      // asteroids to be sent
    Define MaxAsteroidSpeed As Int = 10 // Max Start speed on 
      // asteroids
    Define AsteroidLoadSpeedBonusUpdate As Int = 20 // when a bonus 
      // is made the game sends more 
      // asteroids faster
    Define MaxAsteroidSpeedBonusUpdate As Int = 1 // when a bonus is
      // made the game speeds up some 
      // of the asteroids
    
    // Asteroid Fragment Settings
    Define MaxAsteroidFrags As Int = 20
    Define MinAsteroidFragmentsPerHit As Int = 1
    Define MaxAsteroidFragmentsPerHit As Int = 5
    Define MaxAsteroidFragSpeed As Int = 10
    
    // Score Keeping
    Define AsteroidsToEndOfGame As Int = 500 // if you hit this many 
      // Asteroids the game will end 
      // even if you have ships left
    Define LargeAsteroidHitScore As Int = 500 // number of point for
      // each asteroid hit
    Define SmallAsteroidHitScore As Int = 250 // number of point for 
      // each Asteroid Fragment hit
    Define NewShipBonus As Int = 10000 // you get 1 new ship and 1 
      // hyperjump for every 
      // NewShipBonus points

Most of these are pretty obvious, but I want to mention one in particular, because of its importance to controlling the "pace" of the game. People have different preferences about game pace, but in general, a game should start a little slow and easy, and steadily become faster and/or more difficult over time. If that increase happens slowly enough, the user doesn't consciously notice it, but they certainly do get caught up by it and drawn into it. Done right, they're leaning back all comfortable and lazy at the start, and by the end of the game they're leaning forward in their chair and banging on the keyboard! Pace also, of course, determines how long a game actually lasts—the faster it gets, the harder it gets, the sooner it will end. One specific parameter which I would encourage you to play with in order to see playability difference based on pace is MaxAsteroidSpeedBonusUpdate. The starting value of 1 cause some asteroid speeds to increase at a 1 pixel per move each time a bonus ship is awarded. This ends up making the game last a fairly long time, and only very incrementally increases the pace of the game. Try setting that value to 5, running the game again, and seeing how much difference it makes!

What's next?

Your mission, should you choose to accept it, is twofold.

First, the UFO:

This sneaky, evil, small and tough-to-shoot alien spaceship was an unpredictable, difficult, and big-bonus-point part of the original asteroids—assuming you managed to kill him before he killed you, of course—and we have not yet put it into this KPL version of Asteroids. Right-click, Save Image As... will let you drop the UFO image from this page right into the Asteroids folder.

Second, the safe spot:

Can you come up with a really cool real-time algorithm that works better than our JumpToSafeSpot() code?

Should you take on the KPL code for either of these, and send them back to me, we will be most happy to publish your code, give you lots of kudos, and tell people by the thousands how good of a game developer you are, etc. See above for where that could take you. Mail me at jon@kidsprogramminglanguage.com if you come up with code for these—or any other cool KPL code, for that matter!

Moral of the story? Coding4Fun isn't just a name—it's the point!

Ah, a teaser: anyone remember Missile Command? Check it out below. Yes, that's KPL, and yes, the game rocks! Watch for the article here next month!

Welcome to the first article in a series of fun coding projects built using KPL—the Kid's Programming Language! As you'll see, KPL is not just for kids—it's for anyone who wants to code fun stuff fast. This article will present the KPL code that implements the game shown below—Pong! We thought that recreating the first video game ever invented was a good place to begin our series of KPL examples.

Here are some fun historical links about Pong:

http://en.wikipedia.org/wiki/PONG

http://www.pong-story.com/

http://www.oilzine.com/features/features_details.asp?ID=49

The original Pong console launched the video game revolution—with home consoles and arcade machines—and all it did was let you bounce a very pixilated white ball around your black TV screen! At Christmas time in 1975, people lined up outside Sears, waiting to buy one! Contrast that with what you'll bring home when you hunt-and-gather your Xbox 360 next month—a lot has happened in 30 years, eh?

Recreating the game that started it all took, in my version, 180 lines of KPL code, and just a few hours. And ya know what? It's still fun! Oh, if you checked out Oilzine's article above, you know that the other pillar that began the video game industry was Asteroids. Guess what classic video game our next article will recreate?

Just the interesting stuff, please

This article will assume some basic programming skill, and rather than explaining every line of code in the KPL program, will focus on key techniques or algorithms which will be useful as you develop your own KPL games:

• Using Sprites in KPL
  
  
• Preparing and using custom images
  
  
• Handling keyboard input
  
  
• Sprite interaction
  
  
• Details that keep things interesting
  
  
• Implementing a computer opponent

Before we begin, the article will make the most sense if you have installed KPL, and have opened the KPL program Kplong.kpl, which you will find in the KPL Programs > Games folder in KPL's File Explorer. The ideal way to start, of course, is to load Kplong.kpl in the KPL IDE, click "Run the program," and play it a few times before examining the code.

If you are using a version of KPL from before October 10^th, it may not include Kplong.kpl—for Kplong and lots of other cool new content, it's worth installing the latest version. KPL is available as a freeware download from: http://www.kidsprogramminglanguage.com/download.htm. KPL does have a dependency on the .NET Framework 1.1, and the KPL install will automagically download and install the Framework if it is not already installed on your machine.

Using Sprites in KPL

// Left player's paddle
LeftPlayerY = 225 
LoadSprite( "LEFT", "PADDLE.GIF" ) 
MoveSpriteToPoint( "LEFT", 30, LeftPlayerY )
ShowSprite( "LEFT" )

The LoadSprite() system method takes as parameters the name by which you will refer to the sprite (in this case, "LEFT"), and the file name from which to load the image for the sprite.

The MoveSpriteToPoint() system method takes the name of a Sprite, and the X and Y coordinate at which to place the Sprite. (0, 0) is the upper left corner of the window. This call moves the Sprite to the specified location, but does not yet display it.

The call to ShowSprite() actually causes the named Sprite to be displayed.

Other Sprite-manipulating methods used in Kplong.kpl are:

UnloadSprite() takes the name of the sprite which is to be unloaded when it is no longer needed:

UnloadSprite("BALL")

ClearSprites() simply unloads all Sprites at once, effectively clearing the screen:

ClearSprites()

GetSpriteHeight() returns the height in pixels of the named sprite:

GetSpriteHeight("RIGHT")

SpritesIntersect() takes the name of two sprites, and returns true only if they intersect or overlap on the screen:

If SpritesIntersect( "BALL", "LEFT" ) Then

That's all the Sprite code you need to know to implement Pong in KPL. We have designed KPL to be as simple and as highly leveraged as possible, and this is particularly visible in KPL support for Sprites. A KPL game can be implemented in the fraction of the number of lines of code required to implement the game in another language. Hopefully KPL Pong in 180 lines of code proves that point?

Preparing and using custom images

This KPL program uses custom images for the ball, the paddle, and for the digits 0 through 9 as used for scoring. Using digit graphics isn't necessary, but was actually easy to code, and also allows a custom Pong-inspired digital font to be used for scoring.

The graphics used in Kplong were created using Paint, which is available as part of all versions of Windows. You can launch paint from Start Menu > All Programs > Accessories > Paint, or by running mspaint.exe from the Run… dialog.

I won't attempt to teach use of Paint in this article, but I will mention that the View > Zoom > Large Size menu option is extremely useful for allowing pixel-level manipulation of an image. The Windows help available within Paint is excellent and very detailed. Any other programs which can produce an image file are also usable, of course.

KPL currently supports .GIF, .JPG, .TIF, .BMP and .PNG file formats. Kplong does not make use of animated GIFs, but KPL does support their use for animating Sprites.

KPL will automatically find an image by file name if the image is in the Media \ Images folder under the KPL install. If you expect to use an image from more than one KPL program, this is the right place to put it. If an image is specific to the program you are working on, you can leave the image in the same folder as the .kpl program itself. KPL will find it in the local folder, looking there first before checking the Images folder.

Handling keyboard input

A simple model for coding a game in KPL is a large loop which, at a controlled interval, processes user input and game events. Here is Kplong's Method Main() which shows how this loop is the basis of the processing for this KPL program:

Method Main()
    Define CurrentTime As Decimal 
    Define TimeLastChecked As Decimal
    SetUpGameScreen()
Alert("Left player uses W and Z keys, Right player uses Up and 
Down arrows.", "Get ready!")
        
    ServeTheBall()
    While GameOver = False
        
        CurrentTime = TickCount()    
        
        // If 25 milliseconds have not passed since the last 
        // time we checked, we don't do anything yet.
        If CurrentTime - TimeLastChecked > 25 Then
            // Every 25 milliseconds (that's 40 times a 
            // second!) we fall into this block. First
            // we process Key events to move the paddles
            ProcessKeyEvents()
            // Then we MoveTheBall. During the Move, we 
            // also know whether anyone scored a point, and
            // if they scored their 10th point, the game is
            // over!
            MoveTheBall()
                
            // We reset the timer each time, so that we 
            // wait another 25 milliseconds before moving
            // again.
            TimeLastChecked = CurrentTime
        End If
            
    End While
        
    ShowWinner()
    
End Method

The actual processing of key events is done in the ProcessKeyEvents() method, using the IsKeyDown() function:

// Up arrow key moves right player paddle upward
If IsKeyDown("Up") And RightPlayerY > 1 Then 
    RightPlayerY = RightPlayerY - 10    
End If

The key processing code checks for all keys that are relevant to paddle movement, and will handle any and all of them that are down. It also uses logic as shown above so that keys which would cause paddles to move above or below the viewable screen are ignored.

Sprite interaction

The whole point of Pong, of course, is smacking the bouncing ball back and forth with your paddles. Technically, this is a matter of watching for the ball and paddle sprites to "intersect," and when they do, react by bouncing the ball off of the paddle. As with everything else, KPL makes this ridiculously easy to do—6 lines of KPL code! Here is trimmed code from Method MoveTheBall() which implements this logic:

// If the ball is intersecting either paddle
If SpritesIntersect( "BALL", "LEFT" ) Or SpritesIntersect( "BALL", "RIGHT" ) Then
    PlaySound( "Bounce.wav" )
    // Since we're processing a paddle hit, the ball bounces by 
    // changing direction along the X axis
    MoveX = MoveX * -1 
    // Since this was a bounce, we should go ahead and move the 
    // ball to its new bounced location, heading back the other 
    // way. This is actually important to keep the ball from 
    // getting "stuck" in the paddle. Try removing or commenting
    // out these two lines and play a few rounds until you see 
    // the "intercept bounce bug" that will happen without it:
    BallX = BallX + MoveX 
    BallY = BallY + MoveY 
    MoveSpriteToPoint( "BALL", BallX, BallY )
End If

Details that keep things interesting

There are two bits of Kplong logic worth explaining, and worth tinkering with if you are interested. First, the game uses a bit of random "English" to adjust the trajectory of the ball on each bounce. Here's the single line of code that accomplishes this, from Method MoveTheBall():

// We add -1, 0 or 1 to the move along the Y axis, to keep things 
// interesting
MoveY = MoveY - 1 + Random(0, 2)

The trajectory of the ball is a combination of its move along the X axis, and its move along the Y axis. The code above tweaks the Y axis move, and in doing so makes the game at least a little unpredictable. Note that the Random() function does what you would expect—it returns a random value from 0 to 2, inclusive. You can change the parameters on this Random() call to make the English stronger and the game more unpredictable.

You could even program this logic to make the English on the bounce be based upon the movement of the paddle at the time the ball was struck—which would of course be more realistic, and would add a higher level of user control to playing the game, just as English does in real ping pong.

Another important reason to use this line of code is to avoid the "horizontal bounce bug." Consider what would happen if two paddles positioned opposite each other managed to begin a volley with the MoveY equal to 0—the ball would simply bounce back and forth between them and never alter its course. This line of code prevents that from occurring.

A second important bit of logic that keeps things interesting is that Kplong keeps tracks of "volleys" back and forth, and steadily increases the speed of the bouncing ball as volleys progress. KPL gets very interesting as the ball speeds up—and of course this also prevents rounds from lasting a long and boring amount of time. When you play the game, note how engaging and intense this kind of progression is for you as a player—this is a good and a simple technique to keep in mind for other games you develop. The trimmed code which implements this, also in Method MoveTheBall(), is:

// Increment the volley counter
VolleyCount = VolleyCount + 1 
// If it's not the first bounce and the ball is moving to the right
If VolleyCount > 1 And MoveX > 0 Then 
    // Clear the VolleyCount to start counting again
    VolleyCount = 0 
    // And increment the speed of the ball in the X direction 
    // to speed it up. This steadily increases the speed to keep 
    // rounds from lasting too long.
    MoveX = MoveX + 1 
End If

You can, of course, easily tinker with this code by manipulating the If…Then logic, or by changing the MoveX increment to be higher than 1.

Prepare to be humbled by one line of code!

The last fun detail from Kplong that I'd like to show you is how easy a computer opponent can be to implement, for a program like this one. Here's the full logic, from Method MoveTheBall(), that controls your unbeatable computer opponent:

If ComputerPlayer Then 
    LeftPlayerY = BallY - GetSpriteHeight( "Left" ) / 2
End If

That's right, one line of code will kick your butt. Kplong is, by default, a two-player game—but you can engage the computer opponent by pressing and holding the 'C' key until you see the left paddle begin to move on its own initiative.

An unbeatable computer component isn't fun for long, of course—so let's tinker with this code to give us a chance to win. Here's an algorithm which limits how fast the computer player is able to move the paddle toward the ball—just replace the code above with:

If ComputerPlayer Then 
    // The paddle is 50 pixels high, so + 25 attempts to keep the 
    // center of the paddle on the ball.
    If BallY < LeftPlayerY + 25 Then
        LeftPlayerY = LeftPlayerY - 5
    Else
        If BallY > LeftPlayerY + 25 Then
            LeftPlayerY = LeftPlayerY + 5
        End If
    End If
End If

This kind of tinkering with the game code is a great example of how KPL can make gaming more fun, too. It's easy to adjust the skill of the computer player to be a very close match to a player's skill.

What's next?

That's all the Kplong logic I wanted to specifically explain. The full code is there for you in KPL, of course—have fun tinkering with it! Our best hope is that some of you will take this code, modify it in interesting and creative ways, and send it back to us to share with others. Or take some of this logic and apply it to a completely different KPL game! A four-paddle pong version as well as a 3D pong version—yep, 3D—have been written in KPL since this initial Kplong game. Lots of other games have been contributed to the community as well, including Billiards, Yahtzee, Checkers, Simon and some very cool original games. Asteroids, Pinball and lots of others are in the works. Watch for more articles here on Coding4Fun!

Moral of the story? Coding doesn't get more fun than this.