The making of X-NON

    

    Created by Teasy



    Introduction

    What you will find here are ways to create a game,
    helpful methods and techniques to guide your way,
    and examples of organization and implementation
    all leading up to an end-result to your liking.

    Usually, before you create something
    you need to know at least a little bit
    what you're going to create.
    The more you know about the creation process,
    the less obstacles you will find on your way.

    Even if you are not (entirely) familiar with ,
    or if you're just a little smart or a fairly quick learner,
    you won't have any difficulty following this tutorial 

    I've organized this tutorial a bit like an adventure.
    There is an outline of what I want,
    and what I want to achieve is clear,
    but the paths I choose are completely unset and vary wildly
    to make the journey a lot more interesting 



    Knowledge reference

    Here's a list of things that might be useful
    before or after commencing the attack on this tutorial 


     T-C's Blitz tutorials overview

    Language orientation, section guide & overview with links.

            http://www.bettiesart.com/tc/blitz/


     BlitzBasic Full Foundation tutorial

    Includes everything you'd ever want to know about:
    - variables
    - conditions
    - loops
    - collections
    - routines
    - code constructs

            http://www.bettiesart.com/tc/blitz/blitz.html


     Relative positioning in 10 steps

    Geared towards increasing your awareness of relative coordinates.
    Using a unique what-you-see-is-what-it-is tutorial style.

            http://www.bettiesart.com/tc/blitz/relative.html


     Project Z: One

    A simple and short game tutorial especially written
    to give a good example of:
    - 2D-motion (vectors)
    - images created at run-time
    - variable game-flow and control
    - simple random handling
    - variable collection handling
    - simple artificial intelligence
    - score and difficulty handling
    - simple heads-up display
    - simple collision detection
    - keyboard and mouse control

    This game comes in various flavors, but each of them
    is simply a single source code file.

            http://www.bettiesart.com/tc/pz1/


     Vectors and Sine waves

    This is an in-depth tutorial about motion in 2D space,
    and explains the ways of the sine wave as well.
    Also included are various demonstration programs
    such as "Asteroids"-style space physics.

            http://www.bettiesart.com/tc/blitz/vectors.html


     Value conversion tutorial

    In-depth explanation of value offsets and scales,
    which can be applied to countless scenarios.
    This also uses the what-you-see-is-what-it-is tutorial style.

            http://www.bettiesart.com/tc/blitz/conv.html


     Project Z: Two

    An advanced and in-depth game tutorial
    with many cool features, such as:
    - smooth space physics
    - scrolling multi-layered stars
    - simple game menus
    - dynamic heads-up display
    - variable levels and difficulties
    - special rotated rendered images
    - simple sound and channel handling
    - color fading using patterns
    - RGB color handling
    - customized text routines
    - frame limiting
    - intermediate collision detection
    - separated code construction
    - advanced game-flow
    - multi-level control states
    - sequence handling
    - intermediate A.I.
    - embedded media
    - variable game speed
    - advanced timing techniques
    - virtual screen-edge wrapping
    - screen-edge wrap collisions
    - intermediate random handling
    - and various other tricks

    Like Project Z: One, this is a single source code file
    with everything directly included.

            http://www.bettiesart.com/tc/pz2/


     Tilemaps tutorial

    Includes all the basics, support for accurate object motion,
    and a fast, optimized pixel-perfect collision detection algorithm.

    This is yet another single source code file
    with all in-depth explanations embedded,
    so some revealing parts are sneakily hidden inside 

            http://www.bettiesart.com/tc/blitz/tile.html


    You can also use all of the above simply as reference,
    so you can look it up if there's something further on
    in the tutorial that gives you the creeps 

    There's a bunch of files included in the tutorial package,
    such as images, audio and source code files
    to help you try out every step of the way.
    You can also copy and paste the code ofcourse, if you want.

    You can download the tutorial files separately (while reading online)
    for which each linky is provided throughout this tutorial.
    Or you can download all files together with the tutorial itself
    as a single package (for offline reading): The making of X-NON.zip.

    If you want to take a peek at all the files,
    go to the Tutorial files index.

    Or if you want go straight to the game
    that is the final product of this tutorial,
    take a look at the X-NON files index.

    And to look for a specific chapter in this tutorial,
    please refer to the Index.



    Concept

    What I'm creating is a remake of a retro Amiga game called Gravity Force
    which is a 2D split-screen shooter for 2 players.
    Actually I was creating this game just to be able to show it to people
    to find out what the original Amiga game was called.

            

            

    I started by writing down
    everything I knew about the game,
    as detailed as I could.
    Visualizing your ideas for example
    by writing them down or making sketches
    can be a great help!

    To keep at it, I kept trying to remember the feeling
    that lead me to making this game.
    So basically, make it interesting for yourself!

    But keep it simple at first, you can always add more.
    I found it harder to simplify something that is complicated
    than making something simple more advanced.



    Construct

    Games usually have some very distinctive parts
    like various types of media (graphics, sound, music), code
    and other game data (tilemaps, text).

    You can find a lot of a game's elements just by looking
    at the game's description:

        X-NON is a 2-player split screen shooter
        with 2D "Asteroids" physics and gravity.



    Specification

    While I was thinking about the game,
    here's what I wrote down for X-NON on paper:

        Split screen:
,---------------.---------------.
|               |               |
|               |               |
|               |               |
|               |               |
|    Player 1   |   Player 2    |
|               |               |
|               |               |
|               |               |
|               |               |
`---------------^---------------'

        Ships:
                One ship image for each player (red, green)
        Bullet:
                One bullet image
        Tileset:
                Earth ground with variations
                Various earth edges with variations
                Wall to mark starting area
                Vegetation on edges (green)
        Panning:
                Player 1 sound effects left
                Player 2 sound effects right
        Sounds:
Spawn           (loud)
Thrust          (soft)
Fire            (loud)
Bullet collide  (soft)
Explode         (loud)

        Music:
                Game (background) music:
                    A unique track based on the original Gravity Force tune
        Control:
      ,-----,
      | ^   |\
      |     | |                       Fire
      |     | |
,-----+-----+-----,
| <   | v   | >   |\
|     |     |     | |  Rotate Left - Thrust - Rotate Right
|     |     |     | |
t-----t-----t-----< |
 \     \     \     \|
  `-----^-----^-----'

        Input:
                Player 1:
                        W, S, A, D
                Player 2:
                        Up, Down, Left, Right
        Physics:
                2D "Asteroids" physics
                Downward gravity
        Bullet:
                Bullets fly in a straight line
                And disappear after a certain amount of time
        Collisions:
                Legend:
/\   Ship
o    Bullet
[]   Tile

X    Destroy

                Scheme:
/\ + /\ = X
o  + /\ = X
[] + /\ = /\ X
[] + o  = o  X

        Ship collides:
                Spawn small amount of bullets in random directions
                (like an explosion)
                And ship disappears
        Bullet collides:
                Bullet simply disappears
        Game control:
                For each player 2 game states:
                        In wait mode:
                                If player presses Thrust Then play mode
                        In play mode:
                                If player dies Then wait mode
        Background music:
                Played through entire game (looping)
        Sound:
                Shoot bullet sound, when player ship fires bullet
                Thrust ship sound, when player ship thrusts
                Explode ship sound, when player ship collides with tilemap
                Bullet collide sound, when bullet collides with tilemap
                Spawn ship sound, when player ship respawns

    You can make fancy event tables as well (e.g. cause, condition, effect)
    like you also see in easy game creation packages such as Game Maker.
    But I figured that making it more simple would give me results
    even more quickly.

    Use whichever methods and tools available
    to make the creation process easier for yourself.



    Direction

    If you look at the list above (specifications),
    you could make a list of elements you can build into your game,
    just by simplifying the list.

        Graphics:
            Ships
            Bullet
            Tileset
        Sound:
            Sound effects
        Music:
            Background music
        Code:
            Split screen
            Sound panning
            Control/input (ship behavior)
            Gravity (physics)
            Bullet (behavior)
            Collisions (ship, bullet, tilemap)
            Music
            Sound
            Game control

    This can also gives a better outline of the game creation process.
    Now, there are probably some things missing or incomplete,
    but you can always modify this to your own liking,
    like I have done, unnoticeably 

    You can variate the creation process.
    Like creating some simple ships, then implementing them.
    Making some wacky sounds inbetween.
    Make it interesting for yourself.
    I can't stress this enough,
    since I'm used to taking this way too seriously.

    Actually you can do a lot simultaneously,
    but doing too much at once isn't always good.
    If you get some ideas on the way,
    instead of rushing right into creating them,
    write them down for later.
    And you'll have something cool to look forward to as well 
    Like a list with "things to do when I'm bored" 

    Or you can just let any new ideas go
    if you know how to "re-sync" with that same vibe later
    for more new ideas to appear in your mind automagically,
    so you can keep a steady focus on the task at hand.

    So let's start by implementing one element at a time.
    Before implementing something in code you can also test it
    in a separate program, to see how and if it actually works,
    safely, without disturbing the existing code.
    This can also be useful for other things,
    such as sound, graphics, tilemaps, etc.

    I will focus mostly on the code itself.
    The detailed art, sound and music creation process I'll leave up to you,
    or perhaps in another tutorial 
    Besides, there are also other people on this planet
    who can help out in those areas 



    Structure

    There are many ways to organize the code.
    For example, you could organize the code by type of data:

        - Definition
            - Constants
            - Objects (types)
            - Variables
        - Execution (main)
        - Sub Routines (functions)
            - Main

    Instead, I've chosen to sort the game code by section.
    For example placing all player-related code in the Player section.
    It doesn't matter if you're not sure which sections there will be yet.
    It's more important that you know how each section is divided.
    For example:

        - Section
            - Constants
            - Objects (types)
            - Global variables
            - Sub Routines (functions)

    Some sections, like Collisions,
    depend on different sub-sections,
    like for the Tilemap.

    This also means that some definitions,
    which another section depends on,
    have to be defined before being used.

    Though, in Blitz, only arrays have this requirement.
    So you can really mess around if you want to 

    To give an example
    of how I can structure the code in this way,
    here are a few sections:

        (Definition)
        - Player
            - Constants: ship speed
            - Objects: player object
            - Globals: player references
            - Functions: creating a player
        - Tilemap
            - Constants: tile size
            - Globals: tile map (array)
            - Functions: load a tile map

        (Initialization)
        - Main initialization

        (Execution)
        - Main loop

    This structure is actually a simplified version
    of the structure I used in Project Z: Two.

    I will further clarify
    and expand on all of these
    in the upcoming chapters.



    Graphics resolution

    In any scenario, one needs to set a resolution for the game.
    You could use a 3D sprites world, where the actual resolution
    doesn't have to relate to the size of the game objects, pixel-wise.
    But I've chosen to use a 2D pixel world because this was quick and easy.

    As the screen is split, it's better if the screen is wider,
    so there's better overview horizontally and vertically.
    So you can actually see what's coming from all directions equally 

    Gravity Force was actually vertically split,
    having an upper and lower half of the screen for each player.
    This seemed unlogical to me because in most screen resolutions
    the playing area is more square when horizontally split, right?

    Let's take a look at the resolutions one can choose from.
    Heck, you can even find out using a Blitz program.
    Copy the following program, run it (in debug mode),
    and scroll the debug log in Blitz' Debugger to see which resolutions
    are available on your videocard.

Modes = CountGfxModes ()
For Mode = 1 To Modes
    DebugLog GfxModeWidth ( Mode ) + "x" + GfxModeHeight ( Mode ) + "x" + GfxModeDepth ( Mode )
Next
WaitKey
End


    You'll probably see a list of 16 bit and 32 bit resolutions.
    On modern video cards there are special widescreen resolutions,
    some even with a 2:1 ratio, giving a lot of horizontal space
    compared to vertical space.
    Unfortunately there will be videocards which do not support this resolution.
    The ultimate standard resolution is 640x480x16 which is always safe.

    Although Blitz has a technique you can use to detect if a resolution exists
    on a videocard, let's use 640x480 as a starting point.
    From this point I've started testing some tiles, ships and bullets
    to see which sizes look best for this resolution.



    Orientation

    So, having found a resolution to work with, and using a ship placeholder,
    for example a simple filled triangle saved as a BMP file,
    I can now build a large part of the code relating to, for example,
    the player ship.

    Let's focus on the parts of the game related to the code.

        Split screen
        Sound panning
        Control/input (ship behavior)
        Gravity (physics)
        Bullet (behavior)
        Collisions (ship, bullet, tilemap)
        Music
        Sound
        Game control

    You can divide parts of the code in various ways.
    You can even put each part in separate files if you want.
    And you can separate each game element in various ways as well.
    A lot of ways are also explained in Part 7 - Game on
    of my BlitzBasic Full Foundation tutorial:

        http://www.bettiesart.com/tc/blitz/blitz.html
        (See sub-section "Concepts")

    I'm gonna take one of the easier (if not the easiest) approaches,
    using a single file for the entire code,
    divided into clear sections.

    Okay, you see control/input (ship behavior) and physics up there?
    As these are all directly related to the player (ship),
    these can all be put in a section solely for player routines;
    e.g. the Player section.



    Ship gravity

    In X-NON gravity should be similar to Gravity Force,
    so a gravity pull going straight down.
    So any ship will be pulled towards the ground.

    This may not be as hard as it sounds.
    Or at least I won't bother you with difficult formulae 
    Let's do this in a small testing program.

            

    I'm using a ship image called Ship Pre Final.PNG
    which you can also find
    in the downloadable package file
    containing this tutorial.

; Ship image handle
Local Image

Graphics 640 , 480

Local Image = LoadImage ( "Ship Pre Final.PNG" )

; Now drawing to the invisible screen
SetBuffer BackBuffer ()

Repeat

    ; Flip the invisible with the visible screen
    Flip
    ; Clear the invisible screen
    Cls

Until KeyHit ( 1 )  ; Escape

; Manual cleanup (not required though)
FreeImage Image

End


    Ooh, look!
    A testing program template for our ship 
    A nice black screen with 1 key to press (Esc) 

    Time for some more functionality.
    Let's place the ship on a specific location using two variables,
    for the X and Y coordinates.
    Our gravity is straight down, so from the top of the screen, to the bottom.
    The Y coordinate at the top of the screen is 0,
    and increases when you go down.
    So that's exactly what we want! 

    Let's start by putting our ship at the bottom of the screen, facing up.
    What should happen if the ship would thrust for a short moment (upwards)?
    The ship should 'jump' shortly and land back
    on the starting position, right?
    Is the gravity always in effect?
    Yes! 
    And the gravity is downwards.
    So we can just add something to the current Y coordinate.

Y = Y + gravity


    What happens if we thrust?
    We go up, right?
    So subtracting from the Y coordinate.

Y = Y - thrust


    The gravity is pretty constant, usually, right?
    But what about thrust?
    We could use a variable thrust strength,
    e.g. the longer you hold thrust, the more thrust you build.
    But let's use a constant for thrust as well.

    Understandably, if our thrust strength equals gravity strength,
    we're not falling nor thrusting.
    So to be able to thrust out of the gravity pull,
    we have to use a thrust strength greater than the gravity strength.

Const Gravity = 1
Const Thrust  = 3


    We can change the values of these later,
    if the strengths are too strong or too weak.

    We'll also need some thrust control using the keyboard.

If KeyDown ( 57 )  ; Space
    ; Thrusting!
End If


    And finally making sure the ship can't leave the bottom of the screen.

If Y > 480 Then Y = 480


    Can it be any simpler?
    Maybe 
    But let's merge what we have for now into a single program
    and see what it does, shall we?

    For the assembled program,
    take a look at the file Ship Gravity 1.BB
    in the Tutorial files index.

; Strengths
Const Gravity = 1
Const Thrust  = 3

; Ship position
Local X
Local Y

; Ship image handle
Local Image

; Initial X coordinate (middle of screen width)
X = 320
; Initial Y coordinate (bottom of screen)
Y = 480

Graphics 640 , 480

Image = LoadImage ( "Ship Pre Final.PNG" )
MidHandle Image

; Now drawing to the invisible screen
SetBuffer BackBuffer ()

Repeat

    ; Space is being held down
    If KeyDown ( 57 )  ; Space
        ; Lift off!
        Y = Y - Thrust
    End If

    ; Gravity is always in effect
    Y = Y + Gravity

    ; Prevent ship from falling through the bottom
    If Y > 480 Then Y = 480

    ; Display the ship
    DrawImage Image , X , Y

    ; Flip the invisible with the visible screen
    Flip
    ; Clear the invisible screen
    Cls

Until KeyHit ( 1 )  ; Escape

; Manual cleanup (not required)
FreeImage Image

End


    When you run the program, it doesn't look very realistic 
    An easy solution is using a vertical speed variable
    we can then use for gravity and thrust.

; Thrust using space, upwards
If KeyDown ( 57 ) Then speedY = speedY - Thrust

; Apply gravity
speedY = speedY + Gravity


    And then applying the vertical speed to the vertical position.

Y = Y + speedY


    Oh, and adding another little ship stop thingy
    when the ship hits the bottom.

If Y > 480
    Y = 480

    ; Stop the ship
    speedY = 0
End If


    Assembling the above
    would make the program Ship Gravity 2.BB
    in the Tutorial files index.

; Strengths
Const Gravity = 1
Const Thrust  = 3

; Ship position
Local X
Local Y

; Ship speed
Local speedY

; Ship image handle
Local Image

