Previous Post: What Did 'Better' Mean?
1982-83. In designing Dino Eggs for the Apple II, I wanted to make it much better than my first game Crisis Mountain, as I discussed in my previous post.
No one knew anything. People were trying to figure out what computer games were – and what made the good ones good.
Suddenly, a new concept swept the infant industry: The number of screens is what makes a good game... "Few Screens Bad. More Screens Good."
The catalyst for this burst of wisdom was Miner 2049’er, a best-selling game with a stunning ten distinct screens of game play.
Visual Variety. People told me that Crisis Mountain had only two screens of game play. Well, sort of. It had two background designs on which the player faced randomly-placed objects and a dozen or so increasingly-difficult skill levels. (The glowing orange rocks didn’t appear until skill level 3. The giant boulder and Bertrum – the crazed radioactive bat – didn’t appear until skill level 5.)
I don’t sound defensive, do I? :-)
But I had to admit that Crisis Mountain had only two distinct background screens. For the record: I designed a third background for a ColecoVision version of Crisis Mountain, but for a variety of reasons, that port was never completed. (ColecoVision arrived in a frenzy, and the bubble burst just as quickly.)
The third (unpublished) background screen I designed for Crisis Mountain
So, while I was designing the screen architecture for Dino Eggs, the logic was inescapable: If ten screens are better than two, then surely an infinite number of screens is better than ten. Right?
I wrote a screen-generation routine that randomly determined where every non-living object on the next Dino Eggs screen would go – walkable ledges, jumpable gaps between ledges, vertical steps, boulders, exposed eggs, pieces of wood, and power flowers. In general, the current skill level in the game determined the number of each type of object required for the next screen, and then random numbers determined where on the screen those objects would go.
Except that a completely-random screen would be unplayable. So, I defined what a “playable” screen meant (Time Master Tim had to be able to get everywhere, steps had to be connected to ledges, there could be no mixing ledges and gaps at the edge of the screen, etc.)
And then – it was a brute-force routine. The code created a screen randomly and tested it for “playability.” If that screen failed the test, the code tossed it away and began again from scratch.
I knew that the success of this approach required walking a fine line. If the “playability” tests were too lax, the game wouldn’t be fair to the player. If they were too strict, the code might take too long to come up with an acceptable play screen. And the multiplicity of randomness-upon-randomness was begging for problems, increasing the chance that some obscure bug (or combination of randomly-generated extremes) could lock the code into an infinite loop and freeze the computer.
So -- many evenings I left my Apple II computer stay on, running the screen-generation routine overnight in a test loop creating with screen after screen after screen -- while I slept. I couldn’t judge the “playability” factor in that way, but I could smoke out any critical bugs or fatal freezes caused by random conditions.
It worked. I’ve never tallied out how many different Dino Eggs screens are possible, but it’s a lot. I used random numbers to an extreme and lived to tell the tale.
Note: In my second post, I mentioned my discovery that there is no such thing as a random number, which is true. A computer does various kinds of hand-waving to create an effectively unpredictable number on request, but the result is never truly random. I’m just using the word “random” here because it is clumsy to keep using the phrase “effectively unpredictable number” over and over.
One more note on random numbers in Dino Eggs: The game doesn’t “know” what is beneath a boulder until you kick it over. The code assigns the number of eggs (or piece of wood) that is under the boulder at the moment it is kicked over, not before. And because the player’s own joystick movements re-seed my random number generator, it can be said that the player is creating his own game screen as he goes along. He just can’t control the specific results. (The philosophical implications of this are staggering!)
This paper sketch of the Dino Eggs screen reveals many of my early thoughts on game design. Some of these ideas came to fruition. Some did not. Some are only now being realized in the game’s revival Dino Eggs: Rebirth.
Note at upper left: “PDL...” refers to the early Apple II game paddle. My first game Crisis Mountain had required only that Pong-like paddle – because no one thought enough folks had joysticks to rely solely on them. How quickly that would change. But -- as of this sketch -- I was still considering a Single Paddle/Keyboard mode for Dino Eggs.
The big right-corner arrows: I was thinking of Spiders going horizontally along the top, then threading down vertically. That I did. I was also thinking of roaches going vertically (going up) and then going horizontally on the ledges. That I didn’t do. Also note the idea: “Roaches eat wood (!)”
Note at center bottom: “falling eggs...” In the original Dino Eggs, the eggs disappeared after you picked them up. In the game revival Dino Eggs: Rebirth , you can see the towering (teetering) pile of eggs in your arms, and they visibly scatter and fall if you get bitten by a snake or spider.
Note toward upper right: “falling rolling rock can put out fire?” You bet it can. And in the game revival, boulders can also snuff out the new tar pit fires -- but only temporarily.
Notice the sideways (horizontally-stacked) eggs under boulders. Never did this.
Note toward upper left: "Spiders on any level?" Finally, in Dino Eggs: Rebirth, we have swarms of spiders emerging from spider nests on many ledges at once -- not just at the top of the screen.
Note toward lower right: "pterodactyl eggs..." Now in the game revival, we have two species of flying baby dinos that come out of big fat eggs.
Note toward center left: "can be negative scoring..." As I wrote in my previous post, I think this is a big part of the distinctive (dark) appeal of the game.
And now, I must address the elephant in the room. Well, not an elephant, but a very large foot. Dino Mom’s foot.
Dino Mom is not pleased to see Time Master Tim taking her eggs and whisking them away into the 20th century. We know, of course, that Tim has a noble purpose – to save the dinosaurs as a species from extinction. But Moms (especially Dino Moms) tend not to think in terms of species, but in terms of “My Babies!!!” So, unless you have started a fire to scare her away, she puts her foot down.
I must acknowledge that my inspiration for Dino Mom was Marv Newland’s short film “Bambi versus Godzilla” (1969) – an indie classic that we showed often during my years with the Yale Film Society.
Thank you, Mr. Newland.
In turn, it seems that Dino Mom’s appearance in Dino Eggs has been an inspiration for many others. I’ve received many emails describing how mind-blowing her appearance was. People hadn’t seen anything that big or threatening on a computer screen before. It seemed to push the Apple II and its 6502 machine code to its limits.
After all these years, why does Dino Mom work so well?
- She is powerfully occasional. She appears regularly enough to be a major component of the game, but rarely enough so that her entrances (especially the first one) have a gut-kick rhythm.
- I polished my graphic routines so that the core loops are as fast as they can be. (For example, the weird addressing scheme of the Apple II hi-res graphic screen is flattened into static tables of two-byte values, so that as little as possible needs to be recalculated on the fly.)
- Time management. For each frame of the game – for each object or creature that might need to be drawn – I either draw that object/creature, or call a “wait loop” that twiddles its thumbs for roughly the number of cycles it would’ve taken to draw that object/creature. In this way, I maintain a more consistent frame rate – but I can also cheat a bit. Dino Mom doesn't have her own “wait loop” for when she isn’t on the screen – so that when she is, I “borrow” time from all the other non-existent-creature wait loops.
- Poetic License. Sometimes (especially at higher skill levels), there are so many creatures on screen at the same time that the “time borrowing” method I describe above isn’t available for Dino Mom. And so, sometimes the game does slow down a bit as her foot descends. I worked to keep this slow-down within the realm of a cinematic effect, as movies so often do in the thick of an intense action sequence.
- She’s a good joke – a great punch line – just like Godzilla’s foot is in “Bambi versus Godzilla” or like the falling 16-ton weight was in the early Monty Python television shows. Somehow this joke plays beautifully against the earnest nobility of Time Master Tim's quest to save the Dinosaurs from extinction.
Meanwhile – beyond all of my ambitions for Dino Eggs – lurked the biggest question of all:
How am I going to fit all of this into 48K of memory?
To be continued...
Next post: How Much is 48K?