Lessons Learned
-
Java is inherently concurrent. Early versions of the Java
implementation did not use any synchronization because we (erroneously)
believed that concurrency would be an issue only if we explicitly ran multiple
Java Threads. Early versions were therefore prone to inexplicable failure
on overnight runs on our PCs. The reason behind the failures became apparent
as soon as we attempted to run a multi-SpaceObject game on the 32-CPU NUMA-Q
system at Paul’s workplace. The game failed in the same inexplicable manner,
but within a minute or two. Adding explicit synchronization eliminated
the failures. We ran several overnight test runs on both PCs and on the
32-CPU NUMA-Q system. Paul had to grit his teeth and force himself to use
a simple code-locking design, going against every instinct built up over
ten years of producing highly scalable software. However, this simple locking
design was well-suited to this project.
-
If we were doing this project again, we would probably abstract
out a separate "physics state" object from SpaceObject. This would simplify
the argument lists of many of the methods in the MetricSpace and Gravity
interfaces. It would also make it easier to modify the game to use (for
example) general relativity rather than Newtonian physics.
-
The current implementation of the game has annoying flicker
on many platforms. We attempted to reduce flicker by blacking out the previous
position of each object, then painting the new position, while disabling
repainting of the background color. This was rather complex and difficult
to debug. In addition, it was of no help except in cases where the sun
was stationary. We therefore ripped out the code, greatly reducing display
complexity. If we were doing this again, we would attempt to double-buffer
the display into an image object, then display the resulting image in one
shot.
-
Had we refrained from taking the detour in search of a flicker-free
display, we would likely have had time to implement a drag-and-drop interface
that would allow the players to explicitly set up the game’s initial state.
This would also allow the game to be more easily used as a digital orrery
for investigating orbital dynamics.
-
Write once, test everywhere: but only if you are careful
to use identical versions of Java. Installation from the same CD does not
guarantee the same Java version on different platforms. In particular,
the Mac version of CodeWarrior is behind the PC version.
-
Be sure to appease the Demo Gods (or, if you prefer, be sure
to make appropriate allowances for Murphy’s Law):
-
Freeze your code at least three to four days before
the demo. The "simple" changes made at the last minute will invariably
destroy your demo.
-
Never exercise any capability in your demo
that you have not thoroughly tested beforehand. If you haven’t tested
it, it does not work, no matter how careful and clever you thought you
were.
-
Test your code early in the project on the platform
that is to be used in the demo. (We failed to do this, and recovered only
by bringing in Paul’s desktop PC at the absolute last minute.)
-
Rehearse your demo as if you were rehearsing a part in a
play:
-
Time each portion of your performance.
-
Brutally cut anything that causes you to run overtime.
-
Allow no less than three minutes for every slide in your
presentation.
-
Allow at least five minutes for questions.
-
Have backup hardware available. Rehearse setting it up.
-
Arrive early enough to set up and check out any equipment
that you need for your demo.
If you have not already done so, join your local Toastmasters
club and work toward your CTM.