![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
It's been interesting running into quirks when examining the retrogame I've been fixated on and turning my attention to its sequel.
Each of the games has 4 dungeon levels to explore, each level loaded in via a template. In the sequel, only the fifth level (they're numbered 5 through 8 consecutively) continues the setting of the first four; the remaining three escalate to mythic proportions severely, with the final level via a story setting up a quest to rescue an ensorceled, sleeping Brynhild from hell.
The game engine has quirky limitations, which seem quite arbitrary compared to modern roguelikes. Dungeon levels/maps are subdivided into hardcoded rectangular rooms, and only one treasure can occupy a room; dropping a second treasure makes it nonexistent. Monsters won't leave any room they're in, no matter how small the room is. There are no more than 60 rooms per dungeon level and no more than 20 different treasure types. The innkeeper/town module does implement haggling when buying gear, but zero credit is given for any used gear; old gear simply ceases to be. One has to refer to a book with treasure descriptions and a table of values to figure out how much one exits the dungeon with; this could have been a copy protection feature, one easily defeated as photocopiers became widely available. Miscellaneous magic items vanished upon return to civilization, a "feature" which was fixed in the sequel.
The sequel's game engine has a few minor updates, like properly tracking money (and treasure sold), but there were clearly some design compromises due to a hard limit on computer memory available at the time and a lack of desire to rewrite the game engine significantly. (GOTO in BASIC was not a friend to readability of code.) All treasure types are hardcoded in the engine, while monster types are dynamically loaded per level. As for game balance, that went out the window in favor of escalation, aspermanent temporary stat boosts and permanent weapon/armor enchantment could be bought outright in town.
Some of the space-saving kludges evident in the code rankle my sensibilities, as the game had originally provoked my own imagination of a generalized game engine where one could run a character through adventure upon adventure, like how D&D modules could be tacked on to a campaign.
Each of the games has 4 dungeon levels to explore, each level loaded in via a template. In the sequel, only the fifth level (they're numbered 5 through 8 consecutively) continues the setting of the first four; the remaining three escalate to mythic proportions severely, with the final level via a story setting up a quest to rescue an ensorceled, sleeping Brynhild from hell.
The game engine has quirky limitations, which seem quite arbitrary compared to modern roguelikes. Dungeon levels/maps are subdivided into hardcoded rectangular rooms, and only one treasure can occupy a room; dropping a second treasure makes it nonexistent. Monsters won't leave any room they're in, no matter how small the room is. There are no more than 60 rooms per dungeon level and no more than 20 different treasure types. The innkeeper/town module does implement haggling when buying gear, but zero credit is given for any used gear; old gear simply ceases to be. One has to refer to a book with treasure descriptions and a table of values to figure out how much one exits the dungeon with; this could have been a copy protection feature, one easily defeated as photocopiers became widely available. Miscellaneous magic items vanished upon return to civilization, a "feature" which was fixed in the sequel.
The sequel's game engine has a few minor updates, like properly tracking money (and treasure sold), but there were clearly some design compromises due to a hard limit on computer memory available at the time and a lack of desire to rewrite the game engine significantly. (GOTO in BASIC was not a friend to readability of code.) All treasure types are hardcoded in the engine, while monster types are dynamically loaded per level. As for game balance, that went out the window in favor of escalation, as
Some of the space-saving kludges evident in the code rankle my sensibilities, as the game had originally provoked my own imagination of a generalized game engine where one could run a character through adventure upon adventure, like how D&D modules could be tacked on to a campaign.
