Ingmar: Can you give us an overview of the Infocom games you did and share memories that come to mind from the development of each game?
Bob: The first game I wrote for Infocom was Sherlock! The Riddle of the Crown Jewels.
Infocom’s games were built on a DEC-20 mainframe, using a proprietary language called ZIL. So the first thing we had to do was to rent time on a local DEC-20, and the second was to learn ZIL. My partner, Dave Wilt, had ties to a hi-tech consulting firm called American Management Systems, and he set up the mainframe arrangements. Learning ZIL was more problematic. As I’ve said, I was a writer with no programming experience. So we approached a local programming-services-for-hire firm called Paragon Systems. We set up a consulting agreement to get near full-time access to two of their employees, Mark Poesch and Duane Beck. Those two, together with Frederick Wilt (Dave’s brother) were the three who did the game programming for Sherlock. (By the way, Paragon Systems was owned by a young guy named Mike Verdu, who dropped out of college to run his company. You’ll be seeing his name again!)
I remember traveling up to Infocom’s “new” office in Cambridge Park and sitting with Stu Galley as he patiently taught us the fundamentals of ZIL. I remember the poster in his office: “Sometimes I sits and thinks, and sometimes I just sits.” Between Stu and Chris Reeve, we managed to learn enough to start coding. Duane and Mark did the heavy lifting, and along the way Duane started to teach me to code as well. By the end of Sherlock’s development, I was very warily dipping my toe in the programming waters.
As for the game itself, I have trouble remembering details, other than the design lessons I learned “on the job.” Years later, and sometimes still, people ask me questions about the puzzles in my games, and inevitably I have to go back and start the game up to figure out how to answer their questions. I do have a pretty bad memory, but I claim a special exemption for remembering details of old games. My excuse is that when you’re designing a game, there are dozens of avenues you explore as you’re creating the puzzles, and it’s easy to forget which of several possible solutions you actually implemented! Usually the way I find out is to play the game, get to the puzzle, and then say, “Hmmm, how would I solve this.” That mostly works, as it turns out that I tend to think like myself. Needless to say, however, I am often surprised along the way as I try out various odd inputs and discover responses that I wrote and forgot 30 years ago.
The most vivid lessons that I learned from Sherlock were to always watch people play your game, and never to make things too difficult for the player at the beginning.
The first of these I learned when proudly showing my father-in-law (a non-gamer, as pretty much everyone was back then) an alpha version of the game. The opening text had him standing in front of the door to 221B Baker Street with a doorbell conveniently in view. What could be simpler than >Ring Doorbell. Instead he typed everything BUT that. Inputs like “Where is Sherlock Holmes?” and “Why can’t I open the door?” The Lesson: People don’t necessarily come to your games knowing the conventions of your genre. This lesson is especially valuable these days in the development of casual games.
The second lesson I learned was to ease the player into the game. In Sherlock, the most difficult puzzle in the game is one of the very first puzzles you have to solve. (Is it necessary to post a Spoiler Alert for a game that came out two decades ago? Yes? OK: SPOILER ALERT)
In the game there was a faithful recreation of the layout of Westminster Abbey, and especially the statues and memorials that are still in the building to this day. The player had to figure out that he needed to take a rubbing of the inscription on one of the statues. Not only did he have to find the materials to make the rubbing, but he had to figure out which statue was the right one. And oh yes, when he made the rubbing, the page was blank – it turns out the information was transferred to the paper with invisible ink. So he had to find a heat source to reveal the writing. Thankfully, there was a chapel nearby where a lot of votive candles had been lit, which was a sufficient heat source. So now the player has done everything he needs to, but the paper is STILL blank. The final step? >Turn paper over.
Never since have I put so difficult a puzzle at the beginning of a game.
The second game I wrote for Infocom was Arthur, The Quest for Excalibur. This was the first game I did that had graphics. (And believe it or not, the game won the MacWorld 1989 Graphic Adventure of the Year award!)
I remember the added complexity and limitations of creating scenes and puzzles when the player had an actual image to look at. Everything that the artist happened to throw into a scene became an object that the player might try to interact with, so suddenly I found myself dealing with much more work than I had intended. On the positive, however, was that the artists brought real life to the places I had created, and the artists’ versions were always so much more interesting than what I had imagined.
I don’t remember much about the game itself, other than how cool it was that the player could change himself into different animals (a la The Once and Future King), and how much fun it was to design puzzles that the player could only solve when he was in the form of an owl or a badger or whatever.
Ingmar: How did things come to an end for the company?
Bob: This is really well-documented, so I won’t go into it much here. Suffice it to say that Infocom was actually founded to be a business software development company, and they used the profits from their games to fund development of a relational database program called “Cornerstone” (not so affectionately known as “Millstone” among the game-makers in the company).
As the popularity of text adventures declined, and the company kept plowing more money into Cornerstone, eventually the money ran out. Infocom’s parent closed the doors in May of 1989.
By that time, Mike Verdu had sold his company to a large defense contractor called ASC. Mike was a director there, and he talked the owners into backing a new company. We originally called ourselves GameWorks, but it turned out that Borland had an obscure product with that name, so we went with our second favorite: Legend Entertainment. My wife, Peggy Oriani, designed the shield as our company logo. She became our marketing director and we were off to the races.
Ingmar: When people remember the golden era of adventure games, they usually come up with two companies right away: Sierra and LucasArts. Does that bother you? After all, you paved the way for a lot of things that followed later and a lot of people don’t even seem to know that anymore.
Bob: I think I disagree with your premise. I believe that when people remember the golden era of adventure games, they certainly put Infocom right at the top. This is especially true if you say “text adventure,” and I think people would be hard-pressed to name even one other text adventure game company other than Infocom.
Certainly when you mention the golden era of graphic adventure games, Sierra and LucasArts are the first two on the list, and deservedly so. Even though the later Infocom games did include graphics, none of our games approached the level of delight to be found in, say, Monkey Island. Regrettably, I believe the same is true for our Legend Entertainment games. We were competing head-to-head with Sierra and LucasArts, and while I think we made great games, I don’t think there was any question that the other two companies were kings of the category.Continued on the next page...
E3 2017: Daedalic Entertainment previewPC Mac Linux PS PS4 Xbox Xbox One Switch