I had a great time talking with Anatoly of the DOS Nostalgia Podcast a few days ago, and what do you know, I’m capable of speaking into a microphone. We spoke mostly about the first decade of PC gaming, and conclude with some games that were notable for being so well-programmed that they perform some amazing things on your 8088 that it really has no business doing. Snag the episode here, and let him know what you think.
Archive for the ‘Gaming’ Category
Posted by Jim Leonard on September 7, 2013
Someone with a lot more patience and dedication than myself reviewed a game that I always felt should have some sort of coverage: Echelon. It’s one of those games that was more of a tech demo than a game, a phenomenon that occurred often in the first 20 years of personal computer gaming. Echelon was essentially Access flexing their programming muscles, first with a 3-D flight sim and, in a later revision, continuous digitized sound and speech from the internal PC speaker (on any 286 or higher, otherwise it pauses the system while audio is playing). They loved this idea so much that Mean Streets was originally going to be a spiritual sequel to Echelon, with a better flight sim. Thankfully, Mean Streets also had an adventure game built around the flight sim that was much more enjoyable, so that’s why subsequent games are known as Tex Murphy adventures and not flight sims.
Gemini’s review of Echelon is likely the only review anyone will ever see of this game, so I recommend you check it out. And the next time you have a rainy day you should also check out the other 120 (!) episodes of his DOS-era game review show Ancient DOS Games.
Posted by Jim Leonard on April 21, 2013
I was part of the first wave of people tackling the gigantic task of preserving personal computing gaming history in the early 1990s. (I suppose pirating software in the 1980s counts too, but scanning materials and interviewing people began, for me, in the 1990s.) Without connecting to others or knowing what was out there, I started to hoard software and hardware where financially possible and appropriate. I collected software I considered hidden gems, that should be given their due in some public forum before being forgotten. I grabbed many Tandy 1000s and other early PCs to ensure various works could be run and studied. I was an original member of the abandonware movement. I wrote articles on how to get old software running on modern machines, and contributed to software that did the same. I co-founded the world’s largest gaming database so that information about these works could be consumed and researched by millions.
I did this all before Y2K. When you’re the only guy shouting in a crowd, you tend to look the lunatic, and that’s pretty much how most of my friends and family saw me.
Look around the preservation landscape today and much of what I was working towards for years has come to pass. There are many vintage hardware and software museums, both physical and virtual, including some dedicated to gaming. There are some wonderful emulators that get closer and closer to the real thing each year. There are even some curated collections online. (There are many more curated collections offline, orders of magnitude larger than what is online, but in a decade or so I believe these will move online as well.) Most importantly, there are established communities that support these efforts. All in all, I’m pretty happy with how things have turned out.
Looking around all of my possessions inside my home, I see the fallout of what I was trying to accomplish many years ago. I see no less than five PCjrs, three identical Tandy 1000s, three identical IBM PC 5150s, and multiples of Macs, Apples, C64s, and Amigas. I see crates and bookshelves and closets filled with hardware and software. I see clutter where there should be a nice desk for displaying a computer in a respectful way, or an easy chair for reading or watching TV. It’s too much. It’s time to let most of it go, and focus like a laser on the things that are the most important. I will be disseminating most of my collection, both software and hardware, in the following year.
What I will continue to do, however, is archive and preserve software, as there is still a ton of IBM PC software from the 1980s that has not yet been released into the wild. I am also committed to creating the “sound card museum” project I keep threatening to do. To those ends, I will retain a few systems that will allow me to achieve both of those goals.
So, I’ll still keep buying and collecting vintage software — the difference is, I won’t retain the software after preserving it. Consider me a vintage personal computing clearing house.
Posted by Jim Leonard on September 27, 2012
A fellow vintage computer enthusiast recently asked a group of like-minded hobbyists if they use emulation (ie. running a program that simulates a vintage computer, as opposed to using a vintage computer directly) and, if so, what they use emulation for. Having used, owned, programmed on, and contributed to emulators for very many machines over a long period of time, I had a lot to say. What follows is a slightly expanded version of what I replied back to him. For the purpose of this article, I define “emulation” as “interacting with software running in a virtual environment that mimics the physical environment the software was originally designed to run under“. I also define a “work” as the software you are running in said environment, and is not limited to games (although most emulators are indeed used overwhelmingly for gaming).
For the TL;DR crowd: You need both vintage hardware and emulation to properly research something.
I’ve contributed to a few emulators in varying capacities over the last decade, and in that time, some of my emulation colleagues have expressed surprise when I mention that I have a large collection of functional vintage machinery (both personal computing as well as console gaming) hiding in my crawlspace, and that I rotate pieces in and out on a regular basis for both enjoyment and research. This is not a statement against emulation; some emulators are packed with features that make interacting with the original works very easy and flexible (such as DOSBox, MESS, and MAME) while others are dedicated to accuracy to extreme levels (such as bsnes). The state of most emulation scenes today is thriving and most emulators are quite stable and practical to use as a replacement for the real thing.
So if that’s the case, why maintain so many physical machines? It’s because emulation can only go so far. No matter how good the emulation is, you can’t change the fact that you are running a work on a physically different computer than what it was designed for. For most works, this is perfectly acceptable, but there will always be something missing no matter how good the emulator is. In my vintage computing research, I use a mixture of both emulation and real machines so that I can reap the benefits of both. To illustrate this, I’m going to explain the advantages of both emulators and vintage hardware.
Vintage Hardware Advantages
People who never had access to vintage hardware, and always have success running software inside their emulators, sometimes can’t understand what is missing when you emulate, even using one as hyper-accurate as bsnes. Most emualtors handle the obvious (CPU and Video display subsystem) well, because those are required for basic operation; they also handle CPU “speed” and system timing well, as mishandling them would prevent performance-sensitive software from running properly. So what’s missing? Here’s a short list:
- Video display properties: Color temperature, screen curvature, scanlines, response time, phosphor layout, phosphor speed. All of these are important, some more than others. Vintage game graphics were composed with all of these properties in mind, from color choices down to individual pixel placement by the artist. If you are viewing a classic game’s graphics on a progressive display, the end result can be either too bright or too dim, over-saturated or under-saturated — no matter the outcome, it’s definitely not what the artist intended. Thankfully, this is changing thanks to ever-increasing GPU power in the form of plug-in shaders. But as awesome as modern shaders are, they can’t overdrive hardware. Anyone doing serious research on vector arcade games absolutely must see at least one in person to get a feel for just how bright and intense the vectors can be. (I personally recommend the mint-condition Asteroids currently operating at the Galloping Ghost arcade — very bright, currently no burn-in.)
- Interface properties: Input device layout, button placement, tension/stiffness, etc. This is just as important for computer emulation than game console emulation, because computers have input devices specialized for general-purpose computing (keyboards, mice) and not gaming. For example, some games on the PC used F9 and F10 for lateral movement in games, which initially doesn’t make any sense until you look at a vintage 83-key PC keyboard and see that F9/F10 were located at the very lower-left of the keyboard — optimal placement for gaming with the left hand. And younger Mac users may wonder why classic mac games only use a single button until they physically see why. This is most easily fixed by connecting vintage input devices directly to the machine performing the emulation, although such connections can range from a commercial adapter to a homebrew wire-wrapped monstrosity. But it’s worth the effort, so that you can see why Intellivision or Colecovision games require you to quickly navigate menus using the 1, 3, 7, and 9 keys (look at the controllers, you’ll see what I mean).
- I/O properties: Because most emulation research is in the field of gaming, little attention is paid to emulating I/O as it was on the original hardware, such as the speed of the storage subsystem, any noise it made, and so on. (In fact, most emulators attempt to speed up I/O as much as possible so that programs load much faster than they did on the original hardware.) Some emulators make noise, such as WinUAE, but the overwhelming majority do not, and I think that’s a shame. For gaming, I/O isn’t usually a concern, but for any historical research, it can provide a visceral response that would otherwise be missing.
This last one is hard to understand, so I’ll provide a real-world example: When playing the game Wizardry on a real Apple II or IBM PC, it loads from a single floppy disk frequently while the game progresses, to load new graphics, maze data, etc. due to the computer’s memory being smaller than what a floppy disk holds. Wizardry is a role-playing game, which lends itself to repetitive tasks: Enter dungeon, explore new area, fight party of monsters, etc. As you play Wizardry on these systems, you begin to recognize, either consciously or subconsciously the floppy disk access patterns — the “whirr, thunk, buzz” noises coming from the drive — for these repetitive tasks as the game runs. Open a chest, “thunk”; go down a level, “thunk-THUNK whirr thunk”, you get the idea. Now, imagine that your party is wounded and desperately heading to get to the surface to heal, while navigating an unfamiliar dungeon trying to avoid conflicts. You K)ick down a door, and instead of the familiar “whirr thunk” of finding an empty room, or “whirr buzz thunk” of finding a chest, you hear “whirr buzz thunk-thunk BUZZ THUNK THUNK-THUNK-THUNK-THUNK” and realize, with growing horror, that the game is loading a lot more data than usual because it is trying to put a bone-crushing, game-ending party of monsters behind that door. But my example doesn’t end there! Not only is the I/O subsystem contributing to a real feeling of anxiety and dread, but it is also offering you a choice: If you act quickly enough, you can “dive for the drive” and pull the floppy disk out, preventing the game from loading the data it needs to seal your party’s fate. This works because Wizardry only saves your progress at two places: When you die (which in this example is in about two seconds from now), or out of the dungeon, back in town. Ripping the disk out means you unfortunately lose your progress since the last time you saved, but more importantly it cheats death — and in Wizardry, death is (mostly) permanent, even across saved games.
For vintage gaming research, emulation provides many benefits that the original hardware would struggle with, or in some cases, are impossible. My favorite emulation advantages are, in order of importance (to me):
- Instant searching. Software loads quickly while emulated, so you can sample one game a minute, faster if you’re organized and a quick typist. This is great if you’re trying to blow through 50+ games looking for something (a game character, a programmer or graphics artist in the credits, a specific gameplay mechanic, etc.) Handy for answering quick historical questions.
- Interchangeable hardware. For PC emulation, any combination of video and sound standards can be quickly loaded and tested. Trying to do this with vintage hardware is time consuming and very costly (you try buying every single vintage sound card ever made from ebay!) My most common use of this is listening to all of the different ways a composer tried to optimize a game score for a specific hardware device. For example, load a game that uses 8-note polyphony with a MIDI device, and then load it again with the 3-voice Tandy/PCjr audio chip and hear how the musical elements were scaled down to a drastically limited output device. This practice can also lead to some interesting discoveries, such as how Rob Hubbard bit-banged a single SN76496 channel to make it perform like a crude DAC on Tandy machines, leading to some music soundtracks you can only hear properly on that platform.
- Easy video and audio capture. While audio/video capture is not a substitute for the real thing, it is excellent for quickly illustrating gameplay mechanics or concepts to an audience that can’t (or won’t) run emulators. Capturing video or audio from real vintage hardware ranges from “easy and high-quality” to “nearly impossible” (requiring hardware modification to tap the necessary signals for capture).
- Expanded capabilities. Emulation can enhance your experience of a work, which can greatly increase your enjoyment or appreciation of it. My favorite example of this is playing early multiplayer serial/modem/IPX games, or even 2-player game console games, across the internet with another player. In the 1980s, if you wanted to play a console or computer game with another person, you both had to be physically present. In the case of computer hardware, you had to connect computers via a serial cable, a modem connection over phone lines, or some other wacky physical connection such as a MIDI cable. The difficulty of establishing connectivity limited the experience. Nowadays, that situation has completely flipped — connectivity is standardized and widespread across international boundaries. Emulation bridges what the vintage hardware expects with what the real world can provide, and makes it possible for two people to play the same vintage console or computer game as if they were sitting side-by-side.
- Inspection. I absolutely love this. Many top-flight emulators have an embedded debugger that allow you to pause the emulated system, inspect memory and registers, set execution breakpoints/conditions, and more. This is an absolute boon to researchers (and preservationists, who wish to “crack” copy-protected games so that they can survive past the failure of their media). This has answered a great deal of historical questions for me, from why Galaxy Player is the fastest in the world on 8088 (answer: saturated register additions + self-modifying code), to how some vintage games manipulate a 3-D virtual space and calculate rotation and perspective transformations (answer: Just like everyone else, with matrix math and nine MULs, but with a 16.16 fixed-point worldspace and 256 degrees per circle instead of the usual 360).
So there you have it: You need both vintage hardware and emulation software to get a better picture of what you’re researching.
(Note that I didn’t say “to get the full picture”, because it’s impossible to get the “full” picture of a particular work. The “full” picture would conceivably include facets of the work that may be impossible to obtain, such as experience with the social and political direction of the time period in which the work was created, the background of the people who created the work, the business and financial pressures that led to the funding of the work and controlled its motivation and direction, etc.)
Posted by Jim Leonard on March 15, 2011
(Rather than break up the discussion, I’ve edited this entry with the promised timing information at the end of the post.)
First off, you owe it to yourself to check out Paku Paku, the astonishingly great pac-man clone written by Jason Knight. Why astonishingly great? Because, as a hobbyist retrogaming project, it does everything right:
- Uses a 160×100 16-color tweakmode on CGA, PCjr/Tandy, EGA, VGA, and MCGA, despite only VGA being capable of a truly native 160×100 resolution
- Plays multi-voice sound and music through the PC speaker, Tandy/PCjr 3-voice chip, Gameblaster CMS, and Adlib (yes, CMS support!)
- Runs on any machine, even a slow stock 128K PCjr
- Has convincing game mechanics (ghosts have personalities, etc.)
- Comes will full Pascal+ASM source code
This is just as good a job, if not better, than I like to do with my retroprogramming stunts. Very impressive work!
One of the things I love about coding for the 8088/8086 is that all timings and behavior are known. Like other old platforms like the C64, Apple II, ZX Spectrum, etc. (or embedded platforms), it truly is possible to write the “best” code for a particular situation — no unpredictable caches or unknown architectures screwing up your optimization. Whenever I see a bit of 808x assembly that I like, I try to see if it can be reworked to be “best”. I downloaded Paku Paku just as much for the opportunity to read the source code as for the opportunity to play the game (which I did play, on my trusty IBM 5160).
On Mike Brutman’s PCjr programming forum, a discussion of optimizing for the 8088 broke out, with Jason giving his masked sprite routine inner loop as an example of how to do things fast:
lodsw mov bx,ax mov ax,es:[di] and al,bh or al,bl stosw
It takes advantage of his sprite/mask format by loading a byte of sprite data and a byte of the sprite mask with a single instruction, then it loads the existing screen byte, AND’s the sprite mask out of the background, OR’s the sprite data into the background, then writes the background data. It takes advantage of many 808x architecture quirks, such as the magic 1-byte LODS and STOS instructions (which read a word into/write a word out of AX and then auto-increment the SI or DI registers, setting up for the next load/store) , and the 808x’s affinity for the accumulator (AX, for which many operations are faster than for other registers). In the larger function, it’s unrolled, specialized for the size of the sprite. It’s pretty tight code.
However, one line (“MOV BX,AX”) bugged me, as it also bugged the author:
The sprite data format is stored as byteMask:byteData words which I point to with DS:SI for LODSW… which I then move to BX (which sucks, but is still faster than MOV reg16,mem; add SI,2) so I can use bh as the mask and bl as the data.
So, was that code “best”? Is there no faster way to write a masked sprite in 160×100 tweaked text mode on the 8088?
First, let’s look at his original code, with timings and size:
lodsw 16c 1b mov bx,ax 2c 2b mov ax,es:[di] 10c 3b and al,bh 3c 2b or al,bl 3c 2b stosw 15c 1b -------------------------- subtotal: 49c 11b total cycles (4c per byte): 93 cycles
On 8088, reading a byte of memory takes 4 cycles, whether it’s “MOV AX,mem” or the MOV instruction opcode itself. That’s why smaller slower code can sometimes win over larger faster code on 808x. So it’s important to take the size of the code into account when optimizing for speed.
Some background knowledge of how Paku Paku works can help us: The game does all drawing to an off-screen buffer that mirrors the video buffer, and when the screen needs to be updated, only the changed memory is copied to the video buffer. Because Jason does all drawing to an off-screen buffer in system RAM, and the video buffer is smaller than the size of a segment, you have room left over in that segment to store other stuff. So if you store your sprite data in that same segment after where the video buffer ends, you can get DS to point to both screen buffer AND sprite data. Doing that lets us point BX to the offset where the sprite is (it was originally meant to be an index register after all), and use the unused DX register to hold the sprite/mask. We can then rewrite the unrolled inner loop to this:
mov dx,[bx] 8+5=13c 2b ;load sprite data/mask lodsw 16c 1b ;load existing screen pixels and al,dh 3c 2b ;mask out sprite or al,dl 3c 2b ;or sprite data stosw 15c 1b ;store modified screen pixels inc bx 3c 2b ;move to next sprite data grouping -------------------------- subtotal: 53c 10b total cycles (4c per byte): 93 cycles
Although we saved a byte, it’s a wash — exactly the same number of cycles in practice. However, since he is already unrolling the sprite loop for extra speed, we can change INC BX to just some fixed offset in the loop every time we need to read more sprite data, like this:
mov dx,[bx+1] (next iteration) mov dx,[bx+2] (next iteration) mov dx,[bx+3]
By adding a fixed offset, we can get rid of the INC BX:
mov dx,[bx+NUM] 12+9=21c 3b ; "NUM" being the iteration in the loop at this point lodsw 16c 1b and al,dh 3c 2b or al,dl 3c 2b stosw 15c 1b ---------------------------- subtotal: 58c 9b total cycles (4c per byte): 94 cycles
We shaved two bytes off of the original, but we’re one cycle longer than the original. While the smaller code is most likely faster because of the 8088’s 4-byte prefetch queue, it’s frustrating from a purely theoretical standpoint.
Reverse-engineer extraordinaire Andrew Jenner thinks two steps ahead of me and provides the final optimization that not only gets the cycle count down, but frees up two registers (DX and SI) in the process. He writes only what is necessary, and since we need to skip over every other byte when writing in 160×100 mode, manually updates the DI index register to do so. The end result is obtuse to look at, but undeniably the fastest:
mov ax,[bx+NUM] 12+9=21c 3b ; “NUM” being the iteration in the loop at this point and al,[di] 9+5=14c 2b or al,ah 3c 2b stosb 11c 1b inc di 3c 1b ---------------------------- subtotal: 52c 9b total cycles (4c per byte): 88 cycles
…successfully squeezing blood from a stone.
Is this truly “best”? I think so. But to prove it, we have to time the code running on the real hardware. Thanks to Abrash’s Zen Timer, we have the following results:
- Jason’s original code as listed above, repeated three times to plot a 5×5 sprite: 48 microseconds
- My code block, three times with [bx], [bx+1], [bx+2]: 41 microseconds
- Andrew’s optimization, also written with [bx], [bx+1], [bx+2]: 37 microseconds
And just to make your head spin, check the comments for this entry — the resulting discussion shows that if you’re willing to rearrange both your sprite data and your thinking, you can get things even faster!
Posted by Jim Leonard on February 13, 2011
I have free time to work on a single project at a time, and that project this weekend has been MindCandy. (We’re very close to a test disc (yay!) — minus subtitles. Subtitling 4 hours of multi-speaker dialog is a massive chore, multiplied by the number of languages you want to have, so we’re strongly considering not doing subtitles.) But if I had time to work on multiple projects simultaneously? I’ve always wanted to produce videos about classic hardware and games, 99% centered on the PC/DOS platforms of the 1980s. Imagine how happy I am to have discovered the following people:
Lazy Game Reviews – Produces 10-minute reviews on both hardware and games, with a touch of humor and lots of footage captured from the real hardware whenever possible. The Carmageddon review in particular is perfection, having been captured from a real 3Dfx card and with meaningful illustrations of gameplay, including some accurate history of the development of the game. His Youtube channel is easier to navigate past shows, but the blip.tv channel earns him a modicum of cash and has better quality video, so… choose.
Ancient DOS Games – While LGR covers the gamut of classic personal computers and gaming, Ancient DOS Games covers only DOS games, and the thoroughness and attention to detail is astounding. Features like tips and tricks on how to play the game, recommending the best graphics mode or DOSBOX settings per game, noticing what the framerate of the game is and how it affects gameplay, and even a comparison of dithering methods in Thexder and whether or not they were effective — these are all OCD traits that I would have put into my own coverage of the material. His fly-outs are pixel-art amusing.
Those guys are doing such an amazing job that I really don’t see the need for me to do so. The both of them combined equals a quality of work that I can’t see myself improving upon, which not only makes me very happy, but frees me up to work on other projects. Check them out, dammit!
PS: I found I have a true doppleganger over on tumblr. We have very much in common — moreso were I lesbian.
Posted by Jim Leonard on August 12, 2010
I’d like to take a short break in my audio-cassettes-included-with-classic-computer-games series to ask a question: What series have you tried to collect, and why?
Most collectors of classic game software tend to focus on an entire company (Sierra, Infocom, Adventure International, etc.) while others tend to hone in on a particular series (Wizardry, Ultima, etc.) I am guilty of both, but my collection is biased towards series that may not seem to be worth collecting, have any relationship to each other, or have any rational pattern (even to fellow collectors!). What I collect reflects why I like old PCs as a hobby: Not because “old komputers R k00l” but because “what people did to get past old computers’ limits is k00l”. If a game was really well-programmed, or had great graphics, or managed to produce audible sound out of the beeper, it gained my admiration. Sure, story and gameplay mechanics are a contributing factor, but they’re not the main focus of my collection.
Another odd thing about what I collect: It’s 99% PC. I have some Apple II, Mac, and C64 titles, but those have been donations I’ve promised to take good care of, and I have. My heart lies in the original PC, mostly because it was the hardest platform to get a decent game experience on, making successes all the more impressive. This is atypical; most of my fellow collectors don’t discriminate platforms like I do.
Here’s an incomplete list of some “series” I’ve collected and why I consider them a series:
All the PC versions of Cinemaware adventure titles: Defender of the Crown (including the euro bootable EGA/Tandy/3-voice version), King of Chicago, S.D.I., Sinbad, The Three Stooges, It Came From The Desert, Rocket Ranger. Cinemaware games were a mixed bag: Awesome graphics, music, and sound — on Amiga. Other platforms usually got worse graphics and sound, but better gameplay because they would tweak some games between platforms. Play the original Defender of the Crown for Amiga and you’ll find it is nearly impossible to win. Play it on C64 or PC, and you’ll find it’s a much more balanced game. Anyway, the graphics rocked CGA at the time.
EA Chuck Yeager flightsim series: Chuck Yeager’s Flight Simulator, Chuck Yeager’s Flight Trainer 2.0, Chuck Yeager’s Air Combat. The first was a very fast simulator for an old PC with CGA; you could even flyby the “EOA” logo in the desert. Then Microsoft sued over the “flight simulator” name and they quickly rebranded it as Flight Trainer. Then came Flight Trainer 2.0 with more of a focus on training, and an audio cassette with many notes from Chuck himself. Finally Air Combat, with a completely new engine by Brent Iverson which traded 20% less speed for 100% better graphics, models, video modes, clouds, cameras…
Deus Ex series: Deus Ex, Deus ex 2: Invisible War, Project: Snowblind. Snowblind? Yes, Project: Snowblind was originally developed by Crystal Dynamics as a spin-off of Invisible War, but when DE2:IW sold poorly, the story and assets were changed somewhat to distance the game from a then-failing property. Playing the game, however, reveals much of the familiar Deus Ex biomod mechanics, and the story — while taking a backseat to action — smells heavily of conspiracies, like all Deus Ex games.
Sierra Game Arts collection: Thexder, Silpheed, Firehawk, Sorcerian, Zeliard. All of these games were ports from the PC-88, and all of them look best in their native 640×200 16-color mode which you can see on a Tandy SL/RL/TL series computer or on an EGA card with more than 64K of video RAM. For everything but Silpheed, the full-screen graphics updated very quickly by dividing the entire screen up into 16×8 tiles (8×8 if a 320×200 mode) and only repainting the tiles that change. Since movement was quantized to tile locations, very little updated per frame even though it didn’t look like it. These were essentially 40×25 textmode games but using graphical tiles — brilliant! (Oh yeah, they also support Tandy 3-voice sound and all but Thexder supported a ton of extra sound devices for the time, but it’s the graphics mode and engine that I love.)
DSI road engine games: Test Drive, Test Drive II, Outrun, Grand Prix Circuit, The Cycles. This is extremely obscure and deserves an explanation. When Distinctive Software Inc. was an independent Canadian developer, they came up with a relatively simple-yet-effective road repainting engine that got used in several games published by Accolade: Test Drive, Test Drive II, Grand Prix Circuit, and The Cycles. During this time, they also took on a job for Sega porting Outrun to the PC. They used the same engine, which one could argue they didn’t own because they developed it while under contract from Accolade. They must have known something was up because they didn’t use their DSI name and logo, but instead used Unlimited Software Inc. Accolade felt they violated a working agreement, and filed a lawsuit. (Ironically, the Outrun version of the engine is the smoothest, running much better on faster machines. It’s playable even on gigahertz machines.)
Would you be fooled by this?
Access adventure Series: Mean Streets, Martian Memorandum, Countdown, Amazon: Guardians of Eden, Under a Killing Moon, The Pandora Directive, Overseer. Access knew that the best technology could sell games, even if the story was a bit lacking. Their engines had (crude) motion video, digitized audio, and 256-color graphics as early as 1989. Later games like Under a Killing Moon and Pandora Directive also had a great engine with pre-rendered lights and a fully-textured world to explore. While I loved all of them, my heart belongs to the Mean Streets engine because it used 256-color VGA graphics as the base data but would FS dither to all common lower graphics modes as well.
Here’s part of one shelf of my collection; I have five more shelves:
It’s a small collection compared to some of the superstars of my hobby, and I’ve had to pare it down over the years due to financial hardship, but I’m happy with what I have. It’s special to me, and that’s what counts.
Posted by Jim Leonard on August 7, 2010
(What follows is a continuation of an article about audio cassettes included with computer games; if you would like to start at the beginning, start with Homeword.)
Corruption was one of the legendary Magnetic Scrolls series: text adventures from the UK that are regarded by many to be on equal footing (if not better) than the venerable Infocom series of interactive fiction.
Playing the included audio tape before it’s required by the game isn’t recommended, but doing so sets up the basic premise of the story. The first track on the first side of the tape is a conversation with your boss that was used to frame you. In it, you hear your boss calling you into his office and confronting you about insider trading. (boss: “Using heavy inside knowledge — it’s a criminal offense.” you: “I agree.”) The conversation generally makes you out to be the bad guy (at one point, you bluntly answer accusations with “I’ll be frank: I admit it.”) For atmosphere, the tape has “Derek Rogers, March 25″ scrawled on it in a kind of handwriting.
Sounds pretty damning, doesn’t it? There’s only one problem: You never had this conversation with your boss! You’ve been framed! You have to unravel your life and figure out the corporation’s secrets to win the game and get your life back.
C. E. Forman, an avid interactive fiction gamer, had this to add:
During the course of the game, you the player-character actually find this tape in one of your business partners’ offices, and can play it in the cassette deck of a car you break into. (Magnetic Scrolls also offerred a written transcript you could send for, in the event that the tape got damaged, since it’s a rather vital part of the plot.)
After the conversation, the theme music written by John Molloy starts. The title theme is extremely appropriate for the source material; the musical style evokes images of a mystery that needs to be solved, with sympathy for the hero. The other side of the tape, which is unlabeled, hides the original conversation you had with your boss from which the “framed” version was created. It’s a bit long, but is engaging to listen to as it demonstrates where your tormentor got all his sound bites from to make the version that framed you.
All in all, the tape adds a nicely textured clue that helps flesh out your purpose (and what you’re up against) in the game.
Highlight: The passage “Stupid sod spilled all the beans!” in the “framed” version of the conversation.
High Points: Good voice acting; realization that the “framed” conversation is very cleverly edited together once you hear the original conversation.
Low Points: Annoying reverb effect applied to both actor’s voices makes it hard for some to understand what they’re saying
Audio: For this installment, I’ve linked to the various available mp3s in the above article text.
Posted by Jim Leonard on July 31, 2010
(What follows is a continuation of an article about audio cassettes included with computer games; if you would like to start at the beginning, start with Homeword.)
The President Is Missing
The unthinkable has happened: During a secret conference of national leaders in Switzerland, terrorists break in and capture several world leaders, including the President of the United States! It’s up to you to find out where he is by examining all of the evidence, including multiple audio cues and photographs. Along the way, you’ll uncover a diabolical conspiracy (of course) that may involve even those closest to the President himself.
The audio cues you need to play the game are numerous and vital to solving the game, so they were provided on the included audio tape. In addition to setting the mood for the game through some introductory audio clips, you have a multitude of “file tape” recordings that can help you locate the President and solve the case. Included are interviews with government officials, taped radio communications, recordings from tapped telephones, the terrorists’ spoken demands, and even some (very squelchy) morse code signals.
All in all, it makes for a good mystery. Cosmi titles were never high on quality, but The President Is Missing makes a great attempt at publishing a good game.
High Points: Wide variety of clues; slow realization that it’s not quite as important as what is being said as to how it is being said.
Low Points: Voice acting ranges from acceptable to poor; recording quality ranges from good to poor; too many audio clues lessens the impact of all of them (in other words, a few great clips would’ve been much better than tons of mediocre clips)
Highlight: Hearing an unlucky informant getting blown to smithereens over the phone. :-)
Posted by Jim Leonard on July 23, 2010
(What follows is a continuation of an article about audio cassettes included with computer games; if you would like to start at the beginning, start with Homeword.)
Continuing our exploration into the mind of Tom Snyder, we pull 180 degrees and take a look at Sub Mission, a diabolical game of hide and seek with a warlord. It takes place underwater using submarines and mines; a bit of action, a bit of simulation, and a bit of strategy round out this game with very unique aspects. Sound unique enough for you? If not, consider this: If you play the game “for real” (ie. not with “robots”), you run the risk of permanently killing one of the characters in the game, who has clues vital to escaping. It deletes the character data off of the disk!
Gameplay suffers from seemingly poor planning. One gets the feeling that Tom thought of a couple of neat elements — submarine play, hide-and-seek tactics, permanently killing characters, etc. — and tried to mesh it all into a game. The end result has some holes in the story, and some gameplay elements feel arbitrary and forced. These elements are probably what prompted for the inclusion of a cassette in the game: The first side of the tape has an 8-minute introduction that sets up the premise, and the entire second side of the tape — 22 minutes — is an extremely thorough tutorial.
Highlight: (Cheezy) Computer telling the player that “To save them, you have to play the game — and play to win!“
High Points: Tutorial fully explains all aspects of the game such that reading the manual is probably not necessary; first 46 seconds of the tutorial clearly explains gameplay purpose better than the entire introductory story on the first side of the tape.
Low Points: Weak title theme; “computer voice” in introduction is sometimes hard to understand; (seemingly) randomly-generated music constantly playing in the background; tutorial narrator is dry and reads as if he’s high on weed; repeated careful pronounciation of the words “sonar scope” is irritating to some; tutorial is very long; tutorial was recorded in one take, probably improvised, resulting in some long pauses, stumbling over words, and computer noises in the background; your character himself keeps pointing out glaring holes in the plot and gameplay, such as “Wait a minute — I don’t need those two kids to help me beat the warlord. Why should I risk their lives when I can pilot (the sub) through a remote robot?” and “Why play the wargame at all? Why not just put Sigourney or Peter in the sub and go looking for the escape route?”
Trivia: As previously mentioned, Tom Snyder Productions branched away from computer games and into traditional media, like cartoons. If the name wasn’t familiar before now, do the shows “Dr. Katz” (Comedy Central) and “Squigglevision” ring a bell? They’re the brainchild of Tom’s production company. In fact, listen to the beginning title theme in the Sub Mission intro — there is a faint resemblance to the sequeway music played when moving from one scene to another in Dr. Katz.