; Initial X coordinate (middle of screen width)
X = 320
; Initial Y coordinate (bottom of screen)
Y = 480

Graphics 640 , 480

Image = LoadImage ( "Ship Pre Final.PNG" )
MidHandle Image

; Now drawing to the invisible screen
SetBuffer BackBuffer ()

Repeat

    ; Thrust using space, upwards
    If KeyDown ( 57 ) Then speedY = speedY - Thrust

    ; Apply gravity
    speedY = speedY + Gravity

    ; Apply speed to position
    Y = Y + speedY

    ; Prevent ship from falling through the bottom
    If Y > 480
        Y = 480

        ; Stop the ship
        speedY = 0
    End If

    ; Display the ship
    DrawImage Image , X , Y

    ; Flip the invisible with the visible screen
    Flip
    ; Clear the invisible screen
    Cls

Until KeyHit ( 1 )  ; Escape

; Manual cleanup is not mandatory
FreeImage Image

End


    If you run it, you'll notice that we now have a ship
    that acts more like a kangaroo! 
    The strengths are a bit high, but the effect is what we want, right? 
    We can implement this bit of code in the game later on,
    and tweak the strength to be just right.

    Now, for something completely different..



    Sound panning

    I had the idea to make all sounds of the left player screen
    audible on the left speaker and the right player on the right speaker.
    Now, I'm just hoping that the person playing the game
    does not have a broken left speaker 
    Okay, let's make a small program that does this.

    I'm using a sound called Test Sound.MP3 (from the package)
    to see how to pull this off easily.

; Load the sample and set it to loop
Local Sound = LoadSound ( "Test Sound.MP3" )
LoopSound Sound

; Play the sample and keep track of the channel
Local Channel = PlaySound ( Sound )

; Wait for key, then exit
WaitKey
End


    From this point, to adjust the panning we can use the ChannelPan command.

; Panning
ChannelPan Channel , -1  ; Left
ChannelPan Channel , 0  ; Center
ChannelPan Channel , 1  ; Right


    Now if we have two players, we will probably have to identify each.
    Like simply using a variable containing 1 for player 1, and 2 for player 2.

; Player identification
Local PlayerNumber


    So if it's player 1, play the left channel,
    and if it's player 2, play the right channel.

; Left player
If PlayerNumber = 1

    ; Left panning
    ChannelPan Channel , -1

; Right player
ElseIf PlayerNumber = 2

    ; Right panning
    ChannelPan Channel , 1

EndIf


    Did you know this can also be done using maths?
    The above code is probably faster in execution, though.

    Let's see if we can convert these numbers 1 and 2
    to the new scale and offset.
    If you have seen my Conversions tutorial, this should be a snap.

    Starting with number 1; offset 1 from 0.
    With a range of 1; because 2 is 1 more than 1.

source offset = 1
source scale = 1


    Converting that to the new offset -1; left channel.
    And with a range of 2: (1) - (-1) = 2, e.g. right channel - left channel.

target offset = -1
target scale = 2


    So, first remove the source offset; 1.

target value = source value - 1


    Remove the source scale; 1.
    But 1 is already the scale, so no biggy.

    Then convert to the target scale; 2.

target = ( source - 1 ) * 2


    And finally, add the target offset; -1.

target = ( source - 1 ) * 2 + -1


    Does this make any sense? 

ChannelPan Channel , ( PlayerNumber - 1 ) * 2 - 1


    It seems like the panning bit is ready for implementation 

    If this bit is confusing, don't worry.
    Using a simple 'If Then' is easier to read anyway.



    Ship "Asteroids" physics

    If you've already seen one or more of the following tutorials:
    - Vectors and Sine waves
    - Project Z: One
    - Project Z: Two
    Then you probably already understand how this works.

    To recap, it's basically about adding a thrust vector
    to the current velocity vector.
    Some vector examples:

            

    Imagine flying upwards,
    then pressing the right arrow key to rotate right,
    but still flying upwards.
    Now pressing the up arrow key
    will slowly shift the direction to the right.

    So the velocity vector (current X and Y ship speeds)
    is separate from the thrust vector.
    And the thrust vector is only significant when thrusting.

            

    Then, when calculating the new ship velocity vector,
    you simply add the thrust vector to the current ship velocity vector.

            

    First, setting up a screen resolution.
    A bunch of constants for convenience 

; Blitz graphics window mode states
Const WindowMode_AutoDetect = 0
Const WindowMode_FullScreen = 1
Const WindowMode_Windowed   = 2
Const WindowMode_Scaled     = 3

; Desired screen settings
Const ScreenWidth  = 640
Const ScreenHeight = 480
Const ColorDepth   = 0
Const WindowMode   = WindowMode_AutoDetect

..

; Setup screen
Graphics ScreenWidth , ScreenHeight , ColorDepth , WindowMode
SetBuffer BackBuffer ()


    I'm using the same spaceship image Ship Pre Final.PNG as before.
    Only this time, I'm gonna rotate it, in real-time, to make it easy.

; Original ship image (pointing upwards)
Local ShipImage
; Temporarily rotated ship (any direction)
Local RotatedShipImage

..

; Load and center ship image
ShipImage = LoadImage ( "Ship Pre Final.PNG" )
MidHandle ShipImage

; Disable rotation/scaling smoothing
TFormFilter False


    Let's set the ship basics up, like its location.

; Ship position
Local PosX#
Local PosY#

..

; Start in center of screen
PosX = ScreenWidth  / 2
PosY = ScreenHeight / 2


    You may wonder what's with the dots inbetween each piece of code.
    Well, I like separating variable definition from usage (execution).
    Like having a shopping list of items you want to buy, or in this case, use.

    In the code I'm using horizontal lines as separator.
    It's like what we talked about earlier in Structure,
    where the code becomes easier to read, understand and modify
    by separating the definition from the execution.

    The ship needs some sort of control, so I'm gonna add some keys.

; Ship motion control
Const KeyUp    = 200
Const KeyDown  = 208
Const KeyLeft  = 203
Const KeyRight = 205

; Game control
Const KeyEsc   =   1


    Now, if you'd want to rotate the ship,
    we'd need to have an angle.

; Current ship angle
Local Angle#


    So we can set the angle to any value
    and draw the ship using this angle.

; - Ship image
;   - Duplicate the original image
RotatedShipImage = CopyImage ( ShipImage )
;   - Rotate it to the current angle
RotateImage RotatedShipImage , Angle
;   - Then draw it on screen
DrawImage RotatedShipImage , PosX , PosY
;   - And clear the rotated image
FreeImage RotatedShipImage


    This renders the rotated ship image each frame,
    in real-time, which is very slow.
    So I will pre-rotate it in the final version,
    storing the images in an array for easy access.

    Now we can rotate the ship by changing the angle.

; Ship rotation speed in degrees per frame
Const RotateSpeed = 4

..

; - Rotate left
If KeyDown ( KeyLeft )
    Angle = Angle - RotateSpeed
    If Angle < 0 Then Angle = Angle + 360
EndIf

; - Rotate right
If KeyDown ( KeyRight )
    Angle = Angle + RotateSpeed
    If Angle >= 360 Then Angle = Angle - 360
EndIf


    Note the angle wrapper; when the angle becomes too high or too low,
    it is wrapped to the other side of the scale.
    I usually do this to keep it in range of, for example,
    the indices of an array, like:

Dim Images( 360 )


    Which I do to prevent the angle from going out of range,
    which Blitz - as well as most other languages - does not like.

    Finally, the tricky bit; velocity vectors.
    I'm using my favorite vector functions to make it a little easier.

; Trigonometry: return horizontal vector
Function VectorX# ( Distance# , Angle# )
    Return Sin ( Angle ) * Distance
End Function

; Trigonometry: return vertical vector
Function VectorY# ( Distance# , Angle# )
    Return Sin ( Angle - 90 ) * Distance
End Function

; Trigonometry: return distance using vector
Function VectorDistance# ( X# , Y# )
    Return Sqr ( X * X + Y * Y )
End Function

; Trigonometry: return angle using vector
Function VectorAngle# ( X# , Y# )
    Return 180 - Atan2 ( X , Y )
End Function


    I like putting functions like these
    in a section (or external library)
    for all math related routines.

    Now, the ship can have a speed (velocity),
    and a heading (direction), which, together,
    make up a velocity vector.

; Current ship heading (direction)
Local Heading#
; Current ship speed (velocity)
Local Speed#


    These can also be written as an (X,Y) vector, like this:

; Ship speed vector
Local SpeedX#
Local SpeedY#


    To be able to thrust, let's add a thrust vector too,
    as well as defining the thrust strength.

; Ship thrust speed in pixels per frame
Const ThrustSpeed# = 0.12

..

; Ship thrust vector
Local ThrustX#
Local ThrustY#


    So when you press the Down key (as in Gravity Force),
    the thrust vector should be set to the thrust strength
    and the current ship angle.

; - Thrust
If KeyDown ( KeyDown )
    ; Combine thrust speed and ship angle to make the thrust vector
    ThrustX = VectorX ( ThrustSpeed , Angle )
    ThrustY = VectorY ( ThrustSpeed , Angle )
Else
    ; Reset thrust vector
    ThrustX = 0
    ThrustY = 0
EndIf


    Then the thrust vector should be added to the current velocity vector.
    But first calculate the velocity vector using the current speed and heading.

; - Take the current velocity vector (speed and heading)
; - Then add the thrust vector to it (thrust and angle)
; - Which becomes the new velocity vector
SpeedX = VectorX ( Speed , Heading ) + ThrustX
SpeedY = VectorY ( Speed , Heading ) + ThrustY


    But we don't know the actual speed and heading yet.
    So let's convert this velocity vector back to (X,Y).

; - Now update the current speed and heading with the new velocity vector
Speed = VectorDistance ( SpeedX , SpeedY )
Heading = VectorAngle ( SpeedX , SpeedY )


    Now we can also check if the ship is going too fast.
    Because I've found that having a limited ship speed
    increases the fun to chase someone,
    it's easier to control the ship,
    and, for example,
    being able to stop faster when encountering an obstacle.

; Ship maximum velocity in pixels per frame
Const MaxSpeed = 5

..

; - Limit the speed to the maximum
If Speed > MaxSpeed
    Speed = MaxSpeed

    ; Apply the new speed to the velocity vector
    SpeedX = VectorX ( Speed , Heading )
    SpeedY = VectorY ( Speed , Heading )
EndIf


    Using the most recent velocity vector,
    either the one calculated before (from the speed and heading),
    or the one that was recalculated when going too fast,
    we can change the ship's position.

; - Finally add the velocity vector to the ship position
PosX = PosX + SpeedX
PosY = PosY + SpeedY


    Take a look at Ship Physics 1.BB
    in the Tutorial files index
    for the assembled version.

; Trigonometry: return horizontal vector
Function VectorX# ( Distance# , Angle# )
    Return Sin ( Angle ) * Distance
End Function

; Trigonometry: return vertical vector
Function VectorY# ( Distance# , Angle# )
    Return Sin ( Angle - 90 ) * Distance
End Function

; Trigonometry: return distance using vector
Function VectorDistance# ( X# , Y# )
    Return Sqr ( X * X + Y * Y )
End Function

; Trigonometry: return angle using vector
Function VectorAngle# ( X# , Y# )
    Return 180 - ATan2 ( X , Y )
End Function

;-------------------------------------------------------------------------------

; Blitz graphics window mode states
Const WindowMode_AutoDetect = 0
Const WindowMode_FullScreen = 1
Const WindowMode_Windowed   = 2
Const WindowMode_Scaled     = 3

; Desired screen settings
Const ScreenWidth  = 640
Const ScreenHeight = 480
Const ColorDepth   = 0
Const WindowMode   = WindowMode_AutoDetect

; Ship motion control
Const KeyUp    = 200
Const KeyDown  = 208
Const KeyLeft  = 203
Const KeyRight = 205
; Game control
Const KeyEsc   =   1

; Ship thrust speed in pixels per frame
Const ThrustSpeed# = 0.12
; Ship rotation speed in degrees per frame
Const RotateSpeed# = 4
; Ship maximum velocity in pixels per frame
Const MaxSpeed     = 5

;-------------------------------------------------------------------------------

; Ship position
Local PosX#
Local PosY#

; Current ship angle
Local Angle#
; Current ship heading (direction)
Local Heading#
; Current ship speed (velocity)
Local Speed#

; Ship speed vector
Local SpeedX#
Local SpeedY#

; Ship thrust vector
Local ThrustX#
Local ThrustY#

; Original ship image (pointing upwards)
Local ShipImage
; Temporarily rotated ship (any direction)
Local RotatedShipImage

;-------------------------------------------------------------------------------

; Setup screen
Graphics ScreenWidth , ScreenHeight , ColorDepth , WindowMode
SetBuffer BackBuffer ()

; Load and center ship image
ShipImage = LoadImage ( "Ship Pre Final.PNG" )
MidHandle ShipImage

; Disable rotation/scaling smoothing
TFormFilter False

; Start in center of screen
PosX = ScreenWidth  / 2
PosY = ScreenHeight / 2

Repeat

    ; Input

    ; - Rotate left
    If KeyDown ( KeyLeft )
        Angle = Angle - RotateSpeed
        If Angle < 0 Then Angle = Angle + 360
    EndIf

    ; - Rotate right
    If KeyDown ( KeyRight )
        Angle = Angle + RotateSpeed
        If Angle >= 360 Then Angle = Angle - 360
    EndIf

    ; - Thrust
    If KeyDown ( KeyDown )
        ; Combine thrust speed and ship angle to make the thrust vector
        ThrustX = VectorX ( ThrustSpeed , Angle )
        ThrustY = VectorY ( ThrustSpeed , Angle )
    Else
        ; Reset thrust vector
        ThrustX = 0
        ThrustY = 0
    EndIf

    ; Update

    ; - Take the current velocity vector (speed and heading)
    ; - Then add the thrust vector to it (thrust and angle)
    ; - Which becomes the new velocity vector
    SpeedX = VectorX ( Speed , Heading ) + ThrustX
    SpeedY = VectorY ( Speed , Heading ) + ThrustY

    ; - Now update the current speed and heading with the new velocity vector
    Speed = VectorDistance ( SpeedX , SpeedY )
    Heading = VectorAngle ( SpeedX , SpeedY )

    ; - Limit the speed to the maximum
    If Speed > MaxSpeed
        Speed = MaxSpeed

        ; Apply the new speed to the velocity vector
        SpeedX = VectorX ( Speed , Heading )
        SpeedY = VectorY ( Speed , Heading )
    EndIf

    ; - Finally add the velocity vector to the ship position
    PosX = PosX + SpeedX
    PosY = PosY + SpeedY

    ; - Screen edge wrap when crossing screen boundaries
    If PosX < 0
        PosX = PosX + ScreenWidth
    ElseIf PosX >= ScreenWidth
        PosX = PosX - ScreenWidth
    EndIf
    If PosY < 0
        PosY = PosY + ScreenHeight
    ElseIf PosY >= ScreenHeight
        PosY = PosY - ScreenHeight
    EndIf

    ; Render

    Cls

    ; - Ship image
    ;   - Duplicate the original image
    RotatedShipImage = CopyImage ( ShipImage )
    ;   - Rotate it to the current angle
    RotateImage RotatedShipImage , Angle
    ;   - Then draw it on screen
    DrawImage RotatedShipImage , PosX , PosY
    ;   - And clear the rotated image
    FreeImage RotatedShipImage

    Flip

Until KeyHit( KeyEsc )

; Blitz automagically cleans up
End


    I've also added a screen position wrapper
    in the assembled program,
    so you don't disappear
    after crossing the screen boundaries.

    Now, having a functional space ship physics program,
    we can easily add other bits at any time, like gravity.

    Let's hop over to some more audio first.



    Thrust sound

    To make the ship come alive,
    I've added a rather raw engine sound
    which makes it seem
    like some kind of magnetic drive.

    To test this in practice,
    I've created yet another small program
    called Thrust Sound 1.BB
    in the Tutorial files index.

    Starting with setting up the sound.

; Attempt to load the sound
Local Sound = LoadSound ( "Thrust.WAV" )
If Not Sound Then RuntimeError "Unable to load sound"

; Make it loop, start playing it, and pause it
LoopSound Sound
Local Channel = PlaySound ( Sound )
PauseChannel Channel


    Now let's test this in real-time;
    we can use a Paused flag to set later on anyway.

; Test channel pause/resume
Repeat
    If KeyDown ( 57 )  ; Space
        ResumeChannel Channel
    Else
        PauseChannel Channel
    End If
Until KeyHit ( 1 )  ; Esc


    That should do it 



    Tilemap

    The tilemap routines I've used are almost identical
    to the ones from my Tilemap tutorial.

    One main difference is that I'm using external files,
    rather than internal Data statements for the tile map data.

    I've created a spicy tileset that reminded me of Gravity Force,
    which I've put inside the file Tiles.PNG:

            

    Now for the code, let's create a new section
    for everything related to the Tilemap,
    which can be put in the Definition area
    as you can see in Structure.

    We can start by simply defining the tiles first,
    a bunch of constants at the top of our Tilemap section.

; Size of a single tile
Const TileWidth  = 32
Const TileHeight = 32

; Number of tiles in anim image
Const TileCount  = 42


    Then we can setup the tilemap data, info and images,
    residing in the (Global) variables part of the Tilemap section.

; Tiles images
Global TileStrip

; ( 1-based tile position index )
Dim    Tilemap( 0 , 0 )
Global TilemapWidth
Global TilemapHeight

