Empire 3 - A Good Simulation of Space

Silas Warner drew the Enterprise. Graphics tools at that time were not easy to use, so it had to have taken quite some time. I animated the phaser shot so it would flash a couple times.

[NOTE: this is a screen shot from the active version of Empire 3 on the cyber1 system. I added the "III" to the title page a couple years ago to distinguish between this and the other versions. I opened the lesson to allow Inspection of the source code under Open Source agreements. You are welcome to look at it and learn from it.]

Empire [2] Needed Rework

During my first visit to CERL in October 1973 I had talked with and watched various players. While the second version was exciting, they had some preferences for some changes notably:

• space doesn't "wrap" around
• your ship might be next to an edge of the screen and an opponent out of site just across that edge; the display needed to center around each user's ship.
• play ran slow if you were in "foregnd" mode

Need to Redo the Undercarriage

While working to address the interactiveness/speed factor I also worked at adding features to the game. Here are some notes I found on the back of a handout from Computer Science class CS456/457 Systems Analysis class, Winter Quarter 1973. I found the note February 2008 while I was cleaning out old papers.

Moving the rear-projected microfiche projector turned out to be looked down upon by administrators; many sites used a tank of compressed air to move the microfiche.

On the back of Math 421, Spring 1974, I was working out the idea of Friend-Foe interaction.

I then developed a matrix outlining the actions causing responses.

Not all of these ideas were implemented into Empire III, though some appeared in later versions, modified a bit.

Getting TIPSy

Empire had to be optimized. A game becomes unplayable or uninteresting if it freezes, hangs, or crashes.

PLATO administrators began reducing the amount of cpu processing time available to each user. The amount was measured in Thousands-of-Instructions-Per-Second or TIPS. Foreground TIPS amounts in 1973 were set at 30, I think. By 1974 the amount was down to 20 and then 10. (vague recollection)

You could put a program into background mode, which could give you a high TIPS count, but you took the chance of being locked for a while. You were not guaranteed to get processing.

I can't say that the sysops lowered the foreground TIPS after Empire became a highly popular game, but it may have had some influence.

For each challenge of design there also were innovations provided by the PLATO designers. It also was a dynamically growing and improving system. Finding the right method was the challenge and the fun!

I spent a great deal of my design time working and re- working sections of code, designs, structure of data, and coding techniques.

The horizontal segment helped provide a way of getting more information into the tight amount of space. It allowed for a major expansion of the complexity from the earlier versions. However, accessing almost EVERY element of the array requires a divide. Not good.

Empire III started with many horizontal segments, ending up redesigned with vertical segments.

Empire 3 - Command Display

While changing from a full screen display I decided that a section of the screen could be laid out for instrumentation and command input.

The big innovation here was keeping your ship within the central part of the display or, perhaps easier to understand, as your ship moved through space, the display was updated to keep it near the center of the display. You could see movement of your ship relative to the other objects.

Note the two arrows pointing out from the ship. The shorter arrow indicates the thrust vector. The longer arrow shows the current vector of the ship.

The round dot lower right of the ship is the IFF indicator. If you don't see that dot next to other ships, they are not your friends.

The top section of the screen was for your command input and responses or messages.

Along the right from top-down, the section with "IIIc1" shows which sector you are currently in. That reads Quadrant 3, x sector "c" and y sector "1". The little box near the center of the axes shows where your sector is relative to all space.

VX and VY are your current velocity.

The display is currently showing a single sector. You could see your current sector (1x1), your sector and the ones around it (3x3), or long-range of two sectors out (5x5).

THR is the thrust in the direction your ship is pointed. It is the amount of acceleration. Thrusting took energy. Once up to speed, you could stop the thrusters and keep moving in that direction, of course to rotate around and use thrusters to slow down.

DIR and SET are the current direction (in degrees) your ship is pointed and the set direction you want it pointed. To make the simulation realistic your ship did not instantaneously change direction. Your thrusters had to rotate it to the new direction.

NRG indicates the amount of energy remaining.

Empire 3 - Commands

Both the photon torpedo and phaser shots were made in the direction of where the ship aimed. The torpedo's direction was the sum of your vector and the initial firing vector (where your ship was pointed) at the time of firing.

As you flew through space your momentum kept you moving in a particular direction (unless you were stopped). You could set the ship rotating and fire torpedoes in a pattern, laying a moving field of death.

Inside the Programming of Empire 3

The Plot Thickens

The following shows the upper portion of the unit (subroutine) that plots the various objects on the screen. [Note: this code was updated from the 1974-75 version in 2005 to use the -loop- command structure which makes for immensely easier use.]

This upper portion of the unit actually shows the section where if the object had been written to your screen this code erases that object. The next half (not shown) the writes the new location. This gives a smooth animating update, but does take more memory and more processing to do. It also takes more screen update time on a slow 1200 baud connection. In the Empire IV design we chose to not worry about the old location; we just erased the entire screen and then plotted the new locations, letting your eye/memory recall the previous location.

This gives a good example of a number of TUTOR elements and also shows how all of the characters looked when displayed. Each ship had eight orientations. You can also see the Doomsday Machine (DDM) which did not show up in Empire until later; it was in the character set I was using to reconstruct this version of Empire and I thought I might want to use it somewhere. There is also a Star Base (line 22) followed by an explosion.

There were not enough character set slots to add a full-sized ship, so I used only eight character slots and designed the small ship. This small ship type was later used as the Orion ship in Empire IV.

Pieces of the Pie

One difficulty in writing complex programs on PLATO was in storing the variables; each user instance only had 150 "student" (local) words and the maximum size of common (global to all program instances) was 1500 words. A "word" on a Control Data Cyber was 60-bits; in the early 1970s a word on an IBM mainframe was typically 32-bits.

150 words per user is 9,000 bits or 1,125 bytes TOTAL. 1,500 global words for the inter-process communication is 90,000 bits or 11,250 bytes. Put another way, that's about 1K for user variables and 10K for inter-process globals. Most pictures on any web page will be somewhat larger than this.

The big problem in the early years was that most of those bits weren't all that usable. When you allocated a single variable, say to be an increment counter, it would take a whole word.

Text was somewhat more efficient in that you could store ten (10) six-bit characters into one word. If your name was ten or fewer characters, it would fit in a single word. I am guessing that the way to access an individual letter in that ten character word was the initial inspiration for the -segment- definition.

If the alphabet is written in memory, the first word would have a, b, c, d, e, f, g, h, i, and j written left-to-right in the word. To get the first character into a position to use it you had to get it to the right-most (lowest) six bits of the word. You could either shift the bits right or left on a Cyber, but you needed to make sure the shift did not extend the sign-bit. Once the target character is in that position, you only had to mask the bottom six bits (o77 in octal) to have only that character remain in a register. Both the circular left shift (CLS) and mask could each take only one processor cycle. This operation would be very fast. (I don't know the exact low-level machine-language instructions to implement the segment on a CDC Cyber.)

Extend that idea to a "segment" of any bit size up to 30-bits. It didn't make sense to have a segment larger than half of one word, because it would take one word for each segment. That's what the -segment- define added.

Example: If you have four teams and you want to indicate which team a player is on, you just define a segment array of two-bits per segment. [Two-bits store four values, 0, 1, 2, and 3. Three-bits store eight values, 0 to 7, which is an octal number.] THIRTY player's team could be stored in a single word, where it would have taken thirty words to do the same thing.

The -segment- define opened up a whole new world of possibilities for game design. Now we could store so many more things.

The first listing I have found in my collection with the -segment- define is my only varian listing, dated October 20, 1974.

See the next section for more discussion on the segment, especially one big problem that happens when using it.