Sunday, April 28, 2019

Game 60: Rogue

Download any number of Rogue versions here (I will be using Roguelike Restoration Project 3.6.3 DOS DJGPP):
http://coredumpcentral.org/download.html

Games that originated on mainframes have always proven philosophically troublesome for a retrospective approach. What do we count as the original release? They underwent continuous development, and though they lacked discrete “releases” in the sense that all commercial games were at some point considered done and distributed to consumers, these mainframe games were played by somebody at most stages of their development.

Often, the choice of which version should represent the game is limited by what’s available. Zork is listed on Mobygames as a 1977 release, but there are no binary copies out there, and the only extant copy of the source code is from 1979.

In the case of Rogue, one of very few mainframe-born games to achieve whale status, we have many different versions floating around, but the genealogy remains unclear. Rogue is listed on Wikipedia as a 1980 Unix release, with Glenn Wichman and Michael Toy as its original authors. There are three different “Rogue 1.0” versions released for DOS, all mysteriously credited to “Jon Lane” and “Mr. Mctesq was here.” The oldest files inside any of the archives are dated to 1983.

Then there are a few “Rogue 1.1” releases by Lane and Mctesq including source code, and some “.1” releases by Lane again.

The Rogue 1.0 versions have this title screen:



Ingame, it looks like this:



Another page lists various “Rogue 3.6.x” releases and is more consistent in its versioning. The page claims this was the first version ever widely released, in 1981. The earliest version in the list is two source code archives for 3.6, and the earliest binary is a DOS port of 3.6.1.

The 3.6.1 version looks like this:



Between version 1.0’s color graphics, the IBM-ASCII graphics, more extensive ingame help files, more DOS-friendly keyboard commands (such as support for arrow keys), and the 1983 copyright date and credit to Jon Lane, I must conclude that version 1.0 is actually more recent than 3.6.1.

But if this is the case, why is the “new” one designated version 1.0? And why is the filesize of the “old” 3.6.1 five times larger than 1.0, and the file itself much newer, dating to 2000? My guess is that 3.6.1 was compiled for DOS in 2000 using a then-modern compiler which added some bloat to the file, but the source code was relatively unchanged from its state in 1981, except for what was needed to make it work in DOS. And I would guess that the “version 1.0” is merely the first version distributed by Artificial Intelligence Design, and was based on whatever the mainline Rogue branch was like in 1983, but adapted to DOS and built with a more efficient compiler than the 2000 source port of 3.6.1.

Having spent some time with various versions, I’m most satisfied with “Roguelike Restoration Project 3.6.3,” which I think offers the best balance between authenticity to the 1980 original, stability, and convenience. It was built in 2006, but I can’t find anything anachronistic about it (except for support for arrow keys instead of vi-style hjkl, but you can use those too).

There is a big difference between the Windows and DOS versions; the Windows version defaults to a 120x30 character display mode while the DOS version is 80x25, resulting in the Windows version having larger dungeons.

Win32 Rogue and its extra wide dungeons


I don't know which one is more authentic, but I'm sticking with DOS since Rogue is hard enough without having bigger dungeons. I suppose I could get even closer to Rogue’ing like it’s 1980 by getting the 3.6 source code and building/playing in a Unix or BSD environment, but the work/reward ratio seems unworth it.

Incidentally, there's even a z-machine version of Rogue. The fact that it even works is both a testament to the genius of Infocom's coders and to the madness of Roguelike fans.

For my playthrough, there’s the issue of how to deal with Rogue’s permadeath. My policy, which I formulated with Rogue in mind, has always been that savescumming is permissible, but to limit potential abuse, I limit myself to saving only after 30 minutes of earnest, uninterrupted play since my last restore or restart. Rogue, of course, lends its namesake to the category of Roguelikes and more recently Roguelites, games with the distinguishing feature that they do not permit you to restore games in order to undo your mistakes or misfortunes. Rogue wouldn’t be Rogue if you could just rewind the clock after every bad outcome until you finished the game with a series of perfect decisions and dice rolls from start to finish!

I have beaten pedit5 and dnd without any sort of savescumming, but I had to. Those games, as with all PLATO games, can only be played online, with your save files hosted remotely, making it impossible to cheat the system by backing up your saves yourself. Beating them fairly was reasonable because pedit5 is short, and dnd is forgiving of cautious play. DND likewise is designed to remove your save file when you die, but I beat it within my own savescumming allowance, not having the patience to walk on eggshells through yet another early CRPG, not to mention having to deal with all of those horrible teleporters.

Rogue is neither short nor forgiving. Unlike dnd and DND, there is little opportunity to grind for better levels or gear, and doing so can even be hazardous to your health. I played Rogue long ago on my black & white Macintosh, and never came close to finishing it then, but I remember well enough that starving to death was a serious threat.

