PLATO Empire - Empire 2 - Tactics

Empire 2 - Tactical

Summary of Empire 2 Features:

It seemed that the ships needed more involvement. In Empire 1 they just automatically lumbered from one planet to another carrying the goods for trade. Each player was, in essence, managing affairs from on their own planet and didn't even have the option of moving themselves.

The single screen on Empire 1 felt too confining as well.

In late August of 1973 I redesigned Empire.

Change in Direction - Tactical

By 'tactical' I mean controlling your spaceship, flying on it, shooting from it. With a focus on the 2D virtual shooter (looking "down" from above the flat-land plane of space) action format, I scrapped the strategic command aspects. The players no longer concerned themselves with building an economy, ensuring fuel supplies, managing populations, attempting to take over other planets. They just flew around in 2D space and shot at each other.

It was a blast.

Empire II expanded from a single screen to a 'space' of 8x8 grid of sectors with each sector being a screen full.

When playing, you saw only the sector in which your ship resided, torpedoes and ships could move into the same sector at any time.

Your ship moved by rules of physics, accelerating, decelerating, and rotating. Once you started the ship moving, it continued at that rate until changed. It followed a modified set of real physics rules. One of those modifications was that if you reached an edge of space your ship's location wrapped around to the corresponding opposite edge and continued moving. Not exactly real.

To stop, you needed to rotate your ship in that direction opposite to your motion then fire your thruster.

If you fired a torpedo it moved in the direction you aimed and included the vectors of direction that you were moving. You could fire a volley of torpedoes which would travel into the next sector hoping to hit something there.

The game proved quite popular. I continued to optimize it, taking suggestions from players. The tough apsect of this development was that I was making changes to the live source code of the players playing the game at that time. If I made an error or added a bug, it could cause the game to end until I could figure out the fix. Add on top of this that I had no printouts. This required me to memorize the entire program; which block of source a section of code resided in, which lines that section of code were in that block.

Implementing the Game

The PLATO display screen was 512x512 pixels. This takes 9 bits to store the values 0-511 since 29 is 512. See power of two for a detailed description.

Empire II expanded from a single screen to a 'space' of 8x8 grid of sectors. This takes only 3 bits (23 is 8) to store, so it would only take 12 bits each for X and Y coordinates. I was not so worried about packing data into memory at this point in the development, but this is useful background for later.

The coordinates of the spaceships and torpedoes, user information, and other data needed to coordinate between the timesharing terminals was kept in common. Since the system enforced that only one user could access common at any time, interactions between the running instances of the game were simplified. If one ship's location was updated to a new position, everyone else's program could know that location and determine whether they would be able to see it or not.

A Matter of Space

PLATO provided up to 1,500 words of common memory and 150 words of individual user memory (each user's instance could access their own 150 words of 'student' memory and the 1500 words of common memory) and that is all.

During the first years a lesson (program space) could hold a maximum of six "parts", each part having seven (7) blocks of three hundred twenty (320) 60-bit words. The first block was required overhead to keep the directory information. That's 13,120 words or 96K bytes.

That's not a lot of space to develop a multi-player game in, let alone one as complex as Empire was becoming.

On the Control Data Cyber computers a word was sixty (60) bits, which could represent huge numbers. Most of the memory needed by the game was only the bottom eleven bits to represent an x or y coordinate. This greatly limited the number of objects that could be represented. Somehow, I had to squeeze the number of ships and the number of torpedoes that each ship could fire and the other coordinating paramters into 1,500 words. I decided on fifty (50) ships, one player to a ship, and each ship could fire no more than three torpedoes. This would leave some room for future growth. Players could align themselves with one of eight teams.

Character Set

Another limiting factor was the character set; we had a fixed number of icons (8x16 pixel) characters. PLATO ingeniously provided for an alternate character set that could be downloaded to the terminal memory of each user in a particular program. This meant that those objects could be displayed quickly and any where on the screen.

For each ship I determined that eight different directions would suffice in showing the general direction in which it was headed. Characters were 8x16 pixels, so if a ship were only eight pixels wide and was heading up or down it would only take one character position; if headed any of the other directions, it would take two character positions. I was able to fit four different spaceship types into the charset.

To see what the ships looked like go to The Plot Thickens on the next page.

At that early time there was no character set editor. One had to draw out a character on a grid of paper then convert the bit locations into octal values to then be placed into a character set location.

A sample PLATO TUTOR command would look as follows:

char object1 o000000,o000000,o003401,o004377 o004000,o004377,o003401,o000000

The bit-values of these octal numbers indicate whether the pixel is on or off. Scary, huh?