For those who aren’t the three people interested in my Laser Squad dissection and attempted remake, I’ll give you a brief summary of the current plan and situation…

Laser Squad is a one or two player strategy game set in the future. The Laser Squad are similar to the Rebels from Star Wars and set about doing missions in order to achieve a specific objective. The themes of the game can be seen in various shows or movies. A simple example being ‘Moonbase Assault’ is a base that is storing data and well guarded. Such a computer system was a core focus of Season 2 of Blake’s 7 where Blake set the objective of destroying central control (*spoiler* which was then found to be somewhere known as Star One *spoiler*).

The game itself basically sets two teams against each other. One or both teams can be human controlled. Sadly, single player only allowed the player to be the Laser Squad. Each mission started by the player equipping the team with weapons, ammunition and armour. They then deployed the team into the deployment squares on the map and, once both teams have deployed, they have a number of turns to complete their given objectives.

The ultimate objective was to score 100 victory points. These points were allocated depending on what the mission objective was. For example, killing Sterner Regnix on ‘The Assassins’ scored 100 victory points for the Laser Squad. The Droid Squad scored points for each Laser Squad member they killed (generally calculated as (number of dead LS members / total LS members) * 100).

How you played the missions was completely up to the player. You could use the (in)famous Assassins tactic of arming Jonlan with a rocket launcher and many missiles and just have him keep shooting until he blows enough of the house away to reveal Regnix and take him down. Alternately, you could split the squad into 2 and attack both sides of the house together until you reveal regnix or encounter a droid. That was the beauty of the game. It didn’t really care how you played it too much which meant you can come up with your own strategies for winning.

Naturally it isn’t as easy as all that. You could run out of ammo. You could miss a target 3 feet away from you. You could panic and drop your weapon. You could be fatigued from carrying too much over a long distance. Julian Gollop implemented some really neat features.

This first article will focus on the sprite and map details.

With it being available on 8-bit systems, the graphics were very basic compared to today’s flashy 3D effects. They maps were a pseudo 3d/isometric style giving a basic 3D appearance but clearly only being 2D. Each sprite consisted of 4 x 8 byte pairs of information. In laymans terms, a byte pair can be used to represent the values between 0 and 255 by converting from hex (base 16) to binary (base 2). This in itself means you can create a simple sprite shape consisting of two colours. An example of this in action (for those not really too well versed in the detail of how a computer works) would be:

base 16 is represented by the numbers 0-9 then the letters A-F to represent 10-15
base 2 is represented by the numbers 0 and 1

8 is represented by the binary number 00001000 using 8 bits
F is represented by the binary number 11111111 using 8 bits

This means that the binary pair 8F is equal to 0000100011111111

As an aside, it also means that the byte pair 8F represents the decimal (base 10) number 143.

Using an actual 4 x 8 byte pairs from the game:

0000010303030100,0080C060FCE0C000,0201020106080000,A0C020C030888000

we have

00 00 01 03 03 03 01 00, 00 80 C0 60 FC E0 C0 00, 02 01 02 01 06 08 00 00, A0 C0 20 C0 30 88 80 00

Each of the 8 byte pairs represents a quarter of the sprite and take the form:

Top Left, Top Right, Bottom Left, Bottom Right

Using the knowledge from the previous example, the first 8 byte pairs will be

00000000
00000000
00000001
00000011
00000011
00000011
00000001
00000000

in binary. Now, putting them all together as they would look in the game:

00000000 00000000
00000000 01110000
00000001 11000000
00000011 01100000
00000011 11111100
00000011 11100000
00000001 11000000
00000000 00000000

00000010 10100000
00000001 11000000
00000010 00100000
00000001 11000000
00000110 00110000
00001000 10001000
00000000 10000000
00000000 00000000

A better (clearer) representation being:

…………….
………!!!….
…….!!!……
……!!.!!…..
……!!!!!!!!..
……!!!!!…..
…….!!!……
…………….
……!.!.!…..
…….!!!……
……!…!…..
…….!!!……
…..!!…!!….
….!…!…!…
……..!…….
…………….

Which some may recognise as the Dalek-a-like robot from Cyber Hordes walking (?) right.

The game map was a 2D grid 80 squares by 50 squares consisting of one sprite per square. A simple mapping of sprite 0 = value 0, sprite 1 = value 1, etc. in the map grid manages to build a fairly complete picture of the maps. For some reason I’ve yet to determine, many sprites match up but others don’t. I’m assuming a mapping table exists indicating which sprites map to which map value. My concern is that it would seem an additional effort to add this extra mapping so why bother? Why not just use the exact sprite values? It can either mean I have messed up and got the wrong numbering or I’ve missed something important. Fortunately, by running the game, I can build a mapping by checking the live map with the one I have generated and make any necessary changes to my mapping lists.

Ok, I’ve waffled on enough. Next time I’ll go through the gaming system and explain how stamina, damage, etc. are calculated.

Credit is due to the following:

Julian Gollop: Author and mighty fine game designer
William Fraser: Generously allowed me access to his commented reverse-engineered source code.

VN:F [1.9.22_1171]
Rating: 9.5/10 (2 votes cast)
VN:F [1.9.22_1171]
Rating: +3 (from 3 votes)
Remakes - How Laser Squad Works (Part 1), 9.5 out of 10 based on 2 ratings