I don’t know if I can finish this game completely fairly, but I will try. Chester at CRPG Addict beat it fairly as his second RPG, but it took him 90 hours of play over four months. I can’t imagine devoting that kind of time to a game with less content than Baldur's Gate. I will play fairly for a minimum of 6 hours, and then if I’m not bored yet, continue playing fair until then. I expect I’ll be tired of replaying Rogue before beating it, in which case I’ll switch to my standard savescumming rules. I’d rather cheat in this manner than abandon the game unfinished.

Friday, April 26, 2019

Game 59: Mission Asteroid

Read the manual here:
https://www.mocagh.org/loadpage.php?getgame=missionasteroid

Sierra’s last adventure of 1980 is also by far the shortest and easiest. Intended as an introduction to the genre for younger players, it can be beaten in five minutes, even with the very slow screen transitions. It took me barely an hour to finish, including making a full map and taking screenshots and notes, and multiple restarts as it turns out the game has a very strict time limit which affords little allowance for screwing around.

The manual tells us that a minor planet from the asteroid belt jumped its orbit and is headed on a collision course for earth, and as an astronaut, I am assigned the mission of flying to the rogue planetoid and blowing it up before it annihilates all life on earth.

It also laughably asserts that this game will provide “weeks” of adventure.

It all begins outside a building.



That beeping was my watch, which had a switch I could press to receive a message from mission control, to report to the briefing room immediately.



In the building, past the secretary was a junction, which I followed to the east at first, leading to a computer room.

This becomes an Atari and a Commodore computer in the respective ports, but the image remains the same.


I couldn’t use the computer yet, not without the general’s authorization.

More rooms included a supply room stocked with explosives, a gym which let me work out, and a shower room which let me take a shower.

The very end of the junction led to a rocket ship!



Guarded by nobody except a lanky doctor, I could get in and launch all by myself, but then the game ended, telling me I’d be lost in space without a flight plan.

Restarting, I headed east from the junction instead, leading to the briefing room.

…SECRET. THE ASTEROID IS PROJECTED TO STRIKE THE EARTH AT 07:15 TONIGHT.

Sure, of course we can leave earth’s orbit and intercept a planetoid in a little under seven hours.

Directly adjacent to this top secret briefing room is a press room, which the air force thought was a good idea for some reason. You can end the game by talking to them.

...OVER!


With the general’s authorization, you can use the computer to obtain a flight plan.
  • Right for 10 minutes
  • Up for 5 minutes
  • Left for 15 minutes
  • Down for 5 minutes
  • Left for 5 minutes
  • Up for 10 minutes
Sure, that's a good flight plan, because space is two dimensional, inertia isn’t a thing, the asteroid itself won’t be moving, and reaching the asteroid belt from earth orbit in 50 minutes is a completely reasonable expectation, right?

On my way to the ship, the air force doctor stopped me.



So I hit the gym and showers, and the rest was no problem, and I launched myself into space.



The flight plan is a bit convoluted, and time was short, so what if I simplified things? Could I just go left for ten minutes and up for ten minutes?

It worked!


Disembarking in my space suit, after setting the oxygen dial, I stepped out onto the barren asteroid surface.



Soon, I found a cave.



And deeper in the cave was a deep pit.



Here, I found, you must be very precise in the wording. The VERB-NOUN parser is badly suited to express what we’re trying to do here, to set the bomb’s timer to a number of minutes, and then to place the bomb inside the hole.

On top of that, set the timer too short, and you won’t be able to get back to earth safely before the asteroid explodes. If you’re still in space, then flying pieces of the asteroid destroy you. Set the timer too long, and the asteroid will strike earth first.

Unfortunately I had wasted too much time, and didn’t have a chance to get back to earth on time, so I had to restart again. Retreading my steps quickly, I set the timer, planted the bomb, skedaddled back to the rocket, and flew back to earth.



Once again, this isn’t a particularly great game. It’s very short, and there’s not much in it to do except follow directions. The time limit is too strict to allow for experimenting, wandering, or really doing anything except enter in the exact sequence of commands necessary to win the game. The parser is as frustrating as ever, often refusing to accept commands that seem like they should work.

And for such a short game, where it would seem reasonable to expect more polish, both for its brevity and the need to be beginner friendly, it's probably the most unpolished of the three High-Res Adventures. For instance, misusing the rocket ship controls will get you stranded in space, even if you’re not actually in space.

But I never left earth!


Still, there’s still a sense of wonder and thrill as you leave the familiar setting of earth, and explore the strange new asteroid environment, aided much by the use of color graphics. Drifting in space for the first time is tense, as even with directions, there’s no indication whether you’re doing things right nor not, and one wrong move could get you lost in the void forever. The barren asteroid and its view into space isn’t particularly well drawn, but is atmospheric with the grey landscape and blue earth in the horizon, conveying the sense that you are far from home.

My Trizbort map:

Most popular posts