1. Source Code Size
2. Development and Maintenance Costs
3. Performance
4. Accuracy
5. Playability
6. Complexity of Programming Environment
7. Overall Suitability

Source Code Size

The 3312-line Java implementation was surprisingly large compared to the 4001-line PDP-12 implementation. The Java implementation breaks down as follows:
 

Java Implementation
Lines of Code	Class
15	ControlledObject.java
30	Gravity.java
66	GravityInverseNewtonian.java
71	GravityNewtonian.java
53	GravityTerrestrial.java
103	MetricSpace.java
235	MetricSpaceEuclideanBounce.java
690	RemoteControl.java
12	SpaceBackground.java
47	SpaceBackgroundStars.java
61	SpaceGraphics.java
190	SpaceGraphicsFlipCenter.java
67	SpaceMine.java
81	SpaceMissile.java
569	SpaceObject.java
82	SpaceObjectListIterator.java
104	SpaceObjectRegistry.java
45	SpacePoint.java
196	SpaceShip.java
68	SpaceSun.java
187	StartUp.java
340	Universe.java
3312	total

Of these, GravityInverseNewtonian.java, GravityTerrestrial.java, SpaceBackGround.java, and SpaceBackgroundStars.java implement functionality not present in the PDP-12 implementation. Leaving these classes out of the total leaves 3134 lines.

The PDP-12 implementation breaks down as follows:
 

PDP-12 Implementation
Lines of Code	Purpose
29	data tables (header comment)
71	distance tables (radii in various states)
79	squares table
180	sin/cos tables
47	explosion image sequence pointers
1408	bit-vector tables for images of objects
15	program linkage control
37	code (header comment)
7	linkage control
8	PDP-8-mode interrupt entry
38	"function" argument-passing area
16	LINC-12-mode interrupt entry
100	global variables
80	interrupt handler
28	interrupt variables and jump table
57	initialization code
14	main calculation loop
38	variables and jump table
115	read input from switch registers
55	update explosion
108	acceleration, launch, missile explosion
45	release mines
296	gravity and movement
83	arm mines
341	check for collisions
265	invoke display code for all objects
153	mine-array utility functions
17	return to OS
67	display code
53	reciprocal
11	square
61	square root
62	sin/cos and r*sin/r*cos
17	trailer comment
4001	total

The PDP-12 had a legendary reputation for code density, and this example certainly supports the legend. This is especially true when you consider that much of the PDP-12 implementation’s code is provided by Java library classes and by the operating system on which Java runs. When the PDP-12 code implementing arithmetic and interrupts are excluded from consideration, only 3368 lines remain, which is very close to the size of the Java implementation. But it is when the 1408 lines of bit-vector tables are excluded that the true code density of the PDP-12 becomes apparent: only 1960 lines of PDP-12 assembly were required to implement the control, input, and output code, compared to over 3000 lines of Java.

Development and Maintenance Costs

The Java code was much easier to write and debug than was the PDP-12 assembler. Only about 50 hours of time were consumed by the Java implementation, compared to at least 150 hours for the PDP-12 assembly implementation. This is in part because the code required to compute movement had to be written very carefully in order to get the most out of the 12-bit precision available on this machine. Paul McKenney would like to believe that his 23 additional years of experience also helped to reduce the Java implementation’s development.

In addition, the Java implementation is much easier to modify. Of the features in the Java implementation beyond the basic game, the following would have required major changes to the PDP-12 implementation:

1. Multiple suns in mutual orbit.
2. Collisions causing suns to explode.
3. "Terrestrial" gravity, which simulates the mutual gravitational interactions occurring near the surface of an unbelievably large and massive planet. However, negative gravity was all too easy in the PDP-12 implementation—leaving out a single "CMA IAC" instruction is sufficient, as Paul McKenney and his lab partner saw in an early version.
4. Sticky collisions.
5. Conservation of angular momentum.
6. Simulated speed blur.
7. Boundary marker. Although it would have been easy to simply add the boundary points to the display list for the Sun, displaying a boundary would have caused a substantial performance impact.
8. Color. The monochrome display on the PDP-12 was incapable of color.

Acolytes of Moore’s law may be surprised to learn that the PDP-12 implementation is about twice as fast as the Java implementation. The hardware and software performance tradeoffs are as follows:
 

Performance Aspect	PDP-12	Java	Java/PDP-12 Ratio
CPU MHz	0.625	166	266
Memory Access MHz	0.625	7	11
Memory	6KB (4KW)	64MB	10,667

However, the PDP-12 implementation was written in tightly-coded assembly language, while the Java version compiled to interpreted byte codes. Therefore, the calculation time-step was 100ms in the Java implementation, compared to 50ms in the PDP-12 implementation. We added speed blur to the Java implementation to preserve the illusion of motion despite the slow update rate.

Acolytes of Moore’s law might point out that present-day hardware (1GHz processors as opposed to the 166MHz Pentium on which the Java measurements were taken) should allow the Java implementation to easily outperform the PDP-12 implementation.

Accuracy

The PDP-12 implementation used 12-bit arithmetic, which resulted in significant roundoff error. This roundoff error caused even mildly elliptical orbits to precess and decay quickly enough to be visible to the naked eye. In contrast, the Java implementation uses 64-bit IEEE floating point. Although there is some precession due to the simple use of Euler’s method to evaluate the gravitational equations, it is necessary to mark the point on the screen to see the precession. An extremely elliptical orbit precesses about 2 degrees per minute in the Java implementation, which is a great improvement over the 10-degrees-per-second precession of the PDP-12 implementation.

Playability

The PDP-12 version’s controls were a switch register that was directly sensed by the CPU. This made for very tight controls that allowed players to get predictable results with sequences of switch manipulations.

The Java version’s controls (mouse and keyboard) are quite sloppy by comparison. The mouse is especially bad, since it requires the player to shift his eyes from the display. Both mouse and keyboard suffer from the software overhead exacted by the OS and by Java. Although slowing the game down to 10Hz from the PDP-12’s 20Hz helps, further improvement would likely require that control input ramp up, rather than being the current step function. Such ramping would allow players to reliably give the ships delicate nudges, while still permitting full power over longer time periods.

Complexity of Programming Environment

A comprehensive quick reference for the PDP-12 environment filled 11 sides of 8.5x11 paper. In contrast, the same level of detail on the Java language environment fills no fewer than 648 pages, without covering either AWT or Swing. Of course, Java’s documentation complexity is the inevitable price paid for a higher-level language. Even "small" languages like Smalltalk or Lisp require large quantities of documentation to cover their extensive libraries.

Overall Suitability

The PDP-12 implementation was a reasonably impressive game for its day. The Java version did attract Paul’s kids’ attention, however, after about an hour of play, they were thoroughly bored with it. They then went back to their Nintendo and Windows games, which have very complex graphics and story lines. So even though software productivity appears to have increased roughly three-fold over the past 23 years, the demand for software functionality and complexity has increased by orders of magnitude.

The "software crisis" thus appears to be due to growing demand rather than to constant productivity.