..

; Load tiles images
TileStrip = LoadAnimImage ( "Tiles.PNG" , TileWidth , TileHeight , 0 , TileCount )


    The call to LoadAnimImage
    should actually be put in the Main initialization area
    (as outlined in Structure)
    because it happens after the Graphics screen is setup
    which I'll come to shortly in Video mode detection.

    And finally a function for loading a tilemap from file,
    which can be defined in the sub-routines (or functions) area
    at the bottom of the Tilemap section.

Function LoadTilemap ( FileName$ )
    Local FileHandle
    Local PosX
    Local PosY
    Local Line$
    Local TileNumber

    ; Attempt to open file (return False if unsuccesful)
    FileHandle = OpenFile ( FileName )
    If Not FileHandle Then Return False

    ; Grab tilemap dimensions
    TilemapWidth = ReadLine ( FileHandle )
    TilemapHeight = ReadLine ( FileHandle )

    ; Reset tilemap
    Dim Tilemap( TilemapWidth , TilemapHeight )

    For PosY = 1 To TilemapHeight

        Line = ReadLine ( FileHandle )

        For PosX = 1 To TilemapWidth

            ; Convert tilenumber in map to framenumber in anim image (chr 33 = tile 0)
            TileNumber = Asc ( Mid ( Line , PosX , 1 ) ) - 33

            ; Discard tiles which are out of range
            If TileNumber >= 0 And TileNumber <= TileCount-1
                Tilemap( PosX , PosY ) = TileNumber
            End If

        Next
    Next

    CloseFile FileHandle

    Return True
End Function


    You can also see that
    I'm using a character offset of 33 for tile images.
    So Chr(33) or a "!" character in the file
    means the first tile image.

    This way, you can use any text editor to edit the tilemap data.
    Here's an example tilemap:

20
7
!!!!!!!!!!!!!!!!!!!!
!                  !
! ! # % ' ) + - /  !
!                  !
!  " $ & ( * , . 0 !
!                  !
!!!!!!!!!!!!!!!!!!!!


    If you save this tilemap to file,
    like Test Tilemap 1.TXT in the package,
    you can now load it simply with:

LoadTilemap "Test Tilemap 1.TXT"


    This call to the LoadTilemap function
    can be placed in the Main initialization section
    as defined in Structure.

    You probably noticed that the above tilemap is
    20 tiles wide and 7 tiles high.

    Now, I've set up another rule where tiles outside of 0 and TileCount,
    which is the number of available tile images, will be discarded.
    So spaces, which is Chr(32), would make -1 in the LoadTilemap above,
    which is out of range, so these tiles will stay 0.
    Further on in the program, I will skip those 0 tiles from being drawn.

    Another thing is that I will need to know where players spawn.
    So I've decided to use a special tile that will be used as spawn spots.

    After having created the tile frames,
    this is the information I wrote down:

