# Asteroids: Drawing Objects

Recently I’ve started mentoring a local high school student a bit on implementing a video game, and this is a technical note toward that.

Drawing basic shapes out of polygons to represent game objects is straightforward and requires just a bit of trigonometry, outlined here.

## Shapes

The core idea is that the polygon is located around the object’s current position. So, a standard looking Asteroids ship might be defined as four points about the origin as in this diagram:

Four coordinates defining a fairly standard Asteroids player ship.

The polygon is captured by a list (array) of points in order around the shape. Caveat other restrictions in the game’s code, it doesn’t really matter if they’re clockwise or counter-clockwise. In this case the ship is defined as follows, proceeding counter-clockwise:

1. (0, 24)
2. (-18, -24)
3. (0, -18)
4. (18, -24)

One cute trick that’s often done in Asteroids is to randomly generate the polygons for the asteroids themselves. The points list needs to be in order though or else the lines will overlap and the shape look funny. There are several ways to do this, but one is to go around in a circle, picking a random angle within that arc of the circle, picking a random distance from the origin for that tip of the rock, and computing the x & y value for that polygon point using that angle and distance.

## Drawing

In most polygon graphics APIs, drawing starts by starting a new shape if necessary (i.e., `newpath`) and moving the cursor to the first point in the list (i.e., `moveto`). It then loops over each of the other points and draws a line from the previous position to the current point (i.e., `lineto`). The path is then either closed by drawing a line to the first point in the list from the last, or using a specific function to close the path if the API has one (i.e., `closepath`).

## Rotation and Placement

Of course, in the game the object typically has to rotate and move. Rotation is simple because we’re taking the object’s current position as the origin of the polygon representing it. Each point to draw just needs to be calculated through the basic rotation formula:

```x' = (x * cos(angle)) - (y * sin(angle)) y' = (x * sine(angle)) + (y * sin(angle))```

In these formulas, `x` and `y` are the current point in the polygon list while `x'` and `y'` are the actual points to draw. The direction the object is currently rotated to, i.e.,which way the player is facing, is in `angle`.

This will draw the polygon around the origin, but of course the object is actually somewhere else on screen. This is a simple translation, effectively moving the polygon’s origin to the object’s actual position. In other words, just adding the object’s x and y coordinates to the point to draw:

```x' = x' + objectx y' = y' + objecty ```

## Minor Complications

Although the ship above has somewhat naturally been modeled facing up, angle 0 in trigonometry is actually facing to the right. So, the polygon should instead be modeled with its natural direction facing that way.

Adding just a small detail, essentially all modern computer displays and most software use a slightly different coordinate system from what’s typically used in mathematics: The origin is at the top left of the screen, and the y axis increases going down the screen, not up. Note that this means the 90 degree angle is actually facing down and 270 degrees points straight up.

A wide variety of ways to work with these facts can be applied, but the easiest is just to model the polygon facing to the right and to keep that coordinate scheme in mind. So, the example polygon above would actually be modeled as follows:

The ship actually facing angle 0.

The counter-clockwise ordering of points would then be:

1. (24, 0)
2. (-24, -18)
3. (-18, 0)
4. (-24, 18)

Another small detail to keep in mind is that nearly all trigonometry functions in software libraries are based on radians rather than degrees, though most people work more easily in the latter. Converting between the two just requires a simple formula based on the identity relationship between them:

`radians = pi * degrees / 180`

## Code

A simple demonstration of this is in the box below. Pressing the left and right arrow keys make the ship rotate, and it’s being drawn in the center of the screen rather than the origin (you may have to click on the box first to focus the keyboard on it):

The code snippets for this below are in Javascript, but should be easily applicable to most platforms.

The polygon for the ship has been defined as follows:

```var playershape = [
{ x: 24,  y: 0},
{ x: -24, y: -18},
{ x: -18, y: 0},
{ x: -24, y: 18},
]
```

It’s just an array of points, each a Javascript object with an x and y value. There is also a player object that has its own x, y, and angle, representing the player’s position and orientation on screen.

A couple trigonometry helper functions are defined, to convert degrees to radians, and to rotate x and y values:

```function degtorad(angle) {
return 3.1415926 * angle / 180;
}

function rotx(x,y,angle) {
return (x*Math.cos(angle)) - (y*Math.sin(angle));
}

function roty(x,y,angle) {
return (x*Math.sin(angle)) + (y*Math.cos(angle));
}
```

Note that each of the x and y rotations take as input x, y, and angle, because the rotation formula requires each of those values.

As discussed above, the ship is drawn by starting a path at the first point of the polygon, looping through each other point, and then closing it off. At each step the point to draw is rotated about the ship’s position as the origin, and then translated to the ship’s actual position on screen. This function captures that, and is called by the main drawing routine each time the ship needs to be displayed:

```function drawplayer() {
var x, y;  // These will be the point to draw.
var i = 0;  // i is the current polygon point we're using

ctx.beginPath(); // ctx is the graphics drawing context in this Javascript program.

// Calculate the actual draw point by rotating and then translating.
x = rotx(playershape[i].x, playershape[i].y, player.angle) + player.x;
y = roty(playershape[i].x, playershape[i].y, player.angle) + player.y;
ctx.moveTo(x, y); // Start the polygon at this point.

// Loop through the other points---note that this therefore begins at point 1, not 0!
for (i = 1; i < playershape.length; i++) {
x = rotx(playershape[i].x, playershape[i].y, player.angle) + player.x;
y = roty(playershape[i].x, playershape[i].y, player.angle) + player.y;
ctx.lineTo(x, y); // Extend the path from the previous point to this new one.
}
ctx.closePath(); // Close the path by adding a line back to the start.
ctx.stroke(); // Draw the path.
}
```

To initialize the player, its position is set to the middle of the screen and its orientation set as facing straight up:

```  player.x = canvas.width / 2;
player.y = canvas.height / 2;
```

Each time the left or right key is pressed, the ship’s angle is updated like this.

```    player.angle -= degtorad(10); // Decrease the angle by 10 degrees, making the
// conversion to radians first before subtracting
// from the current angle.
while (player.angle < 0) {        // This actually isn't necessary, but just makes sure
player.angle += 3.1415926 * 2;  // the player's angle is always between 0 and 2*pi.
}                                 // The drawing routines and other logic will all
// handle that fine, but it can make things easier for
// the programmer in writing other parts of the code.
```

## Conclusion

Those are the basic elements in drawing a simple game like Asteroids. The next complication is having an array or arrays of game objects. That’s necessary to capture all of them that might appear on screen, namely the rocks and bullets. A drawing function like that above then needs to be applied to each game object in the array(s), rather than being just hardcoded to a single game object instance like this example is to the player’s ship.

# Fullscreen Scaling in Phaser

This weekend I’ve been playing a bit with nailing down multi-device scaling in Phaser games. This was a bit more confusing than I expected, but I mostly figured out why and thought I’d share.

Update: I’ve posted this example and a state-based project template to GitHub.

My objectives were very simple:

• Set logical view dimensions around which the game will be based;
• Scale the game to fill the available window when loaded, maintaining aspect ratio and content;
• Upon clicking have the game go fullscreen and scale to fill the screen, maintaining aspect ratio and content.

This minimal example demonstrates those (click to fullscreen, again to return):

In the blog view here the game has been placed inside a 300px iframe and scales down accordingly from an 800×600 logical view. After you click it scales up to fill the screen as much as it can without losing content. All of this is using Phaser 2.1.3, the latest release. Note that this is just in Chrome & Chromium. Desktop Firefox seems to have have wholly separate issues, and on Android Firefox fullscreening doesn’t seem to do anything.

This test is extremely similar to Phaser’s dragon and anime fullscreen examples as well as its Full Screen Mobile project template. However, those have a couple issues and do not work ideally for me on both my desktop (Linux laptop, Chromium) and phone (Galaxy S3, Chrome). In the end the problems were small but critical.

First, Phaser’s ScaleManager has an undocumented property `fullScreenScaleMode` that controls how games scale in fullscreen mode. The examples use this. The project template however uses the property `scaleMode`. It’s fairly easy to miss that these are using different properties, and that the fullscreen variant even exists. Further, it seems you actually have to set both to get the expected behavior, at least for `SHOW_ALL` scaling and my two platforms. The code below has a simple chart of the effects under various combinations of setting or not setting both of these.

Second, the ScaleManager property `pageAlignHorizontally` seems to have a bug. In windowed mode it works as expected, but in fullscreen it actually causes the game to be horizontally off-centered. For the moment I’m planning to put the game into a container `div` to center in windowed mode. Phaser seems to take care of centering the game in fullscreen mode even without this being set. I haven’t diagnosed this further. My guess is the base code is setting a left margin to center the game if the property is set, and then fullscreen mode applies a left margin again without checking to see if that has already been done.

Third, it’s not clear from the examples and docs what of Phaser’s ScaleManager API is needed and what is not. The project template in particular does several things that don’t seem to matter, for example calling `ScaleManager::setScreenSize()`. Removing that seems to have no effect with these settings, though the docs say it’s necessary. Conversely, it is important to call `ScaleManager::refresh()` to have the game scale at the start. Otherwise you have to go fullscreen or cause another window change to have the settings apply. The examples however don’t call this.

In any event, after finally identifying all these the test seems to work well on both my laptop and phone. Code is as follows:

```<html>

<div id="game"></div>

<script type="text/javascript">
var game = new Phaser.Game(800, 600, Phaser.CANVAS, 'game',

game.stage.backgroundColor = '#336699';
}

function create() {

// Put a graphic in the center to demonstrate.
sprite.anchor.set(0.5);

/*
* How the following modes take affect.
*
* On a laptop (Linux, Chromium browser):
*   FS Scale  Reg Scale Reg Result  FS Result
*   On        On        Fills       Fills
*   On        Off       Unscaled    Fills
*   Off       On        Fills       Unscaled
*   Off       Off       Unscaled    Unscaled
*
* On a phone (Galaxy S3, Chrome browser):
*   FS Scale  Reg Scale N Result    FS Result
*   On        On        Fills       Fills
*   On        Off       Too big     Unscaled
*   Off       On        Fills       Unscaled; buggy
*   Off       Off       Too big     Exact fit
*
*/
game.scale.fullScreenScaleMode = Phaser.ScaleManager.SHOW_ALL;
game.scale.scaleMode = Phaser.ScaleManager.SHOW_ALL;

// Properly centers game in windowed mode, but aligning
// horizontally makes it off-centered in fullscreen mode.
//game.scale.pageAlignHorizontally = true;
//game.scale.pageAlignVertically = true;

// Docs say this is necessary, but it doesn't seem to change behavior?
//game.scale.setScreenSize(true);

// This is necessary to scale before waiting for window changes.
game.scale.refresh();

}

function gofull() {
if (game.scale.isFullScreen) {
game.scale.stopFullScreen();
} else {
game.scale.startFullScreen(false);
}
}
</script>
</body>
</html>
```

# Circle Intersection Test

Yet another quick test for a geometry function:

Click, drag, and release to draw a line. A point will be drawn at the intersections if there are any. Hit ‘S’ to toggle between treating the drawn segment as a line segments or a line.

The demo uses some basic Phaser features for the interaction and drawing. The Javascript code is:

```var game = new Phaser.Game(530, 300, Phaser.CANVAS, 'container',
{ create: create, update: update, render: render });

var line;

var setting;

var result1;
var result2;

var circle;

var segment = true;

function create() {

line = new Phaser.Line(game.world.width/4, game.world.height/4,
3*game.world.width/4, 3*game.world.height/4);

circle = new Phaser.Circle(game.world.width/2, game.world.height/2,
Math.min(game.world.height, game.world.width)/2);

setting = false;

result1 = new Phaser.Point();
result2 = new Phaser.Point();

segment = !segment;
}, this);
}

function update() {

if (setting) {
line.end.set(game.input.activePointer.x,
game.input.activePointer.y);

if (!game.input.activePointer.isDown) {
setting = false;
}
}
}

function click(pointer) {
setting = true;
line.start.set(pointer.x, pointer.y);
}

function render() {
game.debug.geom(line);

game.debug.geom(circle, '#00ff00', false, 2);

var res = intersection(line, circle, result1, result2, segment);
if (res) {
result1.x--;
result1.y--;
result2.x--;
result2.y--;

game.debug.geom(result1, '#ff0000');

if (res == INTERSECTION)
game.debug.geom(result2, '#ff0000');
}

}

var NO_INTERSECTION = 0;
var INTERSECTION = 1;
var SINGLE_INTERSECTION = 2;
var TANGENT = 3;

function intersection(line, circle, result1, result2, segment) {
var lx = line.end.x - line.start.x;
var ly = line.end.y - line.start.y;

var len = Math.sqrt(lx*lx + ly*ly);

var dx = lx / len;
var dy = ly / len;

var t = dx*(circle.x-line.start.x) + dy*(circle.y-line.start.y);

var ex = t * dx + line.start.x;
var ey = t * dy + line.start.y;

var lec = Math.sqrt((ex-circle.x)*(ex-circle.x) +
(ey-circle.y)*(ey-circle.y));

var te = dx*(line.end.x-line.start.x) + dy*(line.end.y-line.start.y);

if (segment) {
if ((t-dt < 0 || t-dt > te) &&
(t+dt < 0 || t+dt > te)) {
return NO_INTERSECTION;
} else if (t-dt < 0 || t-dt > te) {
result1.x = (t+dt)*dx + line.start.x;
result1.y = (t+dt)*dy + line.start.y;
return SINGLE_INTERSECTION;
} else if (t+dt < 0 || t+dt > te) {
result1.x = (t-dt)*dx + line.start.x;
result1.y = (t-dt)*dy + line.start.y;
return SINGLE_INTERSECTION;
}
}

result1.x = (t-dt)*dx + line.start.x;
result1.y = (t-dt)*dy + line.start.y;

result2.x = (t+dt)*dx + line.start.x;
result2.y = (t+dt)*dy + line.start.y;

return INTERSECTION;
} else if (lec == circle.radius) {

result1.x = ex;
result1.y = ey;

result2.x = ex;
result2.y = ey;

return TANGENT;
}

return NO_INTERSECTION;
}
```