One of the key features of Defender was its radar. The player relied heavily on the tiny blipped dots to position himself within the playfield and work out what action to take. In Hoth Strike I want the exact same thing.
Hoth Strike is essentially a Star Wars inspired (actually The Empire Strikes Back) Defender clone. The core game action revolves around the player ensuring the safety of the stranded rebel pilots who lay strewn across the snowy landscape. In order to pinpoint the pilots the player uses the radar. As with Defender the radar also picks out the alien drones and other adversaries. The only difference between my radar for Hoth Strike and Defender’s is that I won’t go to the trouble of mapping the terrain. Simply put I have no terrain to map. Defender’s wireframe landscape was varied enough to warrant the processing but mine is a Scooby Do wrapping tileset with no distinguishable features.
So how did I scale the playfield down in to a radar ?
It’s a 3 step process:
- Plot the object’s position in the total playfield area.
- Calculate the object’s position as a percentafe of the total playfield.
- Place the blip representation of the object within the radar using it’s percentage position in the total playfield.
The playfield is defined in code as
var playfield = 8096;
That is, the playfield is 8096 pixels wide. The total playfield however is twice that size (16192 px). The reason for this is that I plot an object’s position as either > zero or < zero. Any object whose x co-ordinate falls less than zero continues to decrease through the negative range until it falls less than -playfield + object width (-8096 in our case). At this point it’s position is recalculated to be playfield + object width.
-8096 [ Negative Playfield ] 0 [ Positive Playfield ] +8096
Using the above thumbnail representation of the playfield you can see clearly that the total consideration for the playfield is actually 16192 pixels.
-8096 [ Negative Playfield ] 0 [ [c] Positive Playfield ] +8096
Just to expand on the playfield theory you can see in the thumbnail above that the Canvas area (the area that the player actually sees [c]) is only a small portion of the entire playfield. When I plot the co-ordinates of objects on each “tick” I literally position them within the total playfield. If you altered the oCanvas.div.style.overflow to be “none” instead of “hidden” you would see every game object and your browser window would probably include a long horizantal scroll bar.
So it makes sense then that every object has a position relative to the total width of the game’s playfield. Expressing this position as a percentage ought to be easy.
The radar DIV object is quite simply an object that I position as a child of oCanvas. I position it absolutely and ensure that it sits central for aesthetic reasons. I store the width of the radar in radarwidth and it’s height in radarheight.
Each of the “blips” on the radar are individual DIV objects that are picked from a “blip pot”. I define around 60 blip objects and on each game tick I call the function setBlip(o) where o is the object to be represented in the radar. e.g. oATAT[i].
So what does the setBlip() function actually do ?
As highlighted above the first thing it does is take the co-ordinates of the passed object and assign a temporary x and y co-ordinate which are the co-ordinates of the object relative to the total playfield.
var tx = o.x < 0 ? playfield – (o.x * -1) : playfield + o.x;
The object o is assessed as to whether it is in the negative playfield or not. If it is we multiply it’s x co-ordinate by -1 and position it within the first half of the total playfield by subtracting its x co-ordinate from the playfield width.
e.g. if an object is at -3000 it’s position in the total playfield can be calculated thus:
var tx = 8096 – (3000 * -1); or var tx = 8096 – 3000
var tx = 5096;
For objects that carry positive x co-ordinates it’s much simpler. We simply want to position them within the second half of the total playfield by adding their x value to the size of the playfield. Such objects will always be greater than the playfield. i.e. > 8096 in our case.
Now that we have the object’s position within the total playfield plotted we can express it’s position as a percentage of the total playfield.
var pcx = (tx / totalPlayfield) * 100;
var pcy = ((o.spriteclass == “atat” ?
o.y + (o.h / 2) : o.y) / nCanvasHeight) * 100;
The first line is a straight forward percentage calculation. The second line sees the embedded if statement using a different y value for the AT-AT walkers whose position is always rooted at the base of the screen. For cosmetic reasons therefore I use a y co-ordinate that is actually half way down the AT-AT sprite since it is quite tall. The rest of the percent calculation uses the canvas height rather than the playfield since the canvas is a fixed height and always positive.
Finally I need to plot the co-ordinates of the object relative to the size of the radar.
var posx = (pcx / 100) * radarwidth;
var posy = (pcy / 100) * radarheight;
posx and posy are the actual co-ordinates therefore of the object’s blip in the radar. All that remains is to assign the values to the x and y properties of the blip object and to blit() it to the screen.
On every game slice now I have a miniature representation of the total playfield in a small radar window. This is vital for the player to see the bigger picture as they whizz across the landscape looking for stranded rebel pilots.
I appreciate that this is merely theory and a few images would probably help to illustrate it all better but I’m banking on the game itself to illustrate my theories.
Comments and questions welcome.