The first part of a collection of Soft Dorothy Software scraps and game experiments from the late 80's and early 90's.
Around 1988 when I was still in college I wrote my first shareware game on the Macintosh computer called Glider. For a number of years that followed I spent a good deal of my conscious hours (and perhaps unconscious hours as well) programming little games for my amusement. I think the little Macintosh Plus with crisp black and white pixels, curious mouse interface, became a new kind of canvas for me. I don't think I was naturally a programmer, programming was a means to an end — an end I suppose that consisted of little games that I approached as a kind of little art.
To be clear the games had to be fun as well. If you allow at least that computer games have an art aspect we'll agree that games are not the kind of art you hang on the wall.
To that end I often "sketched" out a game, fairly quickly sometimes, to find early on that it was not to be. Perhaps the game seemed like it had potential but it was going to consume a year of my life to write it. Sometimes though the game just wasn't grabbing me — was simply missing something compelling to make it enjoyable.
I suspect my personality is to reject "lost ideas" quickly where someone else might have spent more time trying to nurture them. Perhaps there were in fact some diamonds in the rough. But other ideas were calling and so off I went to the next thumbnail sketch.
Regardless, if only for some of the pixel art, it may have been worth it to me recovering these prototype games and experiments.
The old Macintosh OS (before OS X) used four-character codes to identify each application. These were called bundle identifiers. Beginning with Glider I established a pattern for my own game's bundle identifiers. The first two characters were lower-case: sd while the last two were digits beginning, with Glider, 01.
I found on one of my recovered hard drives a document listing the titles and bundle identifiers I had used. Here is the beginning of the list:
sd01 = Glider v.1.0/2.0/2.02ß/3.0 +++
sd02 = La Luna not distributed
sd03 = Reaction not distributed
sd04 = BlackBox not distributed
sd05 = Paria incomplete <slow, complex>
sdHM = Harmonograph not distributed
sd08 = FishTank not distributed
sd09 = Glypha v.1.0/2.0 +++
sd10 = Mobocracy incomplete <time-consuming>
sd11 = Dione incomplete <no fun>-K
sd12 = Light Cycles incomplete <buggy>-K
sd13 = MiniGolf Edit incomplete
sd14 = MiniGolf Cr incomplete <buggy>
sd15 = K-10 incomplete <sound prob.>
sd16 = War not distributed
:
It begins of course with sd01 for Glider. If you had a Macintosh back in the 1990's you might recognize sd09, Glypha. The bundle identifiers listed in between though, and those following, belonged to programs that never left my hard drive.
To the degree I am able to, this repo represents those "lost" experiments. We'll skip Glider and Glypha from the list — since they shipped they're already in a repo called SoftDorothy-SharewareProjects. And if you missed it, I have also posted my Casady & Greene sources containing the code, artwork, etc. for my commercial games.
These programs are, at this time, completely lost. I had copied over the binaries from one file system to another, over a decade ago, but alas all the resource forks were lost and so to then are the applications.
The dates on the binaries (if correct) suggest that I toyed around with the apps in September, 1989.
It's possible (but I don't remember exactly) that La Luna was my first stab at a game like Elite. Elite had a huge impression on me with its seeming depth and its ability to completely draw me into its world. More than once I would take a stab at doing something like Elite in scale but then shelve it when I realized the time that would be consumed to do it any justice.
Reaction was, to my recollection, more of an educational demo of a nuclear chain reaction. The application showed "neutrons" as a regular grid of circles on the screen. A control allowed the user to change the density of the neutrons (the spacing between neutrons in the grid). With the click of a button the reaction would begin with one neutron disappearing — decomposing into a few energetic neutrons that scattered at random angles from the original neutron's location. If any of the neutrons struck another neutron in the grid before they left it would cause that neutron to also decompose into a few more.
It's possible I was inspired to write the app after reading one of the Computer Recreations articles in Scientific American magazine (example article).
I am a bit at a loss to recall what BlackBox might have been. My best guess is that it may have been similar to a puzzle game where you deduce the location of a number of hidden mirrors in a "black box" (hidden on a grid obscured by a black rectangle) by placing lasers around the perimeter and note where the reflected (?) laser light exits the grid.
Paria was very much an Elite inspired sketch of a game. If you run the game in an emulator, some small amount of activity comes to life with regard to the controls and window. You have to select New Game from the File menu first.
Don't be fooled by all of the menu items in the games that follow — many are in fact merely stubs and do nothing when selected. That's just the nature of quick prototyping.
You're piloting a spaceship (if that's not obvious) — and in this case the ship was made intentionally complicated to add an element of realism to the game and to allow for perhaps some clever (or desperate) energy management strategies to liven up the game.
The left side of the console is concerned with power creation and power reserves (primary, secondary). Weapons (top right, LAS, incomplete), protective energy shields (bottom right) would consume that energy during a fire fight.
Top center is the star map and buttons to the left of it toggle the map display to show other information to aid in navigation.
Below the map/navigation view is your cockpit view out the front of the spacecraft.
Playing with it a bit I see that the +TH button (and ones near it) allow you to adjust your ship velocity. In fact if you throttle up ,eventually you will see a planet approach in the cockpit view.
Before posting a lot of these old sketches, I tried to add a little code to throttle the game somewhat since on modern emulators running "all out" the demos were often unplayable. In the case of Paria the planet flew by so fast I had blinked and missed it.
Clicking the mouse in the cockpit view appears to fire a laser but I am pretty sure it's just stubbed in for show — nothing results from it but a brief dip of your ship's energy reserves.
Even with the barest degree of functionality in the sketch it's clear that many months, perhaps a year or more, would have been required to implement a full and proper game. Text along the bottom hints at an "intelligent" computer assistant that needed flushing out, full 3D navigation with enemy ships, possible trading, would have been required. Abort (ABT), and various radio (RDIO) controls (and perhaps DES was self-destruct) had to be fleshed out as well.
It looks like this one was begun around December, 1989 — more or less abandoned January, 1990.
Could it ultimately have been "Elite-levels" of fun? Who knows. I think though I saw what I had at that point and decided to move along to the next idea. Even a stub of a game like Paria I thought I could always return to at some later date.
Harmonograph was a little experiment of the educational toy variety like Reaction that I described earlier. A pendulum (or multiple) controls the X-axis while another pendulum(s) controls Y-axis. Start kicks off the calculating, rendering.
There was a tool called Prototyper that I picked up about this time and Harmonograph was I believe the first application I created using it. Prototyper made it easy to create windows with controls, text and would then generate the C or Pascal code to give you a shell with which you could then go in and add the functionality.
For Harmonograph icons-as-buttons along the left allow you to increase or decrease the amplitude of the pendulums — modify the frequency, phase. It more or less works — though seems to crash the OS when you quit (ha, ha). I didn't play with it exhaustively though.
This might be a fun one to rewrite for the web using Javascript, an HTML5 Canvas... I would prefer though to have a UI with stacked pendulums where you could pull them back to set the amplitude, slide a weight up and down to change the period....
Like a screen-saver, FishTank was only ever meant to be a virtual fish tank that you kind of watched. Designing your own tank — stocking it with fish you select, arranging the various plants and decorations would have made it somewhat amusing. Tamagotchi-like I might have required you to periodically feed the fish lest they die...
It was shelved long before any of those features saw the light of day. I think the payoff-vs-effort indicator was trending low in my mind for this one so on to the next idea.
Original file dates suggest I started it in December 1989, bailed by March 1990.
Side-scroller, post apocalyptic ... Mobocracy was a very 90's game. Original file dates suggest February and March of 1990 were consumed with knocking this half-baked sketch out.
If you wanted to kick the tires, you can only "play" it by selecting Practice from the File menu. Controls: try A, D, the space bar, the arrow keys. Artwork has our hero with her sword drawn, parrying, thrusting but if those modes are implemented in the code I didn't take the time to discover. There is additional artwork for a kind of "bounty wall", a weapons shop — none of which were ever implemented.
The lower portion of the game hints at a weapon selection, map, an inventory of bullets, gold, etc. (The player's fatigue is expended by jumping, etc., replenishes quickly though.)
This was clearly a game that, whether the payoff was high or not, was clearly going to be a huge effort. Although Prince of Persia (Metal Slug, etc.) would show it was possible, I think I also felt constrained by the almost 1-dimensional aspect of a side-scroller. Maybe I would have felt more comfortable making it a 2-D Rogue-like instead. In any event, there were other fields still to sow.
Dione was not one of those sown fields that would bear fruit. More or less started out as an Asteroids-like. Actually, if you really know your obscure 80's arcade games, it took more inspiration from Space Duel — a game where two players find their Asteroids-like spaceships tethered together creating all manner of fascinating dynamics when each craft can independently rotate, thrust. Watching the linked ships tumble across the screen like a baton in free-fall was, I think, what I was initially going for.
I couldn't have failed any harder. Dione (the name came from Greek mythology) should have been called "Ball and Chain" as that is how the game play feels. If you really want to try it: left and right arrow keys, Shift and space bar.
Is there a diamond in the rough here? Why, no, not at all. Still, Space Duel is still, in my opinion, ripe for really kicking up a notch into the bullet-hell genre. Now that would be something.
Dione was a March, 1990 sketch.
One of the earliest games I had written was a "TRON" light cycle game on the Commodore VIC-20. Maybe I thought I would have a go with it on the Macintosh. In fact, games being as rare in general as they were on the Mac in those days, there wasn't a proper clone.
Light Cycles, should you try to play it in its rough form, is un-throttled and so plays best in an emulator that you can run at 1990 speeds. I must have decided early on to bail on it however as much of the sprite artwork is unimplemented. That's kind of too bad because I would love to see the player "rez" in, see the Recognizer enter the game grid....
This was the first time I thought to tackle miniature golf as a computer game. Like the previous Light Cycles I went with a 2.1-dimensional look. Which is to say, it's more or less a top-down game but I added just a bit of an orthographic shear to it to suggest a hint of 3-dimensionality.
Later, when I began programming in color, I would revisit miniature golf in an unfinished game called LiliPutz.
This early B&W attempt consisted of two separate apps: MiniGolf Editor for creating the courses and MiniGolf Player for, of course, playing them.
I saw that they compiled and ran (added some throttling to MiniGolf Player) but otherwise relied on the course (Course.2) that was my little test course from March of 1990. Try It doesn't work in MiniGolf Editor. Instead you'll have to Open Course... and Begin Game in MiniGolf Player.
Oh, the collision detection is completely broken — balls don't often ricochet correctly off the walls, sometimes end up outside the course. You know, these little things are not terribly important when you're just prototyping a game. I mean these are solvable issues. But if for other reasons the game seems destined for the byte-heap, why bother?
And so I bothered not for MiniGolf. As I mentioned, I would revisit it later, in color. I am unclear as to why I did abandon this version and move on to experiment with new games.
When I get to the color version I can explain why that one was offloaded though.
I was in college at the University of Kansas when I began K-10. It was named for Kansas highway 10 — the more or less straight and flat stretch of asphalt between Lawrence, Kansas and Kansas City. For a driving game that wanted to keep things simple K-10 was a cheap excuse to present only a straight road.
Spy Hunter, the old arcade game, was an obvious inspiration — it too being a top-down driving game where the cars have weapons. Perhaps a little more obscure, I was inspired too by the Steve Jackson Games pen-and-paper RPG Car Wars.
You can see the Car Wars inspiration on the right portion of the game where armor (front, rear, driver and passenger side) is indicated. Fore and aft weapons... Also, like "rolling up a character", the game was to rely heavily on your designing your car, fitting it with the various weapons and armor, engine upgrades — to the degree your car budget allowed.
I was focusing a good deal at this early stage on getting the shifting (the cars were to be all manual) correct. You have to shift into 1st gear to get rolling, watch the RPM gauge, shift to 2nd when you start to red-line. I was trying to get the power curves to feel right so that putting the car in 4th at a stop would be lugging the engine — downshifting to 1st at highway speed would possibly blow the engine.
As with a lot of these "sketches", you can look to some of the placeholder graphical elements or inoperable menu items to get an idea of where I hoped to eventually go with the game. The PICT resource too hints at a cop car, caltrops, mines and other various weapons that might eventually be employed in the game.
I have a vague recollection that the physics involved started to overwhelm me. I was stuck trying to decide if you model the drivetrain physics from the asphalt to the tire (via frictional component) through the transmission and its gearing to the cylinders trying to turn a flywheel? Or do you go the reverse direction and start with the torque from the cylinders firing, work through the transmission, etc? It seemed like a problem where the math had to go both directions at the same time.
Regardless, I seemed to have shelved the game sometime around April, 1990. Is it worth revisiting? Maybe you think Carmageddon finally (and thoroughly) scratched that cars-destroying-other-cars itch but I still think there is room for a top-down "Death Race 2000".
If you decide to try the game out, I have been successful 1) Car —> Open Car... and select a car from the Cars folder then 2) select File —> Test Run. The keys 1, 2, 3, and 4 shift gears (you need to shift to 1st gear right away), the mouse button is the accelerator, moving the mouse left and right is how you steer.
You will probably see an enemy car or two — and they will fire upon you. If I had implemented player weapons I was unable to discover how to fire them. Also, collision detection is very basic.
In this case, War is the card game — I wrote a Mac version of War.
When I was young my sister and I played War all the time. I don't recall any game actually ending though — they seemed to go on endlessly (was that subtle commentary by whoever created the game?).
I was curious if War was ever generally winnable: as one player started to win most of the battles they were in fact adding more lower ranking cards to their hand. The tide seem to then flow and the opposing player seemed to start pulling back the majority of the cards. How long would this seeming cycle repeat itself.
So, somewhat of a joke, I wrote War, making sure to have a computer vs. computer feature so that I could just kick it off and let it run.
I had thought the resource file for this game was lost, but I just found a hard drive from 2013 that has the resource file intact for War (as well as the resource files and projects for a few more of these old games).
I've included also a small project called Game Shell. It is a sort of barebones game project in Pascal with menu set-up, window set-up, some sound routines, graphic functions, etc. It is not a game but is intended to be a starting point when creating a new game. To create a game you are expected to begin by making a copy of the folder and rename the project. After that you go into the project and begin to add your own artwork, game logic etc.
It represents the same code I used over and over again in my games. In this way I was able to pretty quickly try out a new game "sketch".
But wait...! Yeah, there's more to come.
I have enjoyed this little journey. I gather all the pieces together, fix the type/creator codes for the various files, try to open the projects, clear objects, recompile, re-build the applications. Some apps need throttling to make them half-way playable on an emulator. In one app I found and fixed a 35 year old bug that had been corrupting the application space. I look for and gather artwork files I used for the games.... A few games, like War required a good deal more work in reconstructing the project and resource files.
I am surprised though how often I crash the Mac system running within the emulator. Did they really crash this often?
Here is volume 2, Soft Dorothy Software: Unfinished Tales (Vol 2).
John Calhoun—