TileStrip: Frame 0 = spawn spot , Frame 1 = Wall , Frame 2 = Vegetation Lower , etc
TileMap: Tile 0 = dont display, Tile 1..42 = display frame from TileStrip
TileFile: [ ](#32) = Spacing, [!](#33) = Spawnspot, ["](#34) = Frame 1, etc

TileFile -> TileMap conversion:
#32   (spacing)     ->  -1  ->  out of range        ->  0   (dont display)
#33   (spawn spot)  ->   0  ->  create spawn spot   ->  0   (dont display)
#34   (frame 1)     ->   1  ->  on tilemap          ->  1   (display)
#35   (etc)




    Spawn spots

    Maybe you have noticed that the first tile frame is a spawn spot.

            

    So when the LoadTilemap routine encounters a tile with frame 0,
    it should create a spawn spot, and hide the tile.

; Discard tiles which are out of range
If TileNumber >= 0 And TileNumber <= TileCount-1
    ; This is a spawn spot (tile 0)
    ; Add it to the list and dont put in tilemap
    If TileNumber = 0
        ; Tilemap scale
        AddSpawnSpot PosX , PosY
        SpawnSpots = SpawnSpots + 1
    ; Add all other tiles to tilemap
    Else
        Tilemap( PosX , PosY ) = TileNumber
    End If
End If


    You can see the undefined AddSpawnSpot and SpawnSpots above.
    SpawnSpots will be a global variable holding the total amount
    of available spawn spots.
    And AddSpawnSpot a function to add a spawn spot to the list.

    I usually create the call to the function
    before creating the function itself,
    to clarify the working of it.

    For the list of spawn spots,
    I've chosen a list of objects,
    using Types.

Type SpawnSpot

    ; Position
    Field PosX
    Field PosY

End Type

..

; Total number of spawn spots in tilemap
Global SpawnSpots

..

Function AddSpawnSpot ( PosX , PosY )
    Local This.SpawnSpot

    This = New SpawnSpot
    This\PosX = PosX
    This\PosY = PosY

End Function


    The variable SpawnSpots is not set to any value by default.
    But every time when loading a new tilemap,
    to start fresh, this should be set to 0 anyway,
    as well as deleting any existing spawnspots.

Function LoadTilemap ( FileName$ )

    ..

    ; Reset tilemap
    Dim Tilemap( TilemapWidth , TilemapHeight )

    ; And spawn spots
    Delete Each SpawnSpot
    SpawnSpots = 0


    I've chosen to place the code for spawn spots
    in a section of its own,
    needing no code to be placed
    in either of the Main initialization
    or Main execution sections,
    as I've shown in Structure.

    Because all of the handling of spawn spots
    is performed in other sections,
    such as the LoadTilemap function
    in the Tilemap section.



    Video mode detection

    So far we've been using 640x480 as the normal resolution.
    What if we want to use a higher, or better, wider resolution,
    but we don't know if the computer's video card supports it?
    Let's test and add exactly this feature.

    As in the Graphics resolution chapter,
    I used the CountGfxModes Blitz function to display all available modes.
    Now I'm gonna wrap a function around it,
    to check if a single resolution is listed.

Function ResAvail ( Width , Height )
    For ColorDepth = 16 To 32 Step 8
        If GfxModeExists ( Width , Height , ColorDepth ) Then Return ColorDepth
    Next
End Function


    This function tests for 16bit, 24bit and 32bit color depths,
    which (in theory ) should support all video cards.

    Let's add a bit of a test bed for this function.

; Blitz graphics window mode states
Const WindowMode_Autodetect = 0
Const WindowMode_Fullscreen = 1
Const WindowMode_Windowed   = 2
Const WindowMode_Scaled     = 3

..

; Graphics resolution
Global ScreenWidth
Global ScreenHeight
Global WindowMode
Global ColorDepth

..

; Windowed in debug mode, otherwise fullscreen
WindowMode = WindowMode_AutoDetect

; Prefered
ScreenWidth = 1280
ScreenHeight = 720
ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
If Not ColorDepth
    ; Alternative
    ScreenWidth  = 800
    ScreenHeight = 600
    ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
    If Not ColorDepth
        ; Bare minimum: Small view!
        ScreenWidth  = 640
        ScreenHeight = 480
        ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
    End If
End If

Graphics ScreenWidth , ScreenHeight , ColorDepth , WindowMode
WaitKey
End


    This program checks for 1280x720, then 800x600 and finally 640x480.
    So we can now use this technique for the game,
    and add a loong list of desired resolutions 

    The top (definition) of this code could be placed
    in a section for Graphics handling.

    While the bottom of this code (execution)
    could be placed somewhere at the beginning
    of the Main initialization section,
    because all other graphics depend on it,
    such as LoadAnimImage and LoadImage.



    Sounds overlapping

    Somewhere along the way I found a problem
    when for example 2 things exploded at the same time.
    Some other games also have this same thing, where,
    if too many of the same sounds are played at the same time,
    the sound is extremely loud and causes extreme distortion,
    which sounds not just ugly to me,
    but in all honesty, is very painful for my ears!

    So I've come up with a solution,
    where I track the channels manually,
    and see if a new sound to be played is already playing.
    I've added a minimum overlap time,
    so the same sound can only be played
    if this time has elapsed
    since the sound was first started.

    I'm using an object structure to keep track of each channel.

; Sound channel tracker
Type ActiveChannel

    ; Channel containing the sound playing
    Field ChannelHandle

    ; Reference to the sound being played
    ; (each sound has a different address)
    Field SoundHandle

    ; Time when started playing
    Field Created

    ; How long to wait before being able to play same sound.
    Field TimeOut

End Type


    And using a single function I can:
    - Update the currently playing sounds.
    - Play the new sound,
      if it doesn't overlap with an existing sound.

Function PlaySample ( SoundHandle , TimeOut = False )
    Local FindChannel.ActiveChannel
    Local FoundChannel.ActiveChannel
    Local Playing = False
    Local PlayNew = False

    ; Check all previously playing sounds/channels
    For FindChannel = Each ActiveChannel
        ; If this channel is still playing
        If ChannelPlaying ( FindChannel\ChannelHandle )
            ; And the sound being played is identical to the new sound to play.
            If FindChannel\SoundHandle = SoundHandle
                ; Remember that it is already being played
                Playing = True
                ; And store it for later access
                FoundChannel = FindChannel
            End If
        ; This channel is no longer playing
        Else
            ; Remove it from the list
            Delete FindChannel
        End If
    Next

    ; The new sound to play is already playing (it was found in the list)
    If Playing
        ; If the time since creation exceeds the channel's overlap (time out)
        If MilliSecs - FoundChannel\Created >= FoundChannel\TimeOut
            ; Playing the new sound is allowed (overlapping)
            PlayNew = True
        End If
    ; The new sound to play is not yet playing
    Else
        ; So playing the new sound is allowed (without hesitation)
        PlayNew = True
    End If

    ; Allowed to play new sound
    If PlayNew
        ; Create an object to track the channel
        FoundChannel = New ActiveChannel

        ; Remember the time of creation
        FoundChannel\Created = MilliSecs
        ; Record the overlapping time
        FoundChannel\TimeOut = TimeOut
        ; Also remember which sound is used
        FoundChannel\SoundHandle = SoundHandle
        ; Play the sound (and keep track)
        FoundChannel\ChannelHandle = PlaySound ( SoundHandle )

        ; Finally return the channel,
        ; so you can optionally modify its properties.
        Return FoundChannel\ChannelHandle
    End If
End Function


    The working of this routine is fairly straight-forward, as you can see 
    It is included in a test program Sound Overlap.BB,
    located in the Tutorial files index,
    which you can check out to see how to operate the routine.

Local sound = LoadSound ( "Spawn.WAV" )
If Not sound Then RuntimeError "Unable to load sound"

Repeat
    ; press space to play sound with overlap protection
    If KeyDown ( 57 )
        PlaySample sound , 500
    End If
Until KeyHit ( 1 )
End


    Note that PlaySample returns False if the sound is already playing.
    But if you place 'the line with Return on it' outside the If,
    PlaySample will return the currently playing channel instead.

    I decided to put this funky system
    in a separate section called Audio
    in the Definition area of the code,
    as you can see in Structure.

    By the way,
    you may be wondering why I "forgot" the braces
    behind the MilliSecs in the code above.
    Allow me to elaborate 



    MilliSecs

    Some parts of this game use MilliSecs() to keep track of time.
    Such as how long bullets should stay alive.
    But, because some Blitz functions, like MilliSecs(),
    take a bit of time to be executed,
    I've created a clever yet easy optimization,
    to prevent the game speed from being affected in a bad way,
    in case MilliSecs() needs to be called very often.

    I'm using a Global variable called MilliSecs,
    just without the braces ().

Global MilliSecs


    And I set this to the value of MilliSecs() every frame,
    e.g. in the main loop (Main execution section).

    Which means that this function will never be called
    any more than once per frame nor any less,
    with a very reasonable timing accuracy.

MilliSecs = MilliSecs ()


    Now I can just use MilliSecs, without the braces (),
    in any place, Functions included, and at any time,
    just like when using MilliSecs() directly.

    For more information about MilliSecs()
    take a look at Part 7 - Game On
    of my BlitzBasic Full Foundation tutorial
    specifically in the Timing sub-section.



    Bullets

    Let's add some more gameplay elements, like bullets!
    For ease of bullet management, using another list of bullets,
    using Types for bullet objects.

    Note that this is all very similar
    to the techniques used
    in my previous tutorials, such as:
    - Vectors and Sine waves
    - Project Z: One
    - Project Z: Two

Type Bullet

    ; Time of creation
    Field TimeCreated
    ; Duration of life
    Field TimeToLive

    ; Position
    Field PosX#
    Field PosY#
    ; Velocity
    Field VelX#
    Field VelY#

End Type


    The timing is done using the MilliSecs global.
    TimeCreated will be set to MilliSecs when the bullet is created.
    And TimeToLive will define the amount of time (in milliseconds)
    this bullet will keep flying.

; Bullet time to live in milliseconds
Const BulletTime = 5000


    In fact, the TimeToLive field here is duplicate at the moment
    because it is always the same as the value of the BulletTime constant.
    But while I was creating this,
    I thought that for the explosion effect
    I could re-use the bullet code.
    So I can easily expand on this soon.

    Apart from timing, I'm using another velocity vector
    for the bullet's (constant) displacement.

    So, time to create a bullet..

Function CreateBullet ( PosX , PosY , VelX# , VelY# )
    Local This.Bullet

    This = New Bullet
    This\PosX = PosX
    This\PosY = PosY
    This\VelX = VelX
    This\VelY = VelY

    This\TimeCreated = MilliSecs

    ; Use default time to live
    This\TimeToLive = BulletTime

End Function


    This function doesn't calculate anything,
    like where the bullet should be flying to,
    or how fast the bullet should be going.

    First, to make the bullets fly, I'll also need to know the speed,
    which I'm measuring in pixels per frame.

; Bullet velocity in pixels
Const BulletSpeed    =    4


    E.g. the position of the bullet
    is altered 4 pixels every time,
    while it is still alive.

    This can be done
    in an UpdateBullets function.

Function UpdateBullets ()
    Local This.Bullet

    For This = Each Bullet

        ; Update position
        This\PosX = This\PosX + This\VelX
        This\PosY = This\PosY + This\VelY

        ; Time to die
        If MilliSecs - This\TimeCreated >= This\TimeToLive
            Delete This
        End If

    Next

End Function


    This should all be very straight-forward.
    But, what does the bullet look like anyway?

             <----- Bullet.BMP

    I'm using a very simple 2x2 image
    for a retro-style look.

; Simple bullet image
Global BulletImage

..

; Load bullet image
BulletImage = LoadImage ( "Bullet.BMP" )
MidHandle BulletImage


    Logically, the player will be able to fire using the ship,
    so the bullet should be created
    exactly at the tip of the ship image.

            

    Looking at the ship image,
    this is approximately 24 pixels away
    from the center of the ship image.

; Bullet spawning distance from player image hotspot in pixels
Const BulletDistance =   24


    And ofcourse a simple drawing function.

Function DrawBullets ()
    Local This.Bullet

    For This = Each Bullet
        DrawImage BulletImage , This\PosX , This\PosY
    Next

End Function


    Now we can fire a bullet
    in a certain direction and speed.
    For example,
    if the ship is located
    at (PosX,PosY) pointing upwards,
    the fire code would look something like this:

CreateBullet PosX , PosY-BulletDistance , 0 , -BulletSpeed


    Let's use my favorite vector functions
    and add a ShipAngle,
    which would be the direction of the ship.

; Ship is pointing upwards
Const ShipAngle = 0

..

; Ship position
Local ShipPosX
Local ShipPosY

; Bullet starting position & speed vector
Local BulletPosX
Local BulletPosY
Local BulletVelX#
Local BulletVelY#

..

; Calculate where to create bullet in front of ship
BulletPosX = ShipPosX + VectorX ( BulletDistance , ShipAngle )
BulletPosY = ShipPosY + VectorY ( BulletDistance , ShipAngle )

; Initial bullet velocity vector
BulletVelX = VectorX ( BulletSpeed , ShipAngle )
BulletVelY = VectorY ( BulletSpeed , ShipAngle )

CreateBullet BulletPosX , BulletPosY , BulletVelX , BulletVelY


    Let's put all this together in a test program,
    including all the required definitions,
    and see if it is to our liking.

; Trigonometry: return horizontal vector
Function VectorX# ( Distance# , Angle# )
    Return Sin ( Angle ) * Distance
End Function

; Trigonometry: return vertical vector
Function VectorY# ( Distance# , Angle# )
    Return Sin ( Angle - 90 ) * Distance
End Function

; Trigonometry: return distance using vector
Function VectorDistance# ( X# , Y# )
    Return Sqr ( X * X + Y * Y )
End Function

; Trigonometry: return angle using vector
Function VectorAngle# ( X# , Y# )
    Return 180 - ATan2 ( X , Y )
End Function

;-------------------------------------------------------------------------------

; Blitz graphics window mode states
Const WindowMode_AutoDetect = 0
Const WindowMode_FullScreen = 1
Const WindowMode_Windowed   = 2
Const WindowMode_Scaled     = 3

; Desired screen settings
Const ScreenWidth  = 640
Const ScreenHeight = 480
Const ColorDepth   = 0
Const WindowMode   = WindowMode_AutoDetect

; Bullet control
Const KeySpace =  57
; Game control
Const KeyEsc   =   1

;-------------------------------------------------------------------------------

; Bullet spawning distance from player image hotspot in pixels
Const BulletDistance =   24

; Bullet time to live in milliseconds
Const BulletTime = 5000

; Bullet velocity in pixels
Const BulletSpeed    =    4

; Ship is pointing upwards
Const ShipAngle = 0

;-------------------------------------------------------------------------------

Type Bullet

    ; Time of creation
    Field TimeCreated
    ; Duration of life
    Field TimeToLive

    ; Position
    Field PosX#
    Field PosY#
    ; Velocity
    Field VelX#
    Field VelY#

End Type

;-------------------------------------------------------------------------------

; Smart timing wrapper
Global MilliSecs

; Simple bullet image
Global BulletImage

;-------------------------------------------------------------------------------

Function CreateBullet ( PosX , PosY , VelX# , VelY# )
    Local This.Bullet

    This = New Bullet
    This\PosX = PosX
    This\PosY = PosY
    This\VelX = VelX
    This\VelY = VelY

    This\TimeCreated = MilliSecs

    ; Use default time to live
    This\TimeToLive = BulletTime

End Function


Function UpdateBullets ()
    Local This.Bullet

    For This = Each Bullet

        ; Update position
        This\PosX = This\PosX + This\VelX
        This\PosY = This\PosY + This\VelY

        ; Time to die
        If MilliSecs - This\TimeCreated >= This\TimeToLive
            Delete This
        End If

    Next

End Function


Function DrawBullets ()
    Local This.Bullet

    For This = Each Bullet
        DrawImage BulletImage , This\PosX , This\PosY
    Next

End Function

;-----------------------------------------------------------------------

; Original ship image (pointing upwards)
Local ShipImage

; Bullet starting position & speed vector
Local BulletPosX
Local BulletPosY
Local BulletVelX#
Local BulletVelY#

; Ship position
Local ShipPosX
Local ShipPosY

;-------------------------------------------------------------------------------

; Setup screen
Graphics ScreenWidth , ScreenHeight , ColorDepth , WindowMode
SetBuffer BackBuffer ()

; Load bullet image
BulletImage = LoadImage ( "Bullet.BMP" )
MidHandle BulletImage

; Load and center ship image
ShipImage = LoadImage ( "Ship Pre Final.PNG" )
MidHandle ShipImage

; Place ship in the lower half in the center of the screen
ShipPosX = ScreenWidth  / 2
ShipPosY = ScreenHeight * 3 / 4

Repeat

    ; Timing

    MilliSecs = MilliSecs ()

    ; Input

    If KeyDown ( KeySpace )
        ; Calculate where to create bullet in front of ship
        BulletPosX = ShipPosX + VectorX ( BulletDistance , ShipAngle )
        BulletPosY = ShipPosY + VectorY ( BulletDistance , ShipAngle )

        ; Initial bullet velocity vector
        BulletVelX = VectorX ( BulletSpeed , ShipAngle )
        BulletVelY = VectorY ( BulletSpeed , ShipAngle )

        CreateBullet BulletPosX , BulletPosY , BulletVelX , BulletVelY
    EndIf

    ; Update

    UpdateBullets

    ; Render

    Cls

    DrawImage ShipImage , ShipPosX , ShipPosY
    DrawBullets

    Flip

Until KeyHit( KeyEsc )

; Blitz automagically cleans up
End


    If you run Bullet Physics 1.BB
    (from the Tutorial files index)
    and press Space,
    a string of bullets should be spawned,
    flying upwards.

    So everything seems to work as it should.
    To implement this into the Ship Physics code
    would only require a little bit of renaming
    of variables here and there.

    A sound playing when firing is also added in a snap,
    which code would be placed
    near the call to the CreateBullet function,
    looking something like this:

; Play fire sound
Channel = PlaySample ( FireSound , 10 )
ChannelPan Channel , ( PlayerNumber - 1 ) * 2 - 1


    This code uses both the sound overlap prevention code (10 ms overlap)
    and the 'algorithm' to hear each player on separate stereo channels,
    which I've explained earlier in Sounds overlapping and Sound panning.

    For the final code
    I would create a new section
    for all of the Bullets code,
    which can rest entirely
    in the Definition area
    shown in Structure.

    This would include constants definitions,
    a type object definition,
    some global variables
    and a bunch of functions.

    The UpdateBullets function
    handles just the motion/physics,
    while the DrawBullets function
    only takes care of the rendering.

    In fact, the exact same thing
    applies to the (player) ship.

    I can easily call all of these from the main loop,
    in the Main execution area of the code,
    which is similar to the example program above.



    Pre-rendered rotated ship

    Just like in Project Z: Two I'm using a ship that rotates,
    which can be pre-rendered before the game starts.
    In that game you can see the image being pre-rendered
    during the loading process.

    In X-NON I want to pre-render it to images,
    so also the loading time will be shorter
    (though making the total game filesize bigger).
    I've designed a special Image Rotator program for this,
    with various customizable options.

    Take a look at Image Rotator.BB,
    in the Tutorial files index
    which includes inline comments.
    The process is similar
    to that in Project Z: Two though.

;-------------------------------------------------------------------------------
;
;   Image Rotator V2
;
;,,,,
    ;   Definition
;----

    Const SourceImageFile$  = "Ship Pre Final.PNG"
    Const SourceImageWidth  = 64
    Const SourceImageHeight = 64
    Const SourceFrames      = 1
    Const SourceFrameOffset = 0
    Const SourceFrameToUse  = 0  ; First frame
    Const SourceMask        = False
    Const SourceMaskRed     = 255
    Const SourceMaskGreen   = 0
    Const SourceMaskBlue    = 255
    Const RemoveMaskColor   = True

    Const DestinationFile$  = "Ship Images\Ship "
    Const RotationInterval  = 5
    Const AntiAliasing      = True
    Const Scaling           = True
    Const ScalingTo#        = 1.1
    Const ScalingFrom#      = 1 / ScalingTo

;,,,,
    ;   Processing
;----

    Graphics 640 , 480 , 0 , 2
    TFormFilter AntiAliasing

    Local SourceImage
    Local SourceAnimStrip

    ; Single or multi image
    SourceAnimStrip = LoadAnimImage ( SourceImageFile ,
                                      SourceImageWidth , SourceImageHeight ,
                                      SourceFrameOffset , SourceFrames )
    ; Grab image to use from strip
    SourceImage = CreateImage ( SourceImageWidth , SourceImageHeight )
    SetBuffer ImageBuffer ( SourceImage )
    DrawBlock SourceAnimStrip , 0 , 0 , SourceFrameToUse
    FreeImage SourceAnimStrip

    Local NoMaskImage

    ; Apply virtual masking
    If SourceMask
        MaskImage SourceImage , SourceMaskRed , SourceMaskGreen , SourceMaskBlue
        ; Remove masking color (replace with black)
        If RemoveMaskColor
            NoMaskImage = CreateImage ( ImageWidth ( SourceImage ) ,
                                        ImageHeight ( SourceImage ) )
            SetBuffer ImageBuffer ( NoMaskImage )
            DrawImage SourceImage , 0 , 0
            FreeImage SourceImage
            SourceImage = NoMaskImage
        End If
    End If

    ; Centered hotspot
    MidHandle SourceImage

    ; Upsampling (filter dependent)
    If Scaling Then ScaleImage SourceImage , ScalingTo , ScalingTo

    Local ScreenMidX
    Local ScreenMidY

    SetBuffer BackBuffer ()
    ScreenMidX = GraphicsWidth ()  / 2
    ScreenMidY = GraphicsHeight () / 2

    Local RotatedImage
    Local Angle

    ; Rendering
    For Angle = 0 To 360 Step RotationInterval
        ; Make fresh copy of original to be rotated
        RotatedImage = CopyImage ( SourceImage )
        MidHandle RotatedImage
        ; Rotate with or without filtering
        RotateImage RotatedImage , Angle
        ; Scale if requested
        If Scaling Then ScaleImage RotatedImage , ScalingFrom , ScalingFrom
        ; Render to screen for user to see progress
        DrawImage RotatedImage , ScreenMidX , ScreenMidY
        Flip False
        ; Save image to disk
        SaveImage RotatedImage , DestinationFile + Angle + ".BMP"
        ; Image saved, done
        FreeImage RotatedImage
    Next

    End

;,,,,
    ;
;----
;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,


    It takes a single image (pointing upwards),
    and rotates it at an interval of your choice.
    In this case: 5.

    It then produces separated rotated images,
    with optional customizable smoothing,
    in the range of 0..360 degrees.
    E.g. Ship.PNG -> Ship [0..360].PNG

    I'm also using a separate folder
    for the rotated ship images,
    to keep the large amount of files
    separate from the other files.

    You can take a look
    at the resulting files
    in the Ship Images folder.

    Since I'm using a different ship for each player,
    I'll need to create 2 sets of rotated ships,
    but just changing a few parameters is quick enough.

    As you know,
    I'm giving each player a number,
    like 1 and 2.
    And I'm using a rotation interval of 5
    for reasonably precise rotation (visually).

    You could use a Constant in the program,
    if you'd ever want to change it.

Const RotationInterval = 5  ; degrees


    But I'm going to hardcode this into the program,
    because I'm happy with it
    and I don't need to change it.
    This value relies on what's inside the images anyway.

    Just like in Project Z: Two
    I'm using an array to store the rotated images.
    And because there are 2 players,
    I just add another dimension,
    one for each player.

; ( 1-based player number , 0-based angle )
Dim    PlayerImages( 2 , 360 )


    As previously described in the Specification
    I decided to use a green version of the ship for player 1.
    And a red version for player 2.
    The difference is extremely subtle.

              

    Now, using our handy Image Rotator
    we can quickly turn these
    into 2 rotated ship image sets.

    Then we can use a simple For..Next construct
    to load both sets, ready for use!

; Load pre-rotated player images
For PlayerNumber = 1 To 2
    For Angle = 0 To 360 Step 5
        PlayerImages( PlayerNumber , Angle ) =
            LoadImage ( "Ships\" + "Ship " + PlayerNumber + " - " + Angle + ".BMP" )
        MidHandle PlayerImages( PlayerNumber , Angle )
    Next
Next


    You know, rotating the ship in Project Z: Two
    also occured in steps of 5 degrees,
    e.g. when rotating the ship while playing.

    But what if in X-NON I want a different speed?
    E.g. the visual angle would be different
    from the value of PlayerAngle.

PlayerAngle = 3
DrawImage PlayerImages( PlayerNumber , PlayerAngle ) , ..


    Because there is no frame at angle 3
    this wouldn't work.
    So one solution is to render all the angles,
    but this is not needed if there is a way
    to round the angle up or down
    to the nearest 5-angle value.

    I've found a way to do this
    by first scaling a value down,
    making the value lose its significance inbetween the stepsize,
    and then scaling it up again.

; Return angle divided in steps
Function LimitAngle ( Angle , Stepsize )
    Return Int ( Floor ( Float Angle / Stepsize ) ) * Stepsize
End Function


    Now I can use this function anywhere
    by wrapping it around the raw angle.

PlayerAngle = 3
DrawImage PlayerImages( PlayerNumber , LimitAngle ( PlayerAngle ) ) , ..


    Now, if you would merge some of this together in a single program,
    you should get something that looks like a game already 

    I have composed a mix of the above parts
    and some random bits which I have not explained yet
    in Game composition 1.BB,
    located in the Tutorial files index,
    to give you a good (in-game) look at some of the things
    we have dealt with so far.

    The example program also includes:
    - Some funky debugging features,
      to test the gravity effect.
    - Sound effects for thrusting and shooting.
    - An alternate set of tiles.
    - And a new tilemap for testing.

    There are more new parts of code
    that I will explain in the upcoming chapters.

    But if you take a look just at the code structure,
    and particularly the sections of that program,
    you can see that there's a Player section now.

    It contains a bunch of constants,
    a type definition, some global variables
    and a bunch of functions.

    Maybe you have noticed
    that this is just like the Bullets section,
    which we've handled previously.



    Frame limiting

    To make the game run with the same speed on faster computers,
    I'm using Blitz's own CreateTimer and WaitTimer functions.

    In Project Z: Two I have used the 'skipping' approach
    also using only these 2 functions,
    so that the game would run with a similar speed
    on a slower computer as well.

    But because X-NON's code was written
    for a pretty old computer (~200MHz or lower),
    I don't think it will be a problem now 

; Game speed limiter
Global GameTimer

..

; Setup game speed limiter at 60 updates per second
GameTimer = CreateTimer( 60 )

..

Repeat

    ..

    ; Sync game speed
    WaitTimer GameTimer

Until ..


    Looking at the code above,
    the WaitTimer command
    will only slow down the program
    when a particular computer
    executes the main loop faster
    than the specified update frequency.

    For example, take some very simple code
    that moves a dot across the screen.

Graphics 640,480
SetBuffer BackBuffer ()

Local X = 0

Repeat

    X = X + 1
    If X >= 640
        X = 0
    End If

    Plot X,240

    Flip
    Cls

Until KeyHit ( 1 )
End


    Adding the frame limiting code
    would make it run
    with (almost) the same speed
    on computers that are faster
    than the one you created and tested the program on.

    To actually know how fast your game is running,
    try adding some code
    to measure the number of frames rendered
    (or the number of main loop cycles)
    in 1 second.
    E.g. frames per second (fps).

Local fps
Local frames
Local lastsec

..

Repeat

    ..

    frames = frames + 1
    If MilliSecs () >= lastsec + 1000
        lastsec = MilliSecs ()
        fps = frames
        frames = 0
    End If

    Color 255 , 255 , 255
    Text 0 , 0 , fps

    Flip False
    Cls


    Use Flip False to disable vertical sync
    in order to run without any delays.



    Viewpoint

    As you know,
    I'm splitting the screen in two;
    having a left and right side
    for maximum 'squareness'.

    For this to work in the program,
    I'm going to use a technique
    that resembles using a camera.
    In fact, this is nothing more complex
    than using a simple X and Y coordinate.

    So splitting the screen vertically
    would give me something
    like you can see in the following program:

; Screen dimensions (for example)
Const ScreenWidth  = 640
Const ScreenHeight = 480

; Player 1 (left)
Rect 0 , 0 , ScreenWidth/2 , ScreenHeight

; Player 2 (right)
Rect ScreenWidth/2 , 0 , ScreenWidth/2 , ScreenHeight


    In the program I want to keep track
    of both players independently.
    That's why I've chosen to use
    yet another Type structure
    to reference each player.

    For the sake of the camera,
    I can simply use an X and Y
    for each player, like this:

Type Player

    ; Current position
    Field PosX#
    Field PosY#

End Type


    Now I can, for example,
    use each Player pointer
    to reference a player viewpoint.

    I'm going to use an array
    so I can reference each player directly
    as well as via a For..Each.

; ( 1-based player number )
Dim Player.Player( 2 )

; Create the left player in the upper left corner of the screen
Player( 1 ) = New Player
Player( 1 )\PosX = 0
Player( 1 )\PosY = 0

; Create the right player in the upper left corner of the split
Player( 2 ) = New Player
Player( 2 )\PosX = ScreenWidth/2
Player( 2 )\PosY = 0


    The coordinates I'm currently using
    (also in the program above)
    are still screen-based,
    rather than game world-based.

    In Relative positioning in 10 steps I show
    how you can go from 1 coordinate system to another.
    This is also what I'll be doing here.
    Because in the game world
    the coordinates will be different
    from the screen coordinates.

    For example;
    if I have coordinate (0,0) in the game world
    and I want to move the camera (or player) around,
    this coordinate will still be (0,0) in the game world,
    but very different on the screen!

    If you do not fully grasp this concept,
    I highly recommend taking another peek
    at Relative positioning in 10 steps.

    First, as an example,
    I'm going to draw each bullet
    relative to a player's point of view.

    As we already have a Player pointer
    and a DrawBullets function,
    we can tie them together in a snap.

Function DrawBullets ( Orientation.Player )

    ; Something with Orientation\PosX and Orientation\PosY

End Function

..

DrawBullets Player( 1 )
DrawBullets Player( 2 )


    The code above can basically be a template
    for every viewpoint-based drawing function.
    For example for drawing tiles I can use
    the same technique.

    Looking at the original game design
    in each viewpoint the following things
    should be drawn:
    - Players
    - Bullets
    - Tiles

    This means that even a DrawPlayer function
    should use the same approach.
    Though the math involved is quite simple:

Screen = GameWorld - Camera


    In addition, I want to center the camera
    in each viewpoint, e.g.:

; Player 1 (left view)
Rect 0 , 0 , ScreenWidth/2 , ScreenHeight
; View point (left)
Plot ScreenWidth/4 , ScreenHeight/2

; Player 2 (right)
Rect ScreenWidth/2 , 0 , ScreenWidth/2 , ScreenHeight
; View point (right)
Plot ScreenWidth/2 + ScreenWidth/4 , ScreenHeight/2


    To make this really easy and hassle-free,
    I'm going to use the Origin command,
    so if I draw something at (0,0)
    it will be offset to my favorite origin 

; Centered in left view
Origin ScreenWidth/4 , ScreenHeight/2
Plot 0 , 0

; Centered in right view
Origin ScreenWidth/2 + ScreenWidth/4 , ScreenHeight/2
Plot 0 , 0


    In the code above
    I can replace Plot 0 , 0
    with all drawing functions,
    e.g. for the tilemap,
    bullets and players.

    Well, you may be wondering,
    if we're drawing everything on the screen twice,
    for example drawing a tilemap on the left side,
    and then on the right side,
    isn't the tilemap on the right side
    going to overlap the left side?

    Indeed!
    If it wasn't for the ViewPort command,
    I would be pulling my hair out 

; Left player view
; - Limit all drawing operations to this area
ViewPort 0 , 0 , ScreenWidth/2 , ScreenHeight
; - Offset all drawing operations to this (view) point
Origin ScreenWidth/4 , ScreenHeight/2
; .. Drawing functions

; Right player view
; - Limit all drawing operations to this area
ViewPort ScreenWidth/2 , 0 , ScreenWidth/2 , ScreenHeight
; - Offset all drawing operations to this (view) point
Origin ScreenWidth/2 + ScreenWidth/4 , ScreenHeight/2
; .. Drawing functions


    That should be it!

    Later on, you can place the code above directly
    into the main loop in the Main execution section.



    Bullet viewpoint

    So now we can focus on the drawing functions,
    starting with DrawBullets,
    where we left off.

Function DrawBullets ( Orientation.Player )

    ; Something with Orientation\PosX and Orientation\PosY


    Note that, at the moment,
    you can write the above
    also like this:

Function DrawBullets ( OrientationX , OrientationY )

    ; Something with OrientationX and OrientationY


    Which would turn
    a call to DrawBullets
    into this:

DrawBullets Player( 1 )\PosX , Player( 1 )\PosY


    Let us merge the 'camera formula'
    with the drawing goodness:

Screen = GameWorld - Camera


ScreenBullet\PosX = WorldBullet\PosX - Player\PosX
ScreenBullet\PosY = WorldBullet\PosY - Player\PosY


    Take a look at our current DrawBullets function
    and see if you can find the corresponding variables.

Function DrawBullets ()
    Local This.Bullet

    For This = Each Bullet
        DrawImage BulletImage , This\PosX , This\PosY
    Next

End Function


    It looks like
    Player PosX and Player PosY are
    Orientation PosX and Orientation PosY.

    And
    WorldBullet PosX and WorldBullet PosY are
    This PosX and This PosY.

    While
    ScreenBullet PosX and ScreenBullet PosY
    do not have variables associated with them.

    So all that should look like this:

ScreenBullet\PosX = This\PosX - Orientation\PosX
ScreenBullet\PosY = This\PosY - Orientation\PosY


    Adding it to the function..

Function DrawBullets ( Orientation.Player )
    Local This.Bullet

    For This = Each Bullet
        DrawImage BulletImage , This\PosX - Orientation\PosX , This\PosY - Orientation\PosY
    Next

End Function




    Tilemap viewpoint

    Now I can do the same thing
    with the tilemap drawing function.

    In the Tilemap tutorial
    all of the tiles were drawn,
    e.g. also those tiles
    not even visible on the screen.

    To make the drawing tiles function faster,
    I've added an algorithm
    that excludes drawing tiles
    that are not on the screen.

    Actually, in our case,
    the viewport is half of the screen width.
    By viewport I mean the visible area
    of the screen for each player,
    as shown in previous programs.

    The algorithm is in fact the same one
    as I used in the Tilemap tutorial.
    Although, there it was used for collision detection
    but I can use it here also for drawing.

    Both the function definition and function call
    are the same as the DrawBullet function;

Function DrawTilemap ( Orientation.Player )

    ; Something with Orientation\PosX and Orientation\PosY

End Function

..

DrawTilemap Player( 1 )


    Hopping over into the DrawTilemap function,
    I'm gonna add each element of the algorithm
    step by step,
    so you'll recognize it from the Tilemap tutorial,
    which is actually very similar.

    First, the player view orientation,
    which I'm going to store in separate variables,
    so if I need to alter them,
    I only have to do it in 1 location (!),
    which is a little bit like having a Constant
    at the the start of the program
    to reference something by.

Local PosX
Local PosY

..

; Use a relative display position
PosX = Orientation\PosX
PosY = Orientation\PosY


    Ofcourse you can also reference them directly,
    as I have done for DrawBullets.

    So PosX and PosY
    are now the orientation.

    The tilemap should be drawn
    starting from the upperleft corner of the view
    to the lowerright corner of the view.

    Then we can translate (scale) that world coordinate
    to tilemap scale (by division)
    as also explained in Universal scaling revealed
    and the Tilemap tutorial.

Local StartTileX
Local StartTileY

..

; Use top-left of player window as offset
; centering the player in the middle of the window
; taking split screen into account
; Then find the tile that's there at this moment
; Add one tile to overlap the window edge
StartTileX = ( PosX - ScreenWidth /2/2 ) / TileWidth  - 1
StartTileY = ( PosY - ScreenHeight/2   ) / TileHeight - 1


    And basically the same thing
    for the lowerright corner.

Local EndTileX
Local EndTileY

..

; Use the player window size as the range
; again centering the player in the middle
; and taking split screen into account
; Then find the tile that's there at this moment
; Add one tile to overlap the window edge
EndTileX = ( PosX + ScreenWidth /2/2 ) / TileWidth  + 1
EndTileY = ( PosY + ScreenHeight/2   ) / TileHeight + 1


    Imagine flying around in the world,
    and the player's view
    crosses the boundaries of the tilemap.

    Some games forcefully limit the view
    to the boundaries of the tilemap,
    which Gravity Force also does.

    The technique used to accomplish that
    is explained in the final step
    of Relative positioning in 10 steps.

    Personally I prefer the 'unbound' approach
    where you can also flee from the tilemap
    if you wanted to 

    To add this to the DrawTilemap function,
    simply limit the start and end tile variables
    to the tilemap boundaries,
    without making any adjustments
    to the orientation.

; Make sure that the starting and ending tiles
; are not out of tilemap range (edges)
If StartTileX < 0 Then StartTileX = 0
If StartTileY < 0 Then StartTileY = 0
If EndTileX > TilemapWidth -1 Then EndTileX = TilemapWidth -1
If EndTileY > TilemapHeight-1 Then EndTileY = TilemapHeight-1


    Here, the player can fly to the edge of the tilemap
    and will be able to see 'across' it
    which is my intention for this game.

    All that remains now is adding the drawing part,
    with the juicy part being a conversion
    of a tilemap coordinate to a screen coordinate.

Local TileX
Local TileY
Local TilePosX
Local TilePosY
Local FrameNumber

..

; Now go through only those tiles that are within the player's window
For TileX = StartTileX To EndTileX
    For TileY = StartTileY To EndTileY

        TilePosX = TileX * TileWidth  - PosX
        TilePosY = TileY * TileHeight - PosY

        FrameNumber = Tilemap( TileX+1 , TileY+1 )

        DrawImage TileStrip , TilePosX , TilePosY , FrameNumber

    Next
Next


    This routine should draw all tiles to the screen.
    Even 'empty' tiles.

    So I prefer to skip the drawing of 'empty' tiles,
    to, again, speed up the routine,
    and basically, because it's not needed
    to draw tiles that are completely transparent,
    coming from the direction of common sense.

            

    Looking at the tilestrip,
    I have defined the first tile/frame,
    which is frame number 0
    in the DrawImage command,
    as a completely transparent tile.

    Which means simply wrapping the juicy bit
    in an If.

FrameNumber = Tilemap( TileX+1 , TileY+1 )
; Is non-zero
If FrameNumber
    TilePosX = TileX * TileWidth  - PosX
    TilePosY = TileY * TileHeight - PosY

    DrawImage TileStrip , TilePosX , TilePosY , FrameNumber
End If


    To summarize and for clarity,
    here is the combined DrawTilemap function:

Function DrawTilemap ( Orientation.Player )
    Local StartTileX
    Local StartTileY
    Local EndTileX
    Local EndTileY
    Local TileX
    Local TileY
    Local TilePosX
    Local TilePosY
    Local FrameNumber
    Local PosX
    Local PosY

    ; Use a relative display position
    PosX = Orientation\PosX
    PosY = Orientation\PosY

    ; Use top-left of player window as offset
    ; centering the player in the middle of the window
    ; taking split screen into account
    ; Then find the tile that's there at this moment
    ; Add one tile to overlap the window edge
    StartTileX = ( PosX - ScreenWidth /2/2 ) / TileWidth  - 1
    StartTileY = ( PosY - ScreenHeight/2   ) / TileHeight - 1

    ; Use the player window size as the range
    ; again centering the player in the middle
    ; and taking split screen into account
    ; Then find the tile that's there at this moment
    ; Add one tile to overlap the window edge
    EndTileX = ( PosX + ScreenWidth /2/2 ) / TileWidth  + 1
    EndTileY = ( PosY + ScreenHeight/2   ) / TileHeight + 1

    ; Make sure that the starting and ending tiles
    ; are not out of tilemap range (edges)
    If StartTileX < 0 Then StartTileX = 0
    If StartTileY < 0 Then StartTileY = 0
    If EndTileX > TilemapWidth -1 Then EndTileX = TilemapWidth -1
    If EndTileY > TilemapHeight-1 Then EndTileY = TilemapHeight-1

    ; Now go through only those tiles that are within the player's window
    For TileX = StartTileX To EndTileX
        For TileY = StartTileY To EndTileY

            FrameNumber = Tilemap( TileX+1 , TileY+1 )
            ; Is non-zero
            If FrameNumber
                TilePosX = TileX * TileWidth  - PosX
                TilePosY = TileY * TileHeight - PosY

                DrawImage TileStrip , TilePosX , TilePosY , FrameNumber
            End If

        Next
    Next

End Function


    If you're a little confused about
    all of the 0 and 1-based conversions,
    take a look at the lower parts
    of the Tilemap tutorial.

    The DrawTilemap function,
    just like the DrawBullets and DrawPlayer functions,
    can be called straight from the main loop
    in the Main execution section of the code,
    as shown in Structure.



    Player viewpoint

    The last drawing portion that remains
    are the players,
    for which the technique is no different.

    An interesting feature
    of the player drawing function
    is that the drawing angle (image frame)
    is completely independent
    from the actual ship rotation angle.

    So the drawing angle
    is the image frame to draw.

    And the actual ship rotation angle
    can be a field named Angle
    in a Player object.

Type Player
    ..
    ; Current ship angle
    Field Angle#
    ..
End Type


    This technique was previously explained
    in Pre-rendered rotated ship
    if you're wondering what this is about 

    So let's add a DrawPlayers function
    which combines that technique
    as well as the camera viewpoint.

Function DrawPlayers ( Main.Player )
    Local This.Player
    Local PosX
    Local PosY

    For This = Each Player

        ; But it's not the player being drawn
        If This <> Main
            ; Make this player relative to the one being drawn
            PosX = This\PosX - Main\PosX
            PosY = This\PosY - Main\PosY
        ; This player is being drawn
        Else
            ; Center it
            PosX = 0
            PosY = 0
        End If

        ; Limit the angle to increments of 5, starting from 0
        ; to match with the image frames stored in the array
        DrawImage PlayerImages( This\Number , LimitAngle ( This\Angle , 5 ) ) , PosX , PosY

    Next

End Function


    Maybe you have noticed
    that I've added the field Number
    in the Player object,
    which was also used
    in Sound panning
    and Pre-rendered rotated ship.

Type Player
    ..
    ; Unique player number (1 or 2)
    Field Number
    ..
End Type


    Now that we have
    a complete set of drawing functions,
    e.g. DrawPlayers, DrawBullets
    and DrawTilemap,
    we can put them in the main loop,
    e.g. in the Main execution section.

    Let's combine it with the code
    from the Viewpoint chapter,
    to get the full rendering code
    for both players.

; Render game
; - Player 1
ViewPort 0 , 0 , ScreenWidth / 2 , ScreenHeight
Origin ScreenWidth / 4 , ScreenHeight / 2
DrawTilemap Player( 1 )
DrawBullets Player( 1 )
DrawPlayers Player( 1 )

; - Player 2
ViewPort ScreenWidth / 2 , 0 , ScreenWidth / 2 , ScreenHeight
Origin ScreenWidth / 2 + ScreenWidth / 4 , ScreenHeight / 2
DrawTilemap Player( 2 )
DrawBullets Player( 2 )
DrawPlayers Player( 2 )




    Creating a player (ship)

    Previously, we've created an array
    of Player objects.

    This allows you to
    walk through (iterate) the list of players
    both by number (PlayerNumber)
    and by the order of the objects
    using a pointer (For..Each).

    Adding to that,
    I will use both ways
    to reference the players.

    To control each player easily,
    I'm going to create a bunch of functions
    to handle unique parts of the players.

    For example functions
    to create a player object,
    spawn a player ship,
    control a player ship,
    destroy a player ship,
    and so forth.

    These functions can all be placed
    in the Player section
    in the Definition area of the code.

    We can create functions
    in any way we like.
    So I'll add a new function
    when I think it would make the game:
    - clearer and easier to read
    - easier to understand and modify
    as well as:
    - decreasing the amount of code
    - and decreasing the time it takes
      to add features.

    I'll start with a CreatePlayer function
    so we'll have something to work with.

Function CreatePlayer.Player ( PlayerNumber )
    Local This.Player

    This = New Player
    This\Number = PlayerNumber

    ; Center view on tilemap by default
    This\PosX = (TilemapWidth -1) * TileWidth  / 2
    This\PosY = (TilemapHeight-1) * TileHeight / 2

    Return This
End Function

..

; Setup players
Player( 1 ) = CreatePlayer ( 1 )
Player( 2 ) = CreatePlayer ( 2 )


    Setting up the players
    also refers to
    the Player object array:

; ( 1-based player number )
Dim Player.Player( 2 )


    And to summarize,
    here's the Player object,
    which should now include all the new fields
    that I have previously brought into play:

Type Player

    ; Unique player number (1 or 2)
    Field Number

    ; Current ship angle
    Field Angle#
    ; Current ship heading (direction)
    Field Heading#
    ; Current ship speed (velocity)
    Field Speed#

    ; Current position
    Field PosX#
    Field PosY#

End Type


    Maybe you can figure out by now
    which of the above code should be placed in the Player section
    and which should be placed in the Main initialization section,
    as defined in Structure.

    For example the actual creation of the players,
    e.g. when the program is run,
    should occur in the Main initialization section.

    Even the remark Setting up the players is very descriptive,
    in order to figure out where to put the code.



    (Re)spawning the player (ship)

    Looking at the CreatePlayer function,
    when a player (ship) is first created,
    it is put in the center of the tilemap.

    The idea is that when the game starts,
    no players are spawned yet,
    so having the screen focussed
    at the center of the tilemap
    seems like a decent idea.

    Once a player presses the firebutton,
    its ship should be spawned
    at a random spawn spot.

    But if a ship is able to spawn,
    this means that a ship can be dead too.

Type Player
    ..
    ; True or False
    Field Dead
    ..
End Type

..

Function CreatePlayer.Player ( PlayerNumber )
    ..
    This\Dead = True


    Knowing this,
    we can, for example,
    use a RespawnPlayer function,
    which positions the ship
    at a random spawn spot
    and toggles Dead to False.

Function RespawnPlayer ( This.Player )
    Local Here.SpawnSpot
    Local Channel

    ; Find a random spawn spot
    Here = RandomSpawnSpot ()

    ; Convert tilemap scale (array) to pixel scale (world)
    This\PosX = (Here\PosX-1) * TileWidth
    This\PosY = (Here\PosY-1) * TileHeight

    ; Point up and reset speed
    This\Angle = 0
    This\Speed = 0
    This\Heading = 0

    ; Make alive and kicking
    This\Dead = False

    ; Play respawn sound
    Channel = PlaySample ( SpawnSound , 10 )
    ChannelPan Channel , ( This\Number - 1 ) * 2 - 1

End Function


    I've chosen to use an external function
    to place the code for Find a random spawn spot in,
    to increase or maintain readability and reusability.

    That RandomSpawnSpot function
    would return a reference to a spawn spot object
    which I can then use
    to convert its tilemap coordinate
    to a game world coordinate.

    Another interesting thing is the respawn sound.
    I'm using a bunch of Global variables
    to store the sounds in the game,
    just like in Project Z: Two.

; Effects
Global SpawnSound

..

; Load effects
SpawnSound = LoadSound ( "Spawn.WAV" )


    I think grouping the initialization code
    together in one function is a good idea,
    as mentioned in Structure.

    Because then I can place
    the creation of the players
    as well as the loading of the effects
    in such an InitGame function
    to make the code more clear.

    Did you notice that the code to load a sound
    is actually code that can be placed
    in the Main initialization section,
    just like calls to LoadImage?

    Okay, so let's take a look
    at the RandomSpawnSpot function.

    Because we already know the number of spawn spots,
    as they are increased in the LoadTilemap function
    which is described in Spawn spots,
    we can simply pick a random number within that range
    and count up that number of times
    while walking through the list of spawn spots.

; Grab a random spawnspot from the list
Function RandomSpawnSpot.SpawnSpot ()
    Local Number
    Local Times
    Local This.SpawnSpot

    ; Start at the front
    This = First SpawnSpot

    ; Pick a random one using the known number of spawn spots
    Times = Rand ( 0 , SpawnSpots - 1 )

    ; Count until reached target value
    For Number = 1 To Times
        ; Next spawn spot
        This = After This
    Next

    Return This
End Function


    Because we're using random numbers now,
    I'm also adding the following line of code:

; Reset randomizer
; (set number of milliseconds since system boot as randomizer base value)
SeedRnd MilliSecs ()


    For more information about this code
    take a look at Part 6: Variable Collections
    of my Blitz Basic Full Foundation tutorial.

    The random number generator seeding code
    can also be placed in the Main initialization section.



    Player control

    Now that we can (re)spawn a player (ship)
    let's add the ability to control it.

; Player 1 (left)
Const KeyW     =  17
Const KeyA     =  30
Const KeyS     =  31
Const KeyD     =  32

; Player 2 (right)
Const KeyUp    = 200
Const KeyDown  = 208
Const KeyLeft  = 203
Const KeyRight = 205

..

Function PlayersInput ()
    Local Player.Player
    Local Thrust
    Local RotateLeft
    Local RotateRight
    Local Fire

    For Player = Each Player

        Select Player\Number
            Case 1: Thrust      = KeyS
                    RotateLeft  = KeyA
                    RotateRight = KeyD
                    Fire        = KeyW
            Case 2: Thrust      = KeyDown
                    RotateLeft  = KeyLeft
                    RotateRight = KeyRight
                    Fire        = KeyUp
        End Select

        If KeyDown ( Thrust )      Then RespawnPlayer Player
        If KeyDown ( RotateLeft  ) Then RotatePlayerLeft  Player
        If KeyDown ( RotateRight ) Then RotatePlayerRight Player
        If KeyHit  ( Fire        ) Then FirePlayer        Player
    Next

End Function


    This function can be called from the main loop
    in the Main execution section:

; Control both ships
PlayersInput


    Now, both players should have the ability to control their ship.
    The new functions RotatePlayerLeft, RotatePlayerRight and FirePlayer
    should handle what their names suggest 



    Player (ship) thrust

    Maybe you have noticed that something is missing
    in the PlayersInput function
    to fully control a (player) ship.

    I mean, we can respawn, rotate and fire.
    But not thrust!

    Wait a minute..
    That also means we need a thrust sound playing for each player,
    which should be audible when the ship thrusts,
    and stop playing when the ship stops thrusting (or dies).

    Let's add that first.

Global ThrustSound

..

ThrustSound = LoadSound ( "Thrust.WAV" )
LoopSound ThrustSound


    As each player has the ability to thrust,
    it should also be audible individually,
    using the left/right stereo panning.

Type Player
    ..
    ; Request to thrust ship
    Field Thrusting
    ; Sound channel handle
    Field ThrustChannel
    ..
End Type


    The Thrusting field controls
    the 'request to thrust'
    as I'm going to use another function
    to handle the physics for the ships
    in which I will then be able to know
    when the player has pressed the Thrust key.

    The ThrustChannel field
    should be set to the ThrustSound playing,
    which should start playing, like,
    when the Player is created.

    So I'm adding the following code
    to the CreatePlayer function:

; Prepare thrust sound
This\ThrustChannel = PlaySound ( ThrustSound )
PauseChannel This\ThrustChannel
ChannelPan This\ThrustChannel , ( PlayerNumber - 1 ) * 2 - 1


    This is the pointer to the Player object.
    I'm pausing the sound right after starting it,
    because it should be audible
    only when the ship thrusts.

    If you're unfamiliar with (some of) this code,
    take a look at Thrust sound
    and Sound panning.

    Now we can thrust audibly
    by simply calling ResumeChannel
    which should take place
    in the PlayersInput function.

    When the ship is not dead,
    and the player presses the Thrust key,
    the ship should be respawned.

    But when the ship is dead,
    and the player presses the Thrust key,
    the ship should thrust instead.

    We can expand the Thrust key If
    in the PlayersInput function
    so that it reflects these new things.

If KeyDown ( Thrust )
    If Player\Dead
        RespawnPlayer Player
    Else
        Player\Thrusting = True
        ; Play thrust sound
        ResumeChannel Player\ThrustChannel
    End If
Else
    ; Stop thrust sound
    PauseChannel Player\ThrustChannel
End If


    You could also, for example,
    instead of pausing the sound,
    set its volume to 0.0 (silent)
    using ChannelVolume.

    And resume it again
    by calling ChannelVolume
    with full volume, e.g. 1.0.



    Rotating a player (ship)

    Let's move on to the functions
    that rotate a ship.

; Player (ship) rotation speed in degrees
Const RotateSpeed#   =    4

..

Function RotatePlayerLeft ( This.Player )

    If Not This\Dead
        This\Angle = This\Angle - RotateSpeed
        If This\Angle < 0 Then This\Angle = This\Angle + 360
    End If

End Function

..

Function RotatePlayerRight ( This.Player )

    If Not This\Dead
        This\Angle = This\Angle + RotateSpeed
        If This\Angle >= 360 Then This\Angle = This\Angle - 360
    End If

End Function


    Very straight forward stuff.
    Can't rotate when dead.
    And limit the angle to [0..360].

    The RotateSpeed constant
    is open for tweaking 



    Player (ship) fire

    Onto the FirePlayer function,
    which should create a bullet
    from the tip of the ship image
    flying in the ship's direction.

    Even though the function name
    suggests something different 

    The algorithm to calculate all of this
    is almost identical to the one
    used in Project Z: Two.

    We can use the code
    from the Bullets chapter
    with only a few changes.

Global FireSound

..

FireSound = LoadSound ( "Fire.WAV" )

..

Function FirePlayer ( This.Player )
    Local PosX
    Local PosY
    Local VelX#
    Local VelY#
    Local Channel

    If Not This\Dead
        ; Calculate where to create bullet in front of ship
        PosX = This\PosX + VectorX ( BulletDistance , This\Angle )
        PosY = This\PosY + VectorY ( BulletDistance , This\Angle )

        ; Initial bullet velocity vector
        VelX = VectorX ( BulletSpeed , This\Angle )
        VelY = VectorY ( BulletSpeed , This\Angle )

        ; Add player velocity vector to bullet velocity vector (realism)
        VelX = VelX + VectorX ( This\Speed , This\Heading )
        VelY = VelY + VectorY ( This\Speed , This\Heading )

        CreateBullet PosX , PosY , VelX , VelY

        ; Play fire sound
        Channel = PlaySample ( FireSound , 10 )
        ChannelPan Channel , ( This\Number - 1 ) * 2 - 1
    End If

End Function


    The realistic (versus the unrealistic) bullet physics
    are also described in Project Z: Two.
    Do a search for PlayerFireBullet.



    Kill a player (ship)

    You may have noticed that almost every player function
    contains a check to see if the ship is alive.

    The DrawPlayers function is still missing that check!

..

For This = Each Player

    ; Player is dead
    If Not This\Dead

        ..


    Just to make sure we're not drawing any dead players (or ships).

    Talking about dead ships,
    let's make it so.

Global ExplodeSound

..

ExplodeSound = LoadSound ( "Explode.WAV" )

..

Function KillPlayer ( This.Player )
    Local Channel

    This\Dead = True

    ; Stop thrust sound
    PauseChannel This\ThrustChannel

    ; Create a bunch of shrapnel pieces in random directions
    CreateBulletRay This\PosX , This\PosY

    ; Play explode sound
    Channel = PlaySample ( ExplodeSound , 50 )
    ChannelPan Channel , ( This\Number - 1 ) * 2 - 1

End Function


    In case the Thrust sound is still playing, pause it.
    Also play a special explosion sound.
    And create a ray of bullets,
    as in the original design (Specification).

    The CreateBulletRay function
    does almost exactly the same thing
    as the SpawnShrapnel function
    in Project Z: Two.

Function CreateBulletRay ( InitialPosX , InitialPosY , InitialVelX# = 0 , InitialVelY# = 0 )
    Local Angle
    Local RandomAngle
    Local VelX#
    Local VelY#
    Local PosX#
    Local PosY#

    ; Divide 360 degrees in sections of 5 degrees
    For Angle = 0 To 360 Step 360/5

        ; Then choose a random angle inside that peace of pie
        RandomAngle = Angle + Rand ( 360/5 )

        ; Velocity: use half of bullet speed plus the initial speed (optional)
        VelX = InitialVelX + VectorX ( BulletSpeed / 2 , RandomAngle )
        VelY = InitialVelY + VectorY ( BulletSpeed / 2 , RandomAngle )

        ; Position: use half of ship tip distance plus the offset position
        PosX = InitialPosX + VectorX ( BulletDistance / 2 , RandomAngle )
        PosY = InitialPosY + VectorY ( BulletDistance / 2 , RandomAngle )

        ; Finally create it, but it's not a normal bullet
        CreateBullet PosX , PosY , VelX , VelY , False
    Next

End Function


    The main difference is that
    here I'm not creating the bullets from
    (or on) a single point.

    Instead, I'm creating them in a circle
    a little bit away from that single point
    right from the start.

    This gives the impression of an explosion
    without the use of an explosion image.

    Something else is different,
    being the call to CreateBullet.
    There's a new (5th) parameter!

    This is because I want a bullet ray
    to consist of bullets that each stay alive
    for a random amount of time.

    Or at least a little more random
    than normal bullets,
    which adds a little more
    'explosionness' to it.

    Here is the difference:

Function CreateBullet ( PosX , PosY , VelX# , VelY# , NormalBullet = True )

    ..

    This\TimeCreated = MilliSecs

    ; Bullet
    If NormalBullet

        ; Use default time to live
        This\TimeToLive = BulletTime

    ; Shrapnel
    Else

        ; Use slightly randomized default time to live
        This\TimeToLive = BulletTime / 2 + Rand ( BulletTime )

    End If

End Function




    Updating a player (ship)

    All that remains now
    is a function to handle the juicy bit of the ship's motion,
    a.k.a. the ship's "Asteroids" physics,
    also explained above in Ship "Asteroids" physics.

    We can also add the gravity here,
    which we used in Ship gravity,
    which is also very open for tweaking 

; Player (ship) thrust speed in pixels
Const ThrustSpeed#   =    0.12

; Player (ship) maximum velocity in pixels
Const MaxSpeed       =    5

; Downward gravity strength in pixels (on ship)
Const GravityPull#   =    0.03

..

Function UpdatePlayer ( This.Player )
    Local ThrustX#
    Local ThrustY#
    Local SpeedX#
    Local SpeedY#

    If Not This\Dead
        If This\Thrusting
            This\Thrusting = False

            ; Thrust vector
            ThrustX = VectorX ( ThrustSpeed , This\Angle )
            ThrustY = VectorY ( ThrustSpeed , This\Angle )
        Else
            ThrustX = 0
            ThrustY = 0
        End If

        ; Thrust vector + old velocity vector = new velocity vector
        SpeedX = VectorX ( This\Speed , This\Heading ) + ThrustX
        SpeedY = VectorY ( This\Speed , This\Heading ) + ThrustY

        ; Add gravity vector to velocity vector (180 degrees = down)
        SpeedX = SpeedX + VectorX ( GravityPull , 180 )
        SpeedY = SpeedY + VectorY ( GravityPull , 180 )

        ; Update speed and heading with new velocity vector
        This\Speed = VectorDistance ( SpeedX , SpeedY )
        This\Heading = VectorAngle ( SpeedX , SpeedY )

        ; Limit velocity (speed of ship)
        If This\Speed > MaxSpeed
            This\Speed = MaxSpeed

            ; Recalculate limited velocity vector
            SpeedX = VectorX ( This\Speed , This\Heading )
            SpeedY = VectorY ( This\Speed , This\Heading )
        End If

        ; Update position with velocity vector
        This\PosX = This\PosX + SpeedX
        This\PosY = This\PosY + SpeedY

    End If

End Function


    If any of the above code is unclear,
    please refer to the chapter references above
    or the Knowledge reference.

    The UpdatePlayer function,
    just like the UpdateBullets function,
    can be called from the main loop
    in the Main execution section,
    as you can see in Structure.

; Update game
UpdatePlayer Player( 1 )
UpdatePlayer Player( 2 )
UpdateBullets




    Music

    For the music I liked creating a cover of the original Gravity Force tune
    so I have a cool MP3 track now that I can put into play.

; Soundtrack
Global GameMusic

; Background music channel handle
Global MusicChannel

..

; Load and play music
GameMusic = LoadSound ( "TheChance - Gravity Force.MP3" )
LoopSound GameMusic
MusicChannel = PlaySound ( GameMusic )
; - At half volume, to put it in the background
ChannelVolume MusicChannel , 0.5


    The reason I did not use PlayMusic
    is because I found it to be
    a little buggy for some tracks,
    and less controllable as well.

    I would place the above code
    very early in the program,
    in the Main initialization section,
    to be able to enjoy listening to the music
    as soon as possible 



    (Media) file locations

    After a while
    the amount of external files for the game
    started to become significant,
    and a little organization
    would improve my oversight.

    So, I've created a bunch of (sub-)folders
    to store all the (media) files in,
    like Audio, Tilemaps and Graphics.

    But in the code,
    every call to LoadImage,
    LoadSound and LoadTilemap
    still use the old (root) location,
    e.g. the same place
    where the source code file
    X-NON.BB
    is stored.

    By adding a bunch of constants
    corresponding to the bunch of folders,
    I'll never have to worry
    about this again 

; Locations of external files
Const AudioFolder$  = "Audio\"
Const GraphicsFolder$ = "Graphics\"
Const TilemapsFolder$ = "Tilemaps\"


    For example,
    the music code would,
    after transformation,
    look like this:

GameMusic = LoadSound ( AudioFolder + "TheChance - Gravity Force.MP3" )


    Another example,
    the rotated player ship images:

PlayerImages( PlayerNumber , Angle ) =
    LoadImage ( GraphicsFolder + "Ships\" + "Ship " + PlayerNumber + " - " + Angle + ".BMP" )


    So these ship images
    are actually in a sub-folder
    of the GraphicsFolder now.



    Ship vs ship collision

    As described in the design Specification,
    we need to check for 4 types of collisions:
    - Ship vs Ship: Kill both
    - Bullet vs Ship: Kill both
    - Tilemap vs Ship: Kill ship
    - Tilemap vs Bullet: Kill bullet

    Let's start with Ship vs Ship,
    as that's probably the easiest one.

    The first condition
    is that both player have to be alive:

; Both players must be alive
If ( Not Player( 1 )\Dead ) And ( Not Player( 2 )\Dead )


    Then we need the images of each player
    for a pixel-perfect collision check,
    which we can just grab
    from the DrawPlayers code.

Local PlayerImg1
Local PlayerImg2

..

PlayerImg1 = PlayerImages( 1 , LimitAngle ( Player( 1 )\Angle , 5 ) )
PlayerImg2 = PlayerImages( 2 , LimitAngle ( Player( 2 )\Angle , 5 ) )


    We can first perform an ImagesOverlap check
    to see if the players are actually near each other,
    which speeds up the collision checking considerably.

If ImagesOverlap ( PlayerImg1 , Player( 1 )\PosX , Player( 1 )\PosY ,
                   PlayerImg2 , Player( 2 )\PosX , Player( 2 )\PosY )


    Followed by ImagesCollide,
    including the number
    of the first frame in the image (e.g. 0).

If ImagesCollide ( PlayerImg1 , Player( 1 )\PosX , Player( 1 )\PosY , 0 ,
                   PlayerImg2 , Player( 2 )\PosX , Player( 2 )\PosY , 0 )


    Finally both (player) ships should perish
    in the occurence of a fatal clash.
    E.g. kill the ship if the images collide.

; And kill them if so
KillPlayer Player( 1 )
KillPlayer Player( 2 )


    Putting it all together
    would give us this:

Function PlayerCollideWithPlayer ()
    Local PlayerImg1
    Local PlayerImg2

    ; Both players must be alive
    If ( Not Player( 1 )\Dead ) And ( Not Player( 2 )\Dead )

        PlayerImg1 = PlayerImages( 1 , LimitAngle ( Player( 1 )\Angle , 5 ) )
        PlayerImg2 = PlayerImages( 2 , LimitAngle ( Player( 2 )\Angle , 5 ) )

        If ImagesOverlap ( PlayerImg1 , Player( 1 )\PosX , Player( 1 )\PosY ,
                           PlayerImg2 , Player( 2 )\PosX , Player( 2 )\PosY )
            If ImagesCollide ( PlayerImg1 , Player( 1 )\PosX , Player( 1 )\PosY , 0 ,
                               PlayerImg2 , Player( 2 )\PosX , Player( 2 )\PosY , 0 )
                ; And kill them if so
                KillPlayer Player( 1 )
                KillPlayer Player( 2 )
            End If
        End If
    End If

End Function


    Calling this function,
    as well as any other collision functions,
    would happen somewhere in the main loop
    in the Main execution section
    of the final program.



    Ship vs bullet collision

    The ship vs bullet collision routine is probably a little bit harder,
    because both ships have to be compared
    with every bullet in existence.

    Even though this collision routine
    is a lot easier than the one
    used in Project Z: Two,
    it is identical in nature.

    Let's start by adding a For..Each loop
    for each player ship,
    checking if it is actually alive,
    and grabbing the rotation image to check.

Local Player.Player
Local PlayerImg

..

For Player = Each Player

    If Not Player\Dead

        PlayerImg = PlayerImages( Player\Number , LimitAngle ( Player\Angle , 5 ) )


    I prefer putting the player in the outer loop,
    although you can put it in the inner loop as well,
    if you want to 

    Because now I'm adding a similar loop for each bullet
    right below the previous code,
    directly followed by the image collision checks,
    just like in the ship to ship collision routine.

    Only now, using the BulletImage.

Local This.Bullet

..

For This = Each Bullet

    If ImagesOverlap ( PlayerImg , Player\PosX , Player\PosY ,
                       BulletImage , This\PosX , This\PosY )
        If ImagesCollide ( PlayerImg , Player\PosX , Player\PosY , 0 ,
                           BulletImage , This\PosX , This\PosY , 0 )


    When the images collide,
    again, both the bullet and the (player) ship
    should be killed.

Delete This
KillPlayer Player
; This player is dead, don't check for any more bullets
Exit


    If a collision occurs,
    the routine should exit the inner (bullet) loop immediately
    because the current player in the outer loop
    isn't alive anymore anyway.

    To summarize,
    here is the full routine:

Function PlayersCollideWithBullets ()
    Local Player.Player
    Local This.Bullet
    Local PlayerImg

    For Player = Each Player

        If Not Player\Dead

            PlayerImg = PlayerImages( Player\Number , LimitAngle ( Player\Angle , 5 ) )

            For This = Each Bullet

                If ImagesOverlap ( PlayerImg , Player\PosX , Player\PosY ,
                                   BulletImage , This\PosX , This\PosY )
                    If ImagesCollide ( PlayerImg , Player\PosX , Player\PosY , 0 ,
                                       BulletImage , This\PosX , This\PosY , 0 )

                        Delete This
                        KillPlayer Player
                        ; This player is dead, don't check for any more bullets
                        Exit

                    End If
                End If

            Next

        End If

    Next

End Function




    Tilemap vs ship collision

    This tilemap vs ship collision routine
    will, again, be very much like the collision detection algorithm
    explained in the Tilemap tutorial.

    It is also very similar to our DrawTilemap function,
    so you'll probably recognize most (if not all) of it.

    I'm gonna start it
    in exactly the same way
    as the previous collision function.

Local Player.Player
Local PlayerImg

..

For Player = Each Player

    If Not Player\Dead

        PlayerImg = PlayerImages( Player\Number , LimitAngle ( Player\Angle , 5 ) )


    To check the player position with the tilemap
    I'm changing the scale
    from game world to tile map.

    Because the player ship
    is near the size of a single tile,
    I can do a check with all adjacent tiles,
    e.g. the tiles right next to
    the tile under the player.

    This results in a 3x3 block of tiles
    under the player position.

Local TileX
Local TileY
Local StartTileX
Local StartTileY
Local EndTileX
Local EndTileY

..

; Tile under player
TileX = Player\PosX / TileWidth
TileY = Player\PosY / TileHeight

; 3x3 tile block under player
StartTileX = TileX - 1
StartTileY = TileY - 1
EndTileX = TileX + 1
EndTileY = TileY + 1


    Adding some boundary checking,
    in case the ship goes off the tilemap,
    or near the tilemap's boundaries.

; Limit to edges of tilemap
If StartTileX < 0 Then StartTileX = 0
If StartTileY < 0 Then StartTileY = 0
If EndTileX > TilemapWidth -1 Then EndTileX = TilemapWidth -1
If EndTileY > TilemapHeight-1 Then EndTileY = TilemapHeight-1


    Now it's just a matter of
    walking through the 3x3 block of tiles.

    Also, I only want to check with tiles
    that are not empty,
    so I'll check only tiles that have a non-zero value.

For TileX = StartTileX To EndTileX
    For TileY = StartTileY To EndTileY

        ; Is non-zero
        If Tilemap( TileX+1 , TileY+1 )


    Now I'm gonna scale the tile position
    back to world coordinates,
    so I can perform image checks.

    Same as before,
    starting with ImagesOverlap,
    followed by ImagesCollide.

    Only this time,
    using the player ship image
    and the TileStrip,
    along with the image frames
    contained within the TileStrip.

Local TilePosX
Local TilePosY

..

TilePosX = TileX * TileWidth
TilePosY = TileY * TileHeight

If ImagesOverlap ( PlayerImg , Player\PosX , Player\PosY ,
                   TileStrip , TilePosX , TilePosY )
    If ImagesCollide ( PlayerImg , Player\PosX , Player\PosY , 0 ,
                       TileStrip , TilePosX , TilePosY , Tilemap( TileX+1 , TileY+1 ) )


    When the images collide,
    just the player ship should be killed.
    No disappearing tiles or anything 

KillPlayer Player


    Putting it all together:

Function PlayersCollideWithTilemap ()
    Local Player.Player
    Local TileX
    Local TileY
    Local StartTileX
    Local StartTileY
    Local EndTileX
    Local EndTileY
    Local TilePosX
    Local TilePosY
    Local PlayerImg

    For Player = Each Player

        If Not Player\Dead

            PlayerImg = PlayerImages( Player\Number , LimitAngle ( Player\Angle , 5 ) )

            ; Tile under player
            TileX = Player\PosX / TileWidth
            TileY = Player\PosY / TileHeight

            ; 3x3 tile block under player
            StartTileX = TileX - 1
            StartTileY = TileY - 1
            EndTileX = TileX + 1
            EndTileY = TileY + 1

            ; Limit to edges of tilemap
            If StartTileX < 0 Then StartTileX = 0
            If StartTileY < 0 Then StartTileY = 0
            If EndTileX > TilemapWidth -1 Then EndTileX = TilemapWidth -1
            If EndTileY > TilemapHeight-1 Then EndTileY = TilemapHeight-1

            For TileX = StartTileX To EndTileX
                For TileY = StartTileY To EndTileY

                    ; Is non-zero
                    If Tilemap( TileX+1 , TileY+1 )
                        TilePosX = TileX * TileWidth
                        TilePosY = TileY * TileHeight

                        If ImagesOverlap ( PlayerImg , Player\PosX , Player\PosY ,
                                           TileStrip , TilePosX , TilePosY )
                            If ImagesCollide ( PlayerImg , Player\PosX , Player\PosY , 0 ,
                                               TileStrip , TilePosX , TilePosY , Tilemap( TileX+1 , TileY+1 ) )

                                KillPlayer Player

                            End If
                        End If
                    End If

                Next
            Next

        End If

    Next

End Function




    Tilemap vs bullet collision

    Well, this should be a snap,
    as the tilemap vs bullet collision routine
    is almost identical
    to the tilemap vs ship collision routine.

    First we can
    simply replace all player things
    with bullet things.

    I'll show the changes
    that I've made:

Local This.Bullet

..

For This = Each Bullet

    TileX = This\PosX / TileWidth
    TileY = This\PosY / TileHeight

..

If ImagesOverlap ( BulletImage , This\PosX , This\PosY ,
                   TileStrip , TilePosX , TilePosY )
    If ImagesCollide ( BulletImage , This\PosX , This\PosY , 0 ,
                       TileStrip , TilePosX , TilePosY , Tilemap( TileX+1 , TileY+1 ) )

        Delete This


    So far so good.
    The bullet should disappear
    on tile-impact.

    But looking at the place in the code
    where the bullet gets deleted,
    I see that the object
    that This refers to,
    no longer exists in the inner loop.

    So the next time
    the contents of This is checked,
    Blitz would crash,
    unless we exit the inner loop
    just like before.

    Because there are now 2 inner loops
    inside of the bullet loop,
    we can use a variable
    to guide us out.

Local ExitLoops


    So when the inner loops start:

ExitLoops = False


    And when we delete the bullet:

ExitLoops = True
Exit


    Exit would exit the first inner loop (TileY).
    So at the bottom of the TileX loop:

    Next  ; TileY

    If ExitLoops Then Exit

Next  ; TileX


    This should carry us safely
    through the nested loops.

    To spice up the game
    just a little more,
    I want to add a sound
    when a bullet hits a tile.

    So where the bullet is deleted,
    I add another line:

; Play collide sound
PlaySample CollideSound , 50


    Finally placing the Audio definition:

Global CollideSound


    And Main initialization code:

CollideSound = LoadSound ( AudioFolder + "Collide.WAV" )


    For extra clarity,
    here's the combined function:

Function BulletsCollideWithTilemap ()
    Local This.Bullet
    Local TileX
    Local TileY
    Local StartTileX
    Local StartTileY
    Local EndTileX
    Local EndTileY
    Local TilePosX
    Local TilePosY
    Local ExitLoops

    For This = Each Bullet

        TileX = This\PosX / TileWidth
        TileY = This\PosY / TileHeight

        StartTileX = TileX - 1
        StartTileY = TileY - 1
        EndTileX = TileX + 1
        EndTileY = TileY + 1

        If StartTileX < 0 Then StartTileX = 0
        If StartTileY < 0 Then StartTileY = 0
        If EndTileX > TilemapWidth -1 Then EndTileX = TilemapWidth -1
        If EndTileY > TilemapHeight-1 Then EndTileY = TilemapHeight-1

        ExitLoops = False
        For TileX = StartTileX To EndTileX
            For TileY = StartTileY To EndTileY

                ; Is non-zero
                If Tilemap( TileX+1 , TileY+1 )
                    TilePosX = TileX * TileWidth
                    TilePosY = TileY * TileHeight

                    If ImagesOverlap ( BulletImage , This\PosX , This\PosY ,
                                       TileStrip , TilePosX , TilePosY )
                        If ImagesCollide ( BulletImage , This\PosX , This\PosY , 0 ,
                                           TileStrip , TilePosX , TilePosY , Tilemap( TileX+1 , TileY+1 ) )

                            Delete This
                            ; Play collide sound
                            PlaySample CollideSound , 50

                            ExitLoops = True
                            Exit

                        End If
                    End If
                End If

            Next
            If ExitLoops Then Exit
        Next

    Next

End Function


    So now we have 4 collision functions
    which we can stick in the main loop:

; Collisions
PlayerCollideWithPlayer
PlayersCollideWithTilemap
PlayersCollideWithBullets
BulletsCollideWithTilemap




    Game control

    Let's take a look at the game flow
    we have at the moment.
    And compare that
    with the original design Specification.

    When the game starts,
    players are created,
    but not spawned yet.

    Once a player presses
    the fire button,
    its ship is spawned,
    and can fly it around.

    Once the ship dies,
    a ray of bullets is spawned,
    the ship disappears,
    and the player can press the fire button again
    to repeat the process.

    So it appears that
    everything is in place!

    Before summarizing the main loop,
    I'm going to add a simple Pause feature.

    First, a definition for the Miscellaneous section,
    which I've sneakily smuggled in 
    Followed by the value's initialization
    to be placed in the Main initialization section.

; Game states
Global GamePaused

..

; Set default game states
GamePaused = False


    Let's pick the 'P' key to Pause the game,
    and add Esc as the quit key
    while we're at it.

; Game control
Const KeyP     =  25
Const KeyEsc   =   1


    I'm putting that
    in the Miscellaneous section
    as well.

    And this is some new code
    for in the main loop:

If KeyHit ( KeyP )
    GamePaused = Not GamePaused
End If

..

Until KeyHit ( KeyEsc )


    While the game is paused,
    none of the objects should be updated,
    no collisions should occur,
    and the ships should no longer
    receive input from the player.

    So this affects the input functions,
    the object update functions
    and the collision functions.

    Simply wrapping them up
    should do the trick.

If Not GamePaused
    ; Control both ships
    PlayersInput

    ; Update game
    UpdatePlayer Player( 1 )
    UpdatePlayer Player( 2 )
    UpdateBullets

    ; Collisions
    PlayerCollideWithPlayer
    PlayersCollideWithTilemap
    PlayersCollideWithBullets
    BulletsCollideWithTilemap
End If


    After having added all of the previous bits of code,
    the game's main loop will look like this:

; Main loop
Repeat

    ; Sync time
    MilliSecs = MilliSecs ()

    If KeyHit ( KeyP )
        GamePaused = Not GamePaused
    End If

    If Not GamePaused
        ; Control both ships
        PlayersInput

        ; Update game
        UpdatePlayer Player( 1 )
        UpdatePlayer Player( 2 )
        UpdateBullets

        ; Collisions
        PlayerCollideWithPlayer
        PlayersCollideWithTilemap
        PlayersCollideWithBullets
        BulletsCollideWithTilemap
    End If

    ; Render game
    ; - Player 1
    ViewPort 0 , 0 , ScreenWidth / 2 , ScreenHeight
    Origin ScreenWidth / 4 , ScreenHeight / 2
    DrawTilemap Player( 1 )
    DrawBullets Player( 1 )
    DrawPlayers Player( 1 )

    ; - Player 2
    ViewPort ScreenWidth / 2 , 0 , ScreenWidth / 2 , ScreenHeight
    Origin ScreenWidth / 2 + ScreenWidth / 4 , ScreenHeight / 2
    DrawTilemap Player( 2 )
    DrawBullets Player( 2 )
    DrawPlayers Player( 2 )

    ; - Screen
    Viewport 0 , 0 , ScreenWidth , ScreenHeight
    Origin 0 , 0
    Color 0 , 0 , 0
    Rect ScreenWidth/2 , 0 , 1 , ScreenHeight
    Flip
    Cls

    ; Sync game speed
    WaitTimer GameTimer

Until KeyHit ( KeyEsc )

; Blitz cleans up
End


    I've also added a vertical line in the center
    to add extra accent to the view limits.

    Note that the order of the things in the main loop
    can seriously affect the working of the game.

    That's why I prefer to stick
    to one particular order
    in most of my programs,
    which looks like this:

     Time related
     Input related
     Objects related
     Rendering related

    Here are some examples
    for each of these.

    Time related examples:
    - Set MilliSecs to MilliSecs().
    - Calculate the number of Frames Per Second.

    Input related examples:
    - Call PlayersInput().
    - Pause or unpause the game.

    Object related examples:
    - Update the player ships.
    - Handle physics.
    - Collision detection.

    Rendering related examples:
    - Set viewports.
    - Draw backgrounds and objects.

    Sometimes parts that are rendering related
    can also be time related,
    like WaitTimer in the main loop.
    
    So for me it makes sense
    because from a run-time point of view
    the time related section is executed
    right after the rendering related section.

    Feel free to experiment! 



    Fixing bugs

    While expanding the code,
    I've noticed a few bugs (or features ).


     The 'pause game'-bug

    When you fly around shooting,
    and suddenly pause the game,
    wait for a little bit,
    and unpause the game again,
    bullets will be gone instantly.

    This is because MilliSecs()
    is not paused when the game is paused.

    This can be fixed for example
    by adding the duration of the Pause
    to the value of the TimeCreated field
    in every Bullet object.

Global PauseStart

..

If KeyHit ( KeyP )
    If Not GamePaused
        PauseStart = MilliSecs
    Else
        BulletTime MilliSecs - PauseStart
    End If
    GamePaused = Not GamePaused
End If

..

Function BulletTime ( TimeShift )
    Local This.Bullet

    For This = Each Bullet

        This\TimeCreated = This\TimeCreated + TimeShift
    Next

End Function


    I have not added this to the final game,
    so I'll leave it up to you to test it
    to see if it actually works 


     Input buffer bugs

    Sometimes when you press keys (like Esc)
    while the game is being paused,
    it will cause havoc (like instant quit)
    once the game is unpaused.

    I like fixing these particular bugs
    by placing a FlushKeys
    right after unpausing the game.

If KeyHit ( KeyP )
    GamePaused = Not GamePaused
    FlushKeys  ; Forget pressed keys
End If


    The same goes for
    having finished loading up the game,
    at the end of the InitGame function.

; Clear any pressed keys
FlushKeys


    E.g. no sudden and instant quits after loading
    until the game has actually finished loading.


     Superfast respawn

    When your ship crashes,
    you can instantly press the Thrust/Respawn key again
    to instantly respawn at a new spawn spot.

    I feel this is a little too flexible for this game,
    especially in the middle of a dogfight!

    So I've decided to add some code to prevent
    a player from respawning its ship
    for a certain amount of time
    after having crashed.

    So this would affect
    the RespawnPlayer
    and KillPlayer functions.

    Similar to a PauseStart global variable
    I'll need to keep track of the time
    the player crashed.

    But here,
    both players can crash,
    so I'll add another field
    to the Player object.

Type Player

    ..

    ; Time of death
    Field DiedWhen


    Now I can set the 'time of death'
    when the ship crashes,
    e.g. in the KillPlayer function.

Function KillPlayer ( This.Player )

    ..

    This\DiedWhen = MilliSecs


    Then, in the RespawnPlayer function,
    I can check if the time to wait has elapsed.

    Let's make the 'time for forced meditation' 2 seconds.

Function RespawnPlayer ( This.Player )

    ..

    ; How much time to wait (in ms) before being able to spawn after dying
    If MilliSecs - This\DiedWhen >= 2000


    This value is open for tweaking 
    And could also have been placed
    in the Definition area of the code
    using a Constant.

    Specifically these 2 seconds allow
    for the 'forced' display
    of the nice explosion effect
    when a ship crashes.


     Spawn-crashing

    Imagine both players spawning simultaneously.
    The game will spawn both players regardless,
    and at a completely random spawn spot.

    This means that sometimes
    you can spawn exactly where the other player already is!

    One way to fix this is for example
    by remembering the last spawn spot used,
    or creating a list of randomized spawn spots.

    But I've chosen a different approach,
    which also works when having just 1 spawn spot.

    I'm going to check for a collision
    before actually spawning the player.

    This means that I would have to put
    a call to PlayerCollideWithPlayer
    inside the RespawnPlayer function (!).

    PlayerCollideWithPlayer currently takes into account
    the occurence of both players being dead already,
    so I have to modify it first.

    But it is already being used
    for normal collision detection
    in the main loop.

    So I will duplicate the function,
    while being able to re-use existing code
    and keeping full backward-compatibility
    with the current collision detection.

Function PlayerCollideWithPlayer ()

    ; Both players must be alive
    If ( Not Player( 1 )\Dead ) And ( Not Player( 2 )\Dead )
        ; Then see if they collide
        If PlayersCollide ()
            ; And kill them if so
            KillPlayer Player( 1 )
            KillPlayer Player( 2 )
        End If
    End If

End Function


    The effect of the PlayerCollideWithPlayer function
    is seemingly still the same,
    as I have just moved the actual collision check
    to the new PlayersCollide function.

Function PlayersCollide ()
    Local PlayerImg1
    Local PlayerImg2

    PlayerImg1 = PlayerImages( 1 , LimitAngle ( Player( 1 )\Angle , 5 ) )
    PlayerImg2 = PlayerImages( 2 , LimitAngle ( Player( 2 )\Angle , 5 ) )

    If ImagesOverlap ( PlayerImg1 , Player( 1 )\PosX , Player( 1 )\PosY ,
                       PlayerImg2 , Player( 2 )\PosX , Player( 2 )\PosY )
        If ImagesCollide ( PlayerImg1 , Player( 1 )\PosX , Player( 1 )\PosY , 0 ,
                           PlayerImg2 , Player( 2 )\PosX , Player( 2 )\PosY , 0 )
            Return True
        End If
    End If

End Function


    There's actually no really new code.
    Only the extraction of the collision detection
    into a new function.

    Now the idea is to allow respawn only if:
    - Both players are dead.
    - One player is dead and there's no collision.

    The first juicy bit that would go into RespawnPlayer
    is nearly the same bit as in the PlayerCollideWithPlayer function.

Function RespawnPlayer ( This.Player )

    ..

    Local Respawn

    ..

    ; Prevent spawning over another player, if a player is alive
    If ( Not Player( 1 )\Dead ) Or ( Not Player( 2 )\Dead )
        If Not PlayersCollide ()
            Respawn = True
        End If
    Else
        Respawn = True
    End If


    Only the And has changed into Or,
    to alter the conditions (to respawn).

    I'm also using a local variable named Respawn
    to keep most of the existing code intact,
    and to increase the clarity of the code.

    Finally wrapping the resurrection code
    in the conditional Respawn sauce.

If Respawn
    ; Make alive and kicking
    This\Dead = False


    I'm leaving most of the existing code intact,
    like the adjustment of the (player) ship position
    to the new (random) location of a spawn spot
    when you press the Respawn button.

    So if a (re)spawn fails,
    the camera viewpoint is altered anyway,
    and you can instantly see 'the reason'
    for not being able to spawn.



    Background image

    After playing the game some more,
    it seemed to me that the plain black background
    was a bit dull for my taste.

    So I've decided to create a background image
    called Star Background.PNG
    with lots of dimmed stars.

            

    Adding some code to the program
    for defining and loading the image.

; Stars in the background
Global BackgroundImage

..

; Load background image
BackgroundImage = LoadImage ( GraphicsFolder + "Star Background.PNG" )


    So now I can replace
    the Cls command
    with TileBlock
    to display the image
    across the entire screen
    regardless of the resolution.

    ; - Screen
    Viewport 0 , 0 , ScreenWidth , ScreenHeight
    Origin 0 , 0
    Color 0 , 0 , 0
    Rect ScreenWidth/2 , 0 , 1 , ScreenHeight
    Flip
    TileBlock


    This isn't a very clean location
    for the TileBlock command,
    but I'll change that in a bit.

    I like adding things
    in a quick and dirty way first.
    That way I can see very quickly
    if it's something I want to keep.

    So when I tested the game
    with this new code added,
    it still seemed a bit dull to me.

    Wouldn't it be cool
    to have a moving background,
    much like parallax scrolling?

    This would mean that the background motion
    would depend on the player speed or position.

    For example the tilemap 'travels'
    at the same speed as the player.
    Imagine making the background 'travel'
    at half the speed of the player.

    And because camera orientation
    means reversing the coordinates, where (0,0) is the origin,
    as previously shown in Viewpoint,
    the entire code is no more complicated than this:

TileBlock BackgroundImage , -Player( 1 )\PosX/2 , -Player( 1 )\PosY/2


    I'm adding this for each player.

; Render game
; - Player 1
Viewport 0 , 0 , ScreenWidth / 2 , ScreenHeight

TileBlock BackgroundImage , -Player( 1 )\PosX/2 , -Player( 1 )\PosY/2

Origin ScreenWidth / 4 , ScreenHeight / 2
DrawTilemap Player( 1 )
DrawBullets Player( 1 )
DrawPlayers Player( 1 )

; - Player 2
Viewport ScreenWidth / 2 , 0 , ScreenWidth / 2 , ScreenHeight

TileBlock BackgroundImage , -Player( 2 )\PosX/2 , -Player( 2 )\PosY/2

Origin ScreenWidth / 2 + ScreenWidth / 4 , ScreenHeight / 2
DrawTilemap Player( 2 )
DrawBullets Player( 2 )
DrawPlayers Player( 2 )


    Now I can completely remove the other TileBlock
    below the call to Flip.



    More video modes

    Let's expand the number of resolutions
    that are supported by the game,
    to increase the chance
    of getting the maximum width
    for each player's view.

    I've added the previous resolution detection code,
    as previously described in Video mode detection,
    in the InitGame function.

    So that's also where I've added
    a large number of different new resolutions.

; Resolution constants from Blitz
Const WindowMode_AutoDetect = 0
Const WindowMode_FullScreen = 1
Const WindowMode_Windowed   = 2
Const WindowMode_Scaled     = 3

..

; Graphics resolution
Global ScreenWidth
Global ScreenHeight
Global WindowMode
Global ColorDepth

..

; Check if a resolution is listed in the video card's supported videomodes
Function ResAvail ( Width , Height )
    Local ColorDepth

    For ColorDepth = 16 To 32 Step 8
        If GfxModeExists ( Width , Height , ColorDepth )
            Return ColorDepth
        End If
    Next
End Function

..

Function InitGame ()

    ..

    ; Windowed in debug mode, otherwise fullscreen
    WindowMode = WindowMode_AutoDetect

    ; Autodetect optimal resolution
    ; - Wide screen medium resolution (2.13x wide)
    ScreenWidth  = 1024
    ScreenHeight = 480
    ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
    If Not ColorDepth

      ; - Wide screen high resolution (1.78x wide)
      ScreenWidth = 1280
      ScreenHeight = 720
      ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
      If Not ColorDepth

        ; - Wide screen medium-low resolution (1.77x wide)
        ScreenWidth  = 848
        ScreenHeight = 480
        ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
        If Not ColorDepth

          ; - Wide screen low resolution (1.5x wide)
          ScreenWidth  = 720
          ScreenHeight = 480
          ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
          If Not ColorDepth

            ; - CRT screen high resolution (1.33x wide)
            ScreenWidth  = 1024
            ScreenHeight = 768
            ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
            If Not ColorDepth

              ; - CRT screen medium resolution (1.33x wide)
              ScreenWidth  = 800
              ScreenHeight = 600
              ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
              If Not ColorDepth

                ; - CRT screen low resolution (1.33x wide)
                ScreenWidth  = 640
                ScreenHeight = 480
                ColorDepth = ResAvail ( ScreenWidth , ScreenHeight )
                ; - If this resolution will not work either,
                ;   Blitz will show an error message anyway
              End If
            End If
          End If
        End If
      End If
    End If

    ; Try the detected screen resolution
    Graphics ScreenWidth , ScreenHeight , ColorDepth , WindowMode

    ..




    Final structure

    Also, I've further structured the code
    to follow the guideline
    as explained in Structure
    where I've ended up
    with the following categories:
    - Graphics handling
    - Audio
    - Player
    - Bullet
    - Tilemap
    - Spawn spots
    - Collision
    - Mathematics
    - Miscellaneous
    - Main sub-routines
    - Main execution

    Maybe you can also see
    that it is a little bit different
    from the original design Specification,
    but it still follows
    the original design Structure.

    And, to me, it's very easy
    to both read and understand 



    Verifying loaded files

    A number of times
    when I started the game
    I forgot to put some external files
    in the right place.

    So then the game crashed
    with some weird
    and hard to understand
    error message.

    If some person
    tries to run this game
    without the external files
    in the right place,
    it should not crash
    but give a descriptive
    error message.

    I've come up with a very simple function
    that checks if something was loaded properly.
    And if it wasn't,
    it will show a custom error message.

Function Verify ( TargetHandle , ErrorMessage$ = "probs :(" )
    If Not TargetHandle Then RuntimeError ErrorMessage
End Function


    For example to check
    if the intro music is loaded properly,
    I would call Verify
    after attempting to load the music.

; Start music first
GameMusic = LoadSound ( AudioFolder + "TheChance - Gravity Force.MP3" )
Verify GameMusic , "Unable to load intro music"


    Blitz (very flexibly) allows the loading
    of sounds, images and other files
    without succeeding,
    as the programmer can then decide
    what the consequence should be.

    So I've added a call to Verify
    for the loading of all sounds and images,
    in the same way as the above intro music.

    For example the code
    for loading the rotated images
    would then look like this:

Local PlayerNumber
Local Angle

..

; Load pre-rotated player images
For PlayerNumber = 1 To 2
    For Angle = 0 To 360 Step 5
        PlayerImages( PlayerNumber , Angle ) =
            LoadImage ( GraphicsFolder + "Ships\" +
                        "Ship " + PlayerNumber + " - " + Angle + ".BMP" )
        Verify PlayerImages( PlayerNumber , Angle ) ,
            "Unable to load ship image " + PlayerNumber + "," + Angle


    Then I came to the loading of the tilemap,
    and discovered that LoadTilemap only returns False
    if the tilemap file doesn't exist (or can't be loaded).

Local TilemapLoaded

..

; Load tile map data
TilemapLoaded = LoadTilemap ( TilemapsFolder + "Test Tilemap 1.TXT" )
Verify TilemapLoaded , "Unable to load tilemap"


    But what if the tilemap itself
    doesn't contain any spawn spots at all?

    The game would certainly crash
    because the RespawnPlayer function
    depends on the existence
    of a spawn spot.

    So then I figured
    I can just alter the LoadTilemap function
    in a very quick way,
    to return False
    if the number of spawn spots is zero.

Function LoadTilemap ( FileName$ )

    ..

    CloseFile FileHandle

    ; Return true if any spawn spots found, otherwise false
    If SpawnSpots > 0
        Return True
    Else
        Return False
    End If

End Function


    Did you know both pieces of code above
    can be compressed a little?

; Load tile map data
Verify LoadTilemap ( TilemapsFolder + "Test Tilemap 1.TXT" ) , "Unable to load tilemap"

..

; Return true if any spawn spots found, otherwise false
Return SpawnSpots > 0


    But if you prefer the previous style,
    please do follow your preference 

    Note that there are a few more ways
    to crash the game 
    For example by altering the tilemap file
    and putting in some bogus data 

    But I'll leave it up to you to figure out
    how to prevent the game from crashing then.
    For example you can range-check the values
    like TilemapWidth and TilemapHeight
    after having been loaded in with ReadLine.



    Splash screen

    To make the game look a little more professional,
    and to prevent the 'game explorer'
    from being thrown straight into the game,
    I'm adding an intro screen
    while the game is being loaded.

            

    It looks like a tilemap, but it's just an image
    which I've saved as X-NON Logo.PNG.

    Actually, I've created it using tile frames
    from the file LogoTiles.BMP
    using a tilemap editor 

            

    All of the code required
    for loading and drawing the logo
    can be placed in the InitGame function.

Local IntroImage

..

; Show splash screen / front-end
IntroImage = LoadImage ( GraphicsFolder + "X-NON Logo.PNG" )
Verify IntroImage , "Unable to load intro image"
MidHandle IntroImage
DrawImage IntroImage , ScreenWidth / 2 , ScreenHeight / 2


    I'm placing the logo
    in the center of the screen
    so that it doesn't matter
    in which resolution you run the game.

    On fast computers
    loading all of the external files
    takes a fraction of a second.

    And I want to show the logo
    for at least a little while longer,
    say.. 3 seconds.

    I'm gonna use a simple timer,
    just like we've done before
    in the Bullets chapter.

; Remember when started loading
LoadStart = MilliSecs ()


    The above code would be placed
    somewhere in the beginning
    of the InitGame function.

; If loading took less than 3 seconds,
; wait until those same 3 seconds are up.
; This, in order to make the game logo visible
; for at least a little while.
While MilliSecs () - LoadStart < 3000
Wend


    And this code would be placed
    somewhere at the end
    of the InitGame function.



    Tilemap editor

    In the beginning
    I thought to use only a text editor
    to create tilemaps for the game,

    But at some point
    I discovered that some things that I wanted to do
    just were not possible with those tools.

    For example, the final tilemap,
    which is in Arena 1.TXT,
    I have created with the help
    of various other programs.

    In the folder Extra
    you will find some of these programs
    as well as multiple tilemap editors
    and some extra files.

    Note that I have not tutorialized those programs
    so you're on your own to discover what's what
    and how to operate them,
    which should not be a problem 


     ASCII Converter.BB
    This allows you to convert images to ASCII files and back,
    so you can edit tilemaps using drawing programs!


     Editor (simple).BB
    The tilemap file you want to work on
    is specified directly in the code itself.
    It is loaded when the program is run,
    and also saved when the you quit the program.

    These are the keys you can use in the program:
    Space: Toggle transparent drawing tile
    Cursor keys: Move map
    (+Shift): Move map faster
    Enter: Select tile for drawing
    Left mouse button: Draw selected tile
    Right mouse button: Erase tile
    Middle mouse button: Pickup tile from tilemap
    Escape: Exit and save


     Editor (elaborate).BB
    This program works as a 'normal' tilemap editor should
    by being able to load and save from within the program.
    Inside the code you can easily change the tileset to use,
    for example the tileset for the tilemap or the logo.

    Keyboard shortcuts:
    Tab: Show grid overlay
    Space: Toggle drawing tile transparency and hide empty tiles
    N: New tilemap (width,height)
    L: Load tilemap (filename)
    S: Save tilemap (filename)
    Cursor keys: Move tilemap
    (+Shift): Move tilemap faster
    Enter: Select tile to draw
    Keypad cursor keys: Move tile selection
    Left mouse button: Paint tile
    Right mouse button: Erase tile
    Middle mouse button: Pickup tile
    Escape: Exit



    Expansion

    If you haven't already,
    take a look at X-NON.BB
    in the Tutorial files index
    to see the final resulting code
    of this tutorial,
    if you want 

    Here are some more features
    that I thought would be interesting
    to be added to the game
    at a later stage:
    - Ship health;
       making the ship flash when hit,
       needing more than 1 hit to be killed.
    - A simple scoring system;
       so you don't have to count yourself 
    - A simple menu interface;
       so you can change some settings,
       like speed, gravity, controls, etc.
    - New tilemaps;
       for some more variation.
    - New tiles with more spice;
       to make the experience more vivid.
    - New ships;
       allowing players to choose a ship
       that fits their own style.

    You can also go overboard
    and pick some of these:
    - Tilemap editor integrated into the game;
       so you can add or modify maps with ease.
    - Single player missions;
       if you don't have a partner to play with,
       you can fly through a tilemap maze
       with various obstacles to overcome.
    - Network play (like DirectPlay);
       to play with anyone you like,
       without leaving your home.



    Bonus

    Originally the idea was to have a game that was normalized into extremes
    utilizing advanced object oriented-like variable structures
    and their accompanying methods.

    Actually, I have a lot of projects
    which are built this way (too many!),
    but it occured to me that this was a little extreme
    for a game of this size 

    You see, I sometimes have the tendency
    to make things more complex than they have to be.
    So I immensely simplified the game structure a "few" times.

    If you're interested,
    the full blown project package is available,
    containing all of these layers of simplification,
    as well as all stages of construction (and rewrites),
    weighing at ~50 Megabytes.

    I've included one of the most useful bits
    from the full blown project package
    combined in a single bonus tutorial file,
    which is called Plan Snippets.txt 
    located in the Extra folder.
    
    It contains considerable background information
    and even more details behind the construction of X-NON
    using a home-made and normalized technique (!)
    which, in essence, can also be applied
    to any other development process.

    Despite the current 'simplicity' of this tutorial,
    if anything is unclear about this tutorial
    or if you have questions anyway,
    just let me know!

    You can contact me via my contact information page,
    or simply by sending an email to TheChange@yahoo.com.

    Have fun! 
    And thank you for reading! 



    Index

    The making of X-NON
    Introduction
    Knowledge reference
    Concept
    Construct
    Specification
    Direction
    Structure
    Graphics resolution
    Orientation
    Ship gravity
    Sound panning
    Ship "Asteroids" physics
    Thrust sound
    Tilemap
    Spawn spots
    Video mode detection
    Sounds overlapping
    MilliSecs
    Bullets
    Pre-rendered rotated ship
    Frame limiting
    Viewpoint
    Bullet viewpoint
    Tilemap viewpoint
    Player viewpoint
    Creating a player (ship)
    (Re)spawning the player (ship)
    Player control
    Player (ship) thrust
    Rotating a player (ship)
    Player (ship) fire
    Kill a player (ship)
    Updating a player (ship)
    Music
    (Media) file locations
    Ship vs ship collision
    Ship vs bullet collision
    Tilemap vs ship collision
    Tilemap vs bullet collision
    Game control
    Fixing bugs
    Background image
    More video modes
    Final structure
    Verifying loaded files
    Splash screen
    Tilemap editor
    Expansion
    Bonus
    Index