Move Fast and Abandon Things
Almost-Rans
Maybe it’s the change of weather. Fall often finds me looking backward, to the past — and anyway it is as good excuse as any as to why I have found myself peering into old hard drives trying to recover old bits and bytes from games that I wrote some thirty-five years ago or so.
Shareware games that I released all those years ago I gathered onto a disk image and posted to GitHub as Soft Dorothy Software — Early Shareware Projects. I wrote about the sometimes extraordinary work I needed to employ in order to recover some of these in a blog post.
The disk image is the kind you can drag to a 68K or PPC Mac emulator such as Basilisk II, Sheepshaver or MiniVMac.
I followed up the shareware disk image with a disk image of Casady & Greene Projects. Casady & Greene was the name of the company that published my Glider 4.0 game back in 1991 and so the sources and build tools used to create Glider 4.0 are on that disk image.
The thing that I enjoyed the most about this trip down memory lane was rediscovering and revisiting the almost-rans. While the paper airplane game I released is what people might know, there were plenty of game experiments that never even made it beyond the Hello World stage — for various reasons. What I rediscovered on the old hard drives were many of those early experiments. In trying to recover them, get them to compile again, I was reminded that there are so many indefinable things that go into making a good game. Some of these abandoned experiments may in fact have been gems in the rough had I spent a little more time trying to facet them, polish them. Or maybe not.
Move Fast
I was really excited to also find a document that I had created in 1991 or so listing the games and “creator codes” that I had used in these games. Creator codes were like a very crude “bundle identifier” back in the pre-OS-X era of the Macintosh. They were supposed to be unique from all other application creator codes. The document is interesting to me today because in it I had cataloged the projects that I had worked on up to that point.
What follows is the list I created containing a creator code followed by the name and then the state of the game:
Out of twenty-seven titles, five of them I released (highlighted above). What were the other applications? Quick prototypes. And these represent the projects over about an eighteen-month period. (At the time I created this list I was apparently “working on” three titles.)
I guess to be precise, I did release UnMask — a utility I spent ten minutes writing. I would dismiss it from the data though.
I was very prolific during that time — staying up well past midnight coding every night. I also developed a kind of “shell” for the type of sprite-based games that I was experimenting with so that the cost of a new “sketch”, a prototype game, was primarily paid for in MacPaint — creating the sprites, artwork. A little code for unique input methods, some game mechanics or physics would also be needed. Sounds, high scores, saved games — these are the things we could kick down the road, implement only for the deserving games.
But I was developing a methodology of prototyping ideas quickly in order to determine (quickly) if an idea had legs — if it stuck to the wall so to speak.
Prototype Things
Games are funny things. When I consider games that I liked, the reasons the game hooked me are often nuanced. I’m not sure you can just set out and make a good game. Serendipity seems to plays a role. Or maybe it’s just that I have found myself unable to just conjure up a great game the first go.
Want to know if a kite-fighting game would be fun? Knock out enough of the game in a few days to where you can play with the physics and control of the kite. If flying the kite is too difficult to master, probably no one is going to enjoy the game. On the other hand if just flying the kite is fun, even without the combat element, you’re probably on to something.
Maybe you have played the arcade game, Joust. Even before enemies rez in it was fun just hitting the flap button to fly — sometimes having to pace your flapping, sometimes flapping frenetically to climb quickly. Quite fun.
I found that a simple game where a paper airplane in a cluttered house had to make use of floor vents to get lift was kind of fun as well — even before you realize you should be making progress through the rooms and avoiding toast or whatever.
But as I say, there’s only one way to find out if what you thought would be fun on paper is in fact fun.
Abandon Them
Some games make it out of the starting gate but then you find there’s nowhere to go with the game. In my list at the top of this post I had brutally noted <no point> for some games. Like the platformer game I began, Thief of Baghdad, where you could ride a magic carpet and leap about. That was kind of fun, but … then what?
Consider too that I was a solitary programmer. So some games seemed to have potential but it became clear very quickly that I would need to invest a year or more to get the game to a finished state. I loved Dungeons and Dragons and would have loved to write a sprite-based adventure game. But, man, when I consider all the sprite-work that would be required for the player, wielding all the weapons they might wield, all the monsters and their moves, all the spell effects, etc. Never mind coding all the spells, varied combat, etc.
Not Really Dead
But this is not a case of The Marriage Problem, you can always go back and revisit a game you had previously shelved. (Assuming you can still find the sources, resources, and project files.) I did revisit Thief of Baghdad eighteen or so months later (in color and renamed Scheherazade) and it even started to get “a point”.
Alas though, maybe you can’t go back after all — or perhaps should not. While I got further with the game in its second incarnation, it never really attained that indescribable something and so was abandoned again.
Never mind that you can also harvest code from any of your shelved projects. I mean why rewrite the Fisher–Yates shuffle algorithm if you have it already in a shelved game? Code for switching the monitor depth (on those early Macs) I moved from game to game… Polygon-point collision code, a sine lookup-table for quick trig functions, a dot-product routine, cross-product routines…
I never regarded these prototyping efforts as wasted ones.
Salaryman
The era of the indie Mac game developer felt to me like it was coming to a close as the 1990’s decade proceeded. In any event when I was presented with a job offer to come out to California and work at Apple I eagerly took it — even though I understood that from that point on I would not be allowed to work on non-Apple projects in my spare time.
Not strictly true — to code outside of work though you did have to get written permission from management. I mean it’s part of that whole non-compete clause — tech companies having been burned throughout history by employees creating start-ups that eventually take over their business. Apple was not in the games business so perhaps I would have gotten a pass. It’s that fear that: what if I ask for permission and they say no?
Finding myself in a world of whiteboards and conference rooms made no difference — I found that I continued to take a quick-prototyping approach to any project that landed on my desk (though, perhaps needless to say, the projects were no longer games).
Other programmers that I worked with (maybe I should call them software engineers) designed software. And they made better use of the whiteboards than I did. Rather than iterate at compile-time like I was want to do, they would instead carefully plan and design their software before ever typing a line of code — iterating I suppose on a whiteboard.
From my approach of diving in rather than planning I began to regard myself at Apple as a “blue-collar” programmer working among “white-collar” professionals (imposter syndrome maybe?). But to give myself some credit, after having written code for seven years or so at this point, my instinct as to which direction to dive in with a task was at least an informed one.
There’s a guy on GitHub, his status is “I am typing on the keyboard to do the job.” Story of my life — I like it.
No doubt though, often enough, this freewheeling approach might send me into the weeds. But with the speed at which I pulled the code together, I often found the bottlenecks fairly quickly — quick enough that I could more or less start the whole project over. If you find this narrator reliable, I will say that I often would start and then restart a project perhaps three times and, when all was said and done, have the project in as good a state at about the same time that my white-collar cohorts would have their more carefully designed code also running.
So was the whole exercise of my guerilla programming technique a wash? Maybe. But it always served me well (or was perhaps the only way I knew to program effectively). Often though my last code revision was in fact to simplify the code — generally to make it easier to follow, easier to understand, easier to maintain. (The insight on how at last to organize the code having come out of treating the whole thing as wildly mutable from the beginning.)
There were times too when a coworker might have said, “You should have used a Bloom Filter” and I was able to come back with, “Yeah, already tried that but the typical data we are seeing is so small that the performance gains were negligible and added unnecessary complexity to the code base so I tossed it.” Boom!
(Okay, maybe something like that happened only once — but it was awesome when it did!)
A.B.I.
By the time I finally retired I had slowly come around to feeling like I had in fact been a contributing employee at Apple. To be clear, it was important to me to be a contributing co-worker really. The engineers on the teams that I worked on were the highlight of working as a salaryman (no longer coding solo in a monitor-lit corner of the bedroom all night). I worked with the smartest people I have ever come to know. There were people I worked with that were an order of magnitude better programmer than I will ever be. And it was important to me to feel like I was helping too in my way.
I think I did rank among the fastest programmers. (Is that a category?) You wanted something prototyped to show as a demo for a meeting this week, I’ll have two versions for you then (one with and without a Bloom Filter, ha ha).
And this bit is for my daughters. I have always told them growing up, “A. B. I.”
“‘A’ — Always. ‘B’ — Be. ‘I’ — Iterating.”
“Always Be Iterating.”
I put together disk images of these games-that-never-were — projects, sources, tools — and posted them to GitHub. The pixel art of that early Macintosh era, especially the B&W era, resonates with nostalgia for a lot of people. There might too be a lesson to game devs in all the times that a game has not launched. For me, as I stated at the outset, I assembled these relics for the memories — or maybe to close that chapter.
I have posted the disk images I have assembled to date as Soft Dorothy Software: Unfinished Tales (Vol. 1) and Soft Dorothy Software: Unfinished Tales (Vol. 2).
There will be a Volume 3. It’s a bit of work though to get each project in shape for “release” so I can’t promise when a follow-on volume will appear.
