Things Taken Out

Developers Notebook #1
Ideas that had to be taken out

Things I Had to Take Out
With 32K to work with, I couldn’t quite fit everything that I had originally planned. Examples are:

  • Naming your own character. I felt it was a fun interesting touch, but ultimately I decided it didn’t add to the game and was just taking up memory. Actually I also wanted “names” since I envisioned a possibility of uploading names to site, like an old arcade “top score” list (by use of a modem or WiFi adapter for the PET). Perhaps we will try this idea in a future game!
  • Heart Beat: I played the original Dungeons of Daggerath game when it first came out on the Tandy Color Computer II in 1982. Aside from being 3D, the game also had incredible sounds – including a heart beat. As you got more “stressed” the heart would beat faster, to the point you could eventually pass out. If you really over did it (attacking too fast with weapons you weren’t quite ready to wield), you could even die from a heart attack. For DH, I just wanted to simply have some indicator for when your health was low (such as under three HP left), to start flashing the heart (or maybe three states, like a fast, medium, slow). As simple as it sounds, this takes a bit of memory to pull this off (and would cost some graphic performance). NOTE: I’ve somewhat been able to incorporate this idea! The sound-pitch when firing your arrow is proportional to your remaining health.
  • RANDOM-BLESSING: Originally, BLESSINGS were going to give semi-random bonuses. Semi-random in that the effect of the BLESSING was going to analyze what the player NEEDED in the current situation, and then drop or perform something useful in that context. For example, it might STUN all the CHALLENGES in the STAGE temporarily. Or if low on ARROWS, it would give arrows. Or low on HEALTH, it might gift some PERSISTENCY. But, was cut due to memory limitations. To keep the game more consistent, it was decided to just let BLESSINGS “slow down” the creatures (or it can be viewed as “speeding up your character” giving the appearance of everything else moving more slowly). Initially this was only going to last for some number of steps, but it was less code to make the change permanent (for the current stage).
  • STAGE 2: I wanted to have a lantern that you would collect near the rock. It would be optional, but if collected, it would give you longer vision while inside the cave of STAGE 6. Otherwise without the lantern, you would only be able to see about half as far. A clever idea, but again costing too much memory and performance to specialize.
  • STAGE 3: Four direction animation. The “game engine” does support UP/DOWN icons, but is only using LEFT/RIGHT as of now. So the CROCS would “turn” to have UP/DOWN vertical shape. Essentially the idea was the CROCS would patrol up, down, making the whole STAGE somewhat like the old Frogger game – except you’d hop “between” the CROCs, not on top of them. As they “thinned out”, and reached the center island, then they’d change to a LEFT/RIGHT patrol. But basically it just ended up looking silly whenever the icons transitioned between LEFT/RIGHT and UP/DOWN, and do so rather sporadically. It took quite a bit of extra memory also, so it was cut.
  • STAGE 4: Originally the FLIP SKILL wasn’t going to be learned until this STAGE, after the first kill within this STAGE. Since this STAGE has the CHALLENGES coming from all directions, the FLIP SKILL really comes in handy here. The idea being you “inherit” this skill from the persona. I didn’t remove this because of memory constraints itself, but rather that I had no memory to really explain or indicate what had happened (I was going to have a message popup or scroll across the top: “NEW SKILL LEARNED”, but that’s where the cost comes in). I pondered on this quite a bit, eventually settling on the “LEARN FLIP” policy that is in the game now, which is: you LEARN FLIP SKILL after MOVE STEPS+ARROW SHOTS > 200 (but also with a requirement of having fired at least 1 arrow). In this way, you earn the necessary experience through a combination of moving and firing the arrow. Contrast to modern MMO games where you just assign skills, with no backstory or accomplishment to having actually earned that skill.
  • STAGE 5: I was going to depict a dead skeleton on this stage, from which the player could collect GLOVES. These gloves would be enchanted to allow you to move large objects (such as BLOCKS that I was going to have in STAGE 6). Though you could still proceed without the gloves.
  • STAGE 6: The sluaghs were originally kobols, then I changed them to skeletons with two variety – some skeletons would throw spears! I wanted to add moveable blocks to this stage that you could line up and use them to block against the spears, while you dealt with the other skeletons. I had all this working, but again it just took up to much memory as a specialized aspect of a single stage (I’d have to basically remove all the other stages). Also, it was going to be you could shoot these blocks open to reveal TRAPS that you could collect and use in the next stage.
  • STAGE 7: After defeating the challenges, I wanted two statues to appear. The player would have a choice to collect a bonus item from one of the statues (after which both statues would then disappear when one selection was made). One selection would be more MORE ARROWS, the other selection MORE PERSISTENCY. So they could decide what they needed more of to prepare for the final stage. Again, just not enough memory left. Also, originally instead of DRAKES, STAGE 7 was going to be BEARS, and you could use the TRAPS collected from the boxes in STAGE 6 to slow them down (and do 1/2 damage to their HP).
  • STAGE 7: Another STAGE 7 concept was that the DRAKES would “spit” fireballs to a short distance (2-5 spaces, about the length of their own icons). I think it would have ben really fun, and a build up (practice) to what would be experienced in the next STAGE 8. But memory was really tight, something had to give.
  • STAGE 8: Similar to one of the Zelda dungeons, I wanted the HYDRA to have a full body, neck, and I wanted the fireballs to cause the grass to catch on fire (limiting the players mobility). It would have been fun, but again, memory and performance constrained. Also, the original vision of this STAGE included panels on the ground, that would engage traps along the wall. If you could get the HYDRA to follow you, you could use those traps to smash him. But I realized this was unfair to the HYDRA, why would it lair in a location that was to his disadvantage to be at. Plus again, it would cost a lot of code-space to implement.
  • THE NINTH STAGE: There was plans for a 9th STAGE, which would be placed between what ended up as STAGE 7 and STAGE 8. In this STAGE, you would battle against your “opposite” persona (personas are grouped by YONI and LANGI). That is, if you had selected the “2nd YONI” then this STAGE you’d battle against the corresponding “2nd LANGI”, or vice versa). I called this the “mirror” STAGE. The battle would only go until that “opposite” had been defeated to half health, not completely defeated. An interesting STAGE, but when memory first got full, this was the first thing cut — which worked out, as it made the game more balanced into an even number of STAGEs. From the beginning, there was a concept that throughout the game you’d swap between your character and the chosen persona, with that hint that in ancient times your persona was competing against their opposite for some objective.
  • ARROWS: Originally I wanted to make the game quite challenging, making it very difficult to obtain arrows, to the extent that you could GAME OVER by running out of arrows. But I felt these “catastrophic fail” conditions, which were typical of old arcade games (because they wanted your Quarters!), actually just weren’t very fun. I prefer a game where you can take a few hits and keep on going, not 1-shot-fail and start over.
  • WATER: When I first added WATER, I wanted to add a “ripple” effect of the water moving when the player moved within it. Or, to just have a “wave” effect of the water flowing back and forth. I’d do this by just INVERTING the WATER symbol in a coordinated fashion, up until it hit a shore, and then reverse in the other direction. Or just ripple out from where the player had last touched the water. I think it would have been a very interesting effect, and a nice feature for the “game engine” to have (animated map background). But not enough memory or performance to give it a try.

%d bloggers like this: