I'm taking a detour into the past to play a quickie CRPG of ambiguous importance. I wasn't originally going to bother with Dungeon Campaign; although it's one of the earliest RPG-like games available on personal computers, it isn't clear that this or any of Robert C. Clardy's other Apple II games informed anything of note, even if his 1980 Odyssey was glowingly well received by CGW's Scorpia as late as 1993.
Nevertheless, I've toyed with the idea a few times, and just decided to do it - it's an afternoon's investment at most.
Dungeon Campaign, like all Apple II games of this era, was coded in Integer BASIC and distributed on tapes, though no tape versions seem to be dumped. It is directly based on the game "Dragon Maze," which originally existed as a type-in program in the Apple II 1978 reference manual.
I found quite a few disk copies of Dragon Maze on archive.org, most of them modified from the original, but one was authentic as far as I could tell.
 |
| Most copies don't "erase" the picture. |
The dragon isn't very smart and will just walk back and forth if he can't move closer to you, but if this happens too long he will jump over a wall.
The trick to winning is to memorize the maze, which annoyingly vanishes the exact moment that it finishes being generated. It will re-reveal itself as you bump into walls, but if you need to do this, the dragon will certainly jump over a wall and chase you into a corner. The dragon starts near the exit, and since there's only one route, so there's no getting around it. You've got to manipulate the dragon to move away from the exit, and preferably get stuck in an alcove somewhere, or get it to jump a wall so that it follows you while you head directly for the exit. Both techniques only work if you know the exact path to the exit as well as enough walls to manipulate the dragon's movement.
It's not a great game, but it's meant more as a learning exercise than an enjoyable experience in itself, so I'm not bothering to rate it.
Game 216: Dungeon Campaign
I am playing a floppy-based re-release which bundles both Dungeon Campaign and Wilderness campaign.
Dungeon Campaign begins by generating maps for four levels, but there's not much point in paying attention to any but the last. Only the map for the fourth level reveals its exit; the rest have staircases that could be anywhere.
We have 15 adventurers including an elf who warns when traps are near, and a dwarf who updates the map as the dungeon is explored. There are no stats or hitpoints; taking hits in combat or wandering into traps just means people die. The party levels up as a unit and the overall combat effectiveness is equal to this level times the number of surviving adventurers. A melee in which one of the 15 dies but the party gains a level means our overall strength rises from 15 to 28.
You
can jump to avoid traps when the elf warns you are near one, but this
isn't always possible when a junction or corner is trapped, as happened
to me almost right away.
 |
| This confusingly worded "trap" sends you to a random part of another level. |
The
necromancer sent me to level 3, right by the staircase to level 4,
where I encountered 79 ghouls and somehow won at the cost of five
adventurers, though I don't fully understand why, as I only landed a
successful hit once.
The prize was grand, though.
 |
| Add caption |
Before exiting the dungeon, I went back up to level 3, noticed that one of the rooms was highlighted, and searched it for a bit more treasure. Then I returned to level 4 and left, though on the way a spectre entered and killed one more of us.
I replayed two more times, and made more effort to explore the dungeon. Some notes:
- I still don't really get how combat works. When you encounter a group of monsters, it has a total power level, but I don't know what it means. You take turns rolling dice and hitting or missing each other. Whenever they hit you, someone dies. You must hit them multiple times to win, but this number is much smaller than the number of monsters in the group.
- Sometimes you awaken a dragon. It behaves much like the one in Dragon Maze, but if it catches you, then it eats one man and goes away. Climbing stairs de-spawns the dragon.
- Pit traps aren't so bad; they just get you closer to the exit. Unless you're already on the fourth level, in which case one or two people die.
- Gas traps cover a small radius, but are harmless if you walk through the spewed gas quickly enough.
- One time I found a magic sword as a treasure. The magic sword lets you instantly win one combat, at the expense of the sword.
- Another treasure was a treasure map, which revealed the location of all treasure rooms on the current level.
- Returning to a previously explored dungeon floor reveals treasure rooms in any locations you've been to before but haven't searched. This doesn't make much sense to me mechanically and may be a bug.
- The game can crash with an array out of bounds error. This only happened once, and I don't know what causes it.
During
my second replay, I gathered 4200 quadroons on the upper levels and got
my party to reach level 9, but traps and fights started to take their
toll. I escaped with 6 survivors. Was the extra money worth all those
lives? Who knows.
GAB rating: Average. It's simplistic and a little weird, but Dungeon Campaign does what it sets out to do; give the experience of a dungeon crawl in the space of a few minutes.
Robert C. Clardy won't be relevant to Data Driven Gamer again until way into the future of 1989 with J.R.R. Tolkien's War in Middle Earth, and after that not again until 1997 when Synergistic Software produced the Hellfire expansion pack for the original Diablo.
We'll
soon return to our regularly scheduled 1983 programming with a series
of posts on Moria, the Roguelike that would gradually turn into Angband.
I have tried my hand at randomly generating a maze a few times now. It is much harder than you'd think!
ReplyDeleteDo you have any insight into the method Clardy used?
It's pretty primitive and honestly kind of horrifying. Even with 16KB Integer BASIC, there's got to have been a better way than this.
DeleteFirst of all, the maze is 13x13 tiles, and to start, each one is considered to have a wall to the right, below it, and also to be undug. A cursor is then placed somewhere randomly in the maze.
Then there's the maze digging loop.
First step of the loop - the tile at the cursor is marked dug. From the cursor, figure out all the directions that lead to undug tiles. These are the directions we can move to.
Next, we decide whether to dig or move the cursor. If there are no valid moving directions, we move the cursor. If there are three or more valid directions, we dig. Otherwise, there's an 80% chance we dig, and 20% chance we move the cursor.
If we dig, pick a random direction. If you can't dig in that direction, pick randomly again. Once a valid direction is chosen, move the cursor to that tile. If we moved horizontally, then remove the right wall from the leftmost tile. If we moved vertically, then remove the bottom wall from the topmost tile. If we're not done digging, then return to the first step of the digging loop.
If we move the cursor, then pick a random tile. If it's undug, pick a different random tile. Once a dug tile is chosen, go back to the first step of the loop. This part can take an agonizingly long time if the initial tunnel wasn't very long, because the vast majority of tiles are undug and it will just keep randomly picking undug tile after undug tile until it randomly hits one of the few dug ones.
Then we repeat the loop. I'm not entirely sure what ends it - it looks like there's a counter that starts at 169 and decrements with each successful dig, but the maze tends to stop being built well before all 169 tiles are dug.
FWIW, I don't think the general approach is terrible. But the part where the cursor teleports randomly until it finds something viable is scary stuff.
DeleteI'd rewrite it with this logic, which I think should be quite doable in the program constraints:
Pick a random index in the array of maze tiles (FYI, the maze is represented as a linear array of 169 tiles). Check to make sure the tile at this index is dug and also has at least one viable digging direction. If not, then randomly pick a number "1" or "-1." Add this to the index and check to see if the tile there is viable. If not, keep adding to the index until you find one that is (looping from 0 to 169 or vice-versa if needed). Then move the cursor there.
Hi Ahab.
ReplyDeleteDid Dungeon Campaign randomly generate the dungeon for you?
I noticed that in the one I was using, the dungeon layout is the same every time. The file name is,
Dungeon Campaign - Wilderness Campaign (1979-1980)(Synergistic).dsk
and the ones I found on the web were all these. But I found this one:
Dungeon Campaign - Wilderness Campaign (1979-1980)(Synergistic)[a].dsk
This one only has a text and a black background for the title screen where you choose dungeon/wilderness. The zip file size is 71kB where the other one was 43kB. The maze is generated randomly.
The version I used has this filename:
DeleteDungeon_Campaign_Wilderness_Campaign_1980_Synergistic_Software_a.do
Game select screen is white text on black background, and the map is different every time.
It looks like the one you were using uses AppleSoft BASIC instead of Integer BASIC. The RNG in that code is never seeded properly, and will therefore always return the same sequence of pseudorandom numbers, and therefore always generate the same maze. Though if you restart the game without restarting the computer, then the maze will be different.
In Integer BASIC, the RNG can't be seeded and doesn't need to be. If you were to write an Integer BASIC program that called RND(10) ten times and ran it after a hard reset ten times, you'd get ten different sequences. But if you wrote the equivalent in AppleSoft BASIC and did the same, you'd get the same sequence each time. I am guessing that Clardy rewrote Dungeon Campaign in AppleSoft and didn't realize this.
Thank you Ahab, this is quality education I am getting.
DeleteYes, the [a]version with a white text and black background for title screen generates dungeon randomly, and it loads the DOS3.3 and Integer BASIC before the title screen. DOS 3.3 is dated 1983.
When I was looking for a ROM for Apple Beneath Manor, I found 2 copies. One is presumably AppleSoft BASIC and the other is Integer BASIC (it loads Integer BASIC). But the date that appears on the loading screen is couple years after the initial release (1978).
So I thought that Integer BASIC came AFTER AppleSoft BASIC . . . but I was wrong! So the newer language is inferior in this aspect than the old one.
I am a little confused with those dates. So was the game created initially with Integer BASIC, got rewritten in AppleSoft BASIC, but the DOS 3.3(1983) version was written again after that?? The [a]version loads DOS 3.3 and Integer BASIC, but is dated 1983. And the file size is bigger than the AppleSoft BASIC version so I thought the data contains the extra data for Integer BASIC to run on an AppleSoft BASIC machine.
"Thank you Ahab, this is quality education I am getting."
DeleteSo am I!
"When I was looking for a ROM for Apple Beneath Manor, I found 2 copies. One is presumably AppleSoft BASIC and the other is Integer BASIC (it loads Integer BASIC)."
There are two Apple versions of BAM that I know of. The first is by Software Factory, was programmed in Integer BASIC, only supports LORES and ASCII video modes, and was released in 1978 on floppies and cassette. The second is by Quality Software, supports HIRES mode, and according to the manual is made with something called "Galfo Integer Basic compiler." Meaning it's still coded in Integer, but unlike the earlier release it would be compiled into optimized binary code.
MOCAGH has scans for both of these:
https://mocagh.org/loadpage.php?getgame=applemanor
https://mocagh.org/loadpage.php?getgame=applemanor-alt2
You might find CiderPress useful. It can explore disk images and list files as long as they're stored in a file system, which is no guarantee when dealing with Apple software! INT means Integer BASIC, BAS means AppleSoft BASIC, and BIN means binary.
"So the newer language is inferior in this aspect than the old one."
I'm not sure what you mean by that. AppleSoft gives you control over the RNG seed, and Integer BASIC doesn't. In that regard, AppleSoft is more powerful, but Integer is easier to use.
"I am a little confused with those dates. So was the game created initially with Integer BASIC, got rewritten in AppleSoft BASIC, but the DOS 3.3(1983) version was written again after that?? The [a]version loads DOS 3.3 and Integer BASIC, but is dated 1983."
Getting an accurate picture of version timelines is pretty challenging. Apple II games were pirated a lot, and many of the copies you can download are from pirate copies instead of authentic dumps. The only collections I trust for authentic Apple II dumps are 4am, Woz-a-day, and Brutal Deluxe, and I don't see Dungeon Campaign in any of them. I'd guess that any version which supplies DOS 3.3 and Integer BASIC is a pirate copy.
One interesting thing I discovered. 4am does has a "Campaign Trilogy" disk image, and it contains both Integer and AppleSoft versions of Dungeon Campaign. If you boot it on an Apple II, then the dungeons will be different. If you boot it on an Apple II+, then the dungeons will be predetermined.
Thank you so much for sharing your knowledge!
DeleteConcerning BAM, yes I am aware and I think you are referring to the remake Special Edition. I have two different image for the LORES version. One with the INTEGER BASIC appended to it, and the other without it. That was why I made the misunderstanding that INTEGER BASIC must be something newer than what they had in 1978.
"AppleSoft gives you control over the RNG seed, and Integer BASIC doesn't. In that regard, AppleSoft is more powerful, but Integer is easier to use."
Does this mean that there IS a way to randomize the dungeon layout for Dungeon Campaign (AppleSoft version)?
"I have two different image for the LORES version. One with the INTEGER BASIC appended to it, and the other without it."
DeleteOh, okay. Original Apple II's came with Integer BASIC in ROM, so it wasn't necessary for a 1978 game to come with it on the disk. But later models had AppleSoft, so in order to run old Integer BASIC software you had to either have a language card or load it into RAM.
I have a copy with this filename:
Beneath Apple Manor (original 1978 version) (13-sector).nib
It will not run at all on Apple II+ mode, because it needs Integer BASIC and it isn't there.
"Does this mean that there IS a way to randomize the dungeon layout for Dungeon Campaign (AppleSoft version)?"
Sure. At any point after dungeon generation begins, press Ctrl+Reset (Ctrl+C in AppleWin) to stop the game. Then type "RUN." You'll get a new, random dungeon layout.
Doing this in code would require some restructuring though, but the general approach is:
1: Ensure that there has been some keyboard input on the computer since its last boot. Having a "press any key to continue" prompt at the title screen would do.
2: Use PEEK(78) and PEEK(79) to retrieve two pseudo-random bytes.
3: Seed the RNG. E.g. X = RND(-1*PEEK(78)-256*PEEK(79))
If you're curious why Integer BASIC doesn't need step 1, it actually does. But since Dungeon Campaign was originally only distributed on a cassette, that step was already taken care of when the user loaded the program.