Modelling the Game World in Space Commander – Learn to Code Your Own Games

The Space Commander world is modelled as a 2D space, like looking at a map from above. Objects in the game exist and move in this 2D space. All our calculations will take place in this game world. When it’s time to draw objects on the screen we’ll then map the game world to our screen world.

To describe objects’ position and motion we need a few parameters.

Position

This is the (x, y) coordinates of the object in the 2D game space. Screen coordinates tend to use the top left corner as the (0, 0) position with the positive x axis to the right and the positive y axis to the bottom. This differs from the conventional mathematical axes which have the positive x axis to the right but the positive y axis to the top.

It’s really a personal choice but I usually stick to the mathematical model unless the game world is quite simple. In this case we’ll be modelling vector quantities for velocity and acceleration, creating targeting code, etc., so using the mathematical model just makes it easier (for me) to see how angles and positions fit together.

You can make the game world match the screen world, but it doesn’t save much computing power and I can never get my head around the flipped maths!

Direction

When objects move or rotate, we need a way to describe their direction, or the way they are pointing. Using normal mathematical notation this gives us a 0 degree angle parallel to the positive x axis (i.e. horizontally to the right) with positive angles measured in an anti-clockwise direction from it.

Using this notation makes all our angle, sine, cosine and tangent calculations match with what we would expect.

Distance

As our world is imaginary, we don’t have to worry about real world distance measurements. Our positions will be easier if we use pixel coordinates, so it makes sense to measure distances in pixels as well.

Time

Again, we get to choose our units of time. We can use seconds, but a more natural measurement inside the code is the game loop. Using one game loop as one unit of time simplifies the whole time process. If we set a speed of 5 pixels per loop, we simply need to add 5 pixels each time our game loop runs.

This method can have problems. It relies on the game loop running at a set speed. TIC80 runs the game loop at 60 loop per second. If our code gets too complex each game loop takes longer than 1/60 second to complete. Our game will start to slow down, and objects will visibly move slower on the screen.

If you’ve played any retro computer games, you’ll have seen this in action.

Making the World Infinite

We want the player to be able to fly as far as they want in any direction, giving this idea of an infinite playing space. If we use a standard position, measured in pixels from a fixed origin we’ll hit a problem.

In computers, numbers have limits. If we use an integer variable to model the x coordinate of the player there will be a maximum (and minimum) value that this variable can store.

If you’re familiar with C programming, you’ll understand about using different numbers of bytes to store integers. A single byte (8 bit) integer can store values from 0 to 255. A 16-bit integer can store 0 to 65535. And so on.

If our player were to fly in one direction for a long time the coordinates may reach the limits of our variable. E.g. using 8-bit integers we can count up to 255, but adding 1 to this will result in an overflow error and our variable will wrap round to 0.

To get around this potential problem we’ll use the fact that we always want to player to be in the centre of the play area. So, we’ll use the player ship as our origin and have everything moving relative to it. So, if the player ship is travelling up, we keep the player stationary, but move everything else down, giving the same end movement.

In TIC80, which uses Lua, all numbers are represented by 64-bit floating-point numbers (real numbers with decimal places!). 10 bits are used for the exponent (the power of ten), 1 for the sign (positive and negative) and 53 for the mantissa (the significant figures of the number). This allows Lua to represent integer values from -2^53 to +2^53. We’d never reach that value, but I hope you get the idea of what we’re doing. If you ever do code in C, or even worse assembly, you’ll now know what to do!

Modelling the position and Movement of Objects

So now we know the basic parameters we’re using let’s look at how we’ll model our data.

We want to create several helper functions that will allow us to calculate positions, movement, rotations and so on. We’ll have a few different object types for our player ship, enemy ships, missiles, stars, etc.

We could write separate functions for each object to, for example, rotate it. But each of these functions would basically be the same code repeated multiple times and this isn’t good coding practice.

So, we want each operation to be handled by a single helper function which will be able to work with all our objects.

e.g. rotate_object(player_ship) and rotate_object(enemy_ship) should both work.

This relies on each object in our game storing its model data in the same format. So, when we create a class (object definition) for each game object it will inherit this data format. This is one of the principles of Object Orientated Programming (OOP) – Inheritance. Or we can think of each object providing a defined set up to its values, an OOP Interface.

If you’re interested in learning Object Orientated Programming, please check out my Python courses on Udemy.

In TIC80 we have to implement this manually, but in other languages, such as Python, we can do it through the OOP coding system.

So, each object in the game will have,

• a position attribute with x and y coordinates.
• a velocity attribute with an angle and magnitude

Moving Objects in the 2D World

The Player Ship

We’ve already seen that the player ship isn’t going to move. Its position will always be at (0, 0). But it will have a velocity with angle and magnitude.

To move the player ship, we work out its x and y position increments, dx and dy.

We then take these away from the positions of every other object in the game.

Every Other Object

Because we’re modelling our velocities as vectors (magnitude and direction) we can simply add our movements together to get the resultant motion. Each object has its own position and velocity, so we again calculate the incremental movement due to that motion and simply add that to its position after (or before) the movement relative to the player ship.

This then gives the new object position in (x, y) format using the player ship as the (0, 0) origin.

Mapping the Game World to the Screen

So, all of the previous calculations allow us to move our objects around in the 2D game world where we are obeying all the mathematical norms for the axes and angles. We need to work out how to draw this on the screen.

We know that we always want the player ship pointing vertically. This is a 90 degree angle, measured from the positive x axis. If the player ship is currently travelling at an angle A, we would need to rotate the whole game map by (90 – A) degrees to get the ship pointing up the screen.

Our screen coordinates are measured from the top left corner, with x increasing to the right and y increasing down the screen. So, to map our 2D game world to the screen we need to take the game world x coordinate, but the negative y coordinate. We then need to offset this by half the screen width and half the screen height to move the origin to the centre of the screen.

So, our helper function will look like,

This leaves new position with the screen coordinates version of the game world position.

Mapping Object Rotation to the Screen World

As we rotate an object around the origin to position it on the screen its coordinates will change, but so will its angle of rotation.

We know that we need to rotate the game world by (90 – player_ship_angle). So, when we draw an object on the screen world its rotation will also increase by the same amount,

Coding the World Display

So, we’ve now got all the information and calculations we need to code this game world and map it to the screen.

Please have a look at the video and the code below to see how I’ve implemented our algorithms.

Play the Demo Code

Code