1990 Loose End #1: Legend of Faerghail

    

Legend of Faerghail was an early representative of a clear 1990s trend: an explosion of interesting RPGs from German developers. I played it in the fall of 2013 and called it, in my "Final Rating" post, an "interesting misfire." Starting with a base reminiscent of The Bard's Tale, it added a bunch of innovative features, including a combat mechanic that drew from both Wizardry and Phantasie, and excellent graphics and sound--including some of the first ambient sound. Alas, it had too many mistakes and half-developed ideas to rate very highly.

I still would have finished it except for a bug I encountered that made an entire castle disappear, preventing me from continuing the game. That was in the Amiga version. The DOS version was already bugged beyond belief, so my only option would have been to re-start with the Amiga and hope the bug didn't recur or attempt the Atari ST version, which is only in German. I decided to simply quit, even though it ended a very long winning streak.

There's supposed to be a castle here.

Last summer, 6 months after my final post, I heard from Olaf Barthel, one of the three principal developers of the game, who started our correspondence by saying, "your observations and assessment of the game's merits and shortcomings are spot on"--a quote that some of my regular commenters should feel free to repeat more often. We traded a series of e-mails in which he offered a wealth of information about the game's development. The exchange made me feel a lot better about Faerghail, and based on it, I fully intended to re-engage the game, peppering my new posts with information from Olaf's e-mails. But every time I went to fire it up, I was reminded that I still faced the same bugs and probably wouldn't be able to finish it.

Now that I'm in 1991, I suspect I won't ever return to Faerghail, but the least I can do is offer some of Olaf's insights on the game.

Olaf, Veith Schörgenhummer, and Matthias Kästner were the creators of Faerghail. They started development when they were in school together and all 18 or 19 years old. The scenario was based on a Dungeons & Dragons campaign that Schörgenhummer had designed. At first, they were simply trying to create something for the German domestic market, which was a bit light on RPGs at the time. But their publisher saw potential in the international market and insisted on an English translation and DOS and Atari ST ports.

I had long wondered about the game's name, and in particular whether it was intended to evoke the earlier Fargoal. Apparently not. In 1986, Olaf was studying in England as an exchange student and bought a book called Irish: A Complete Introductory Course. Later casting about for a name for the game, Olaf pulled the book from his shelf, flipped to a section that listed common Irish surnames, and stabbed his finger on "Ó Fearghail." They dropped the "O" and switched the "a" and "e" so no one would read it as "fear." The funny thing is, this is the second game I know of to get its name in this exact way; the first was Eamon. I love the idea that we nearly got The Legend of Flaithbheartaigh.

The page from which Olaf took the game's name.

   

Olaf confirms that the game was built on a foundation of The Bard's Tale, Phantasie, and first edition AD&D rules (the second edition wasn't translated to German until the game was already finished). Inspired by the ability to dig through walls in Moria, they added the "smith" class with his demolition abilities (something I never really explored). This part I love and leave in Olaf's own words:

The reason why there is a monk, but no female counterpart, was in that we couldn't quite picture how it would look like. It is something of a stretch to imagine how the monk, wearing a cloak and hood, could be capable and effective in unarmed combat. It would have been an even greater stretch to imagine a nun, wearing cloak and veil, in the same role as the monk. Because we did not have a female monk, we added the female-only healer class instead.

Something I didn't realize while playing the game is that monsters, while randomly roaming the hallways, actually pick up treasure. This accounts for why I didn't find chests in the same places sometimes when I had to re-load a level, and why some monsters inexplicably offered more treasure than others. As for the monsters themselves, the generic "ghost" images were a late-game addition. Originally, the game was going to be like The Bard's Tale, where you just stumble upon enemies but don't see them ahead of time. Eventually, after playing Dungeon Master, the team decided they wanted to see monsters in the environment, but they didn't have enough time to create images for every one.

Olaf agrees about the inferiority of the DOS version. It was an awkward time to develop for DOS, right in between the CGA and VGA standards and the AdLib and SoundBlaster capabilities. Ultimately, they just didn't have the time and resources to invest in better graphics or any sound. A fundamental weakness of the DOS version is that you can "clear" monsters in the wilderness areas, which makes it impossible to later grind for food. You end up spending most of your gold keeping the team fed.

My comparison of Amiga (left) and DOS (right) graphics.

As for the translation issues we encountered, Olaf says that the manual and game text were translated professionally, but by people who didn't understand the context of RPGs and had trouble with terms like "dungeon master." He recalls having the same "riddle trouble" that I did when he played Wizardry VI in German, got nearly to the end, faced a riddle whose answer should have been "pen" or "quill," and yet couldn't get the game to accept any appropriate German word. Ironically, Olaf wrote to me in absolutely flawless English. In a few years, he could have done the translations himself.

Faerghail was Olaf Barthel's last game, but he has had a long and rewarding career in the computer industry. (This interview goes over many of his contributions.) Veith Schörgenhummer also called it quits after Faerghail, and Olaf lost touch with him. Matthias Kästner, on the other hand, went to art school and has continued to work in the German games industry as a designer, animator, art director, and project leader. His credits include graphics on Fate: Gates of Dawn (1991), Neocron (2002), Back to Gaya (2005), Mata Hari (2008), Black Mirror II: Reigning Evil (2009), Black Prophecy (2011), and The Raven: Legacy of a Master Thief (2013).

Olaf offered a lot more about the game, and rather than try to work it into paragraphs, I'm going to paste his own words below for anyone who's really interested in the details of graphics, sound, and programming.

*****

All text below except for the bolded headers, image captions, and text in brackets is directly quoted from Olaf Barthel's e-mails to me between 12-14 July 2014.

On the development process:

At that age you can move the world, just by sheer force of ignorance and sticking to your guns. In retrospect, that type of approach must have made it harder for everybody who was involved in making the game.

Not only were the three of us pressed for time, as the final exams were approaching (we passed -- working on the game did not have a negative effect on our marks), our producers and collaborators at reLINE software must have been tearing their hair out, given the complexity of the game.

What originally started out as a more modest product evolved into a multi-platform game (Amiga, Atari ST, PC), in two different languages, using unproven technology (reLINE software wrote all their games in assembly language; Legend of Faerghail was written in 'C'), by an unproven designer/programmer team.

Legend of Faerghail was the first, only and last big commercial game the three of us collaborated on. We all were hobbyists/amateurs, who were self-taught and learned the craft through writing software for and painting on the C64.

On monster AI:

The monsters roaming the dungeons follow simple A.I. rules. When a dungeon level is loaded, the monsters are always reset to start positions, and then proceed to roam the halls. They will patrol the hallways, search for treasure (and pick it up, if they feel like it: if you encounter and kill these monsters, the loot will include the treasure they found) and try to follow the player if they can spot it. You can even bait certain types of monsters, which will then stop following the player and stick to the bait. The A.I. is not particularly good, though (Pac Man has stellar ghost A.I. compared to Legend of Faerghail).

On saving the game:

Saving the state of the game to disk and later restoring it evolved over time, with auto-mapping getting squeezed in very late in development. Because of memory constraints I was unable to store the positions, attributes, etc. of all roaming monsters and the level auto-map states for all dungeons the player had visited up to this point. This is the reason why upon reentering a dungeon level, monsters respawn and the level auto-map is reset.

On the Amiga version:

-The game was originally designed specifically for the Amiga, which is why there are sound-effects and, for its time, modest graphics effects. The prototype dungeon crawler even used the Amiga-specific high resolution graphics mode (640 by 512 pixels in 16 colours). These platform-specific features and resolution were eventually scaled back because of the Atari ST port. The PC port arguably had even more restrictions than the Atari ST version. The Atari ST version even supports a 640 by 400 pixel black and white mode.

We never realized that we might have been one of the first computer role playing games to feature ambient sound and day/night cycles in 1st person perspective ("Ultima III" certainly had day/night cycles, but the on-screen visuals never reflected the gradual change of time). Building this feature into the game seemed natural, given the capabilities of the Amiga.

The three of us designed the ambient sound of the game. The Amiga offered four channels of 8 bit digital stereo sound, and we tried to make the most of it. For the sound effects we must have watched (or rather "listened to") just about every adventure movie that was available on VHS tape at the time. I recall that most of the combat sound effects came from Richard Lester's The Three Musketeers.

The Amiga version had to work well on the standard type of Amiga at the time, which had only 512 KBytes of main memory available. Because of this restriction, the game may at times choose not to load monster portraits or sound-effects. However, the game adapts if you have more memory to spare, giving you more monster portraits, sound effects, etc. and it will even cache assets (just set your Amiga emulation to use 512K of fast memory, or more).

The game covers three disks, in the Amiga version, and can be installed to hard disk in order to speed up disk access (it has no on-disk copy protection). The game even supports multi-tasking, which means that given enough memory, you can use the Amiga for productivity software and play the game at the same time.

The reason why saved games can be corrupted is likely because you did not wait for disk activity to finish after saving the game to disk. Because of how floppy disks work with the Amiga operating system, there is a small delay after the last write access before the file system concludes the write operation and spins down the floppy disk. This delay is independent of the floppy disk emulation speed. Hence, if you save to disk, wait 1-2 seconds before you restart the emulation or switch it off.

On the DOS version:

The game itself was designed and "prototyped" on the Amiga, and at some point had to be ported both to the Atari ST and the "IBM PC compatible" platform. This proved to be challenging on many levels: the game was not intended to be ported when designed, game design was still evolving and ongoing, and at reLINE software nobody had the necessary experience in programming the PC in the 'C' programming language.

This was at a time when the IBM PC compatible platform started to become relevant as a gaming platform, both in Europe and internationally. reLINE software had already acquired a development system, with AdLib sound card and EGA graphics. By comparison to the Atari ST and certainly the Amiga, the PC was not a mature platform, because it lacked an operating system. The development tools in particular were immature: the Atari ST had an excellent Turbo 'C' compiler, but the 'C' compiler used on the PC by reLINE software had so many quirks that porting code from the Amiga almost always amounted to a rewrite.

Holger Heinrich at reLINE software took on the challenges of porting Legend of Faerghail to the PC, and from what I recall this was an exceptionally difficult task. Not only did Holger have to port a game which was not intended to be portable, he also had to learn programming the system from scratch.

The PC development platform itself was by no means uniform or stable either. Back in 1988/1989 the term 'compatible' in "IBM PC compatible" had claws and teeth. How you programmed the graphics hardware varied greatly by manufacturer, and since there was no operating system to help you along, you had to use low-level operations to get it to do something useful. I recall that reLINE had to test the game on a special IBM PC compatible machine manufactured by Tandy, which had both a significant market share in the U.S. and which had its own peculiarities to account for.

Porting the game to the PC amounted to rewriting the game code, both because of the quirky 'C' language development platform, and because the code was not particularly portable to begin with. What worked well on the Amiga had to be adapted for the PC, and you probably saw the side-effects of this approach play out.

On the challenges of mapping from a 3D perspective:

The "3D" view was the first tough problem to crack when we designed the game prototype. We had to find a way to make both the perspective work, and find a system for building the image from components (walls, doors, stairs, special illustrations). What Matthias and I arrived at was what you see in the finished game. Each element in the perspective layout was designed according to a template (this [image] is from my original 1988 archives). The game uses a central perspective, and the visible space is three steps deep.

Both the background (floor and ceiling) and the foreground elements are slightly asymmetrical. This was a deliberate design decision: whenever you turn or take a step forward/back, the game redraws these elements by mirroring them horizontally. This makes the view appear slightly, but noticeably different from how it looked before, supporting the fact that something has changed when you moved.

The basic "3D" view design was adapted from The Bard's Tale, but it never occurred to us that our version did not give the player a sense of what is left or right of the wall he or she is currently facing [This was something I had complained about in my reviews].

On location design and content:

We wanted to make the individual location map layout reflect the architecture of the respective place. This is why, for example, the monastery layout looks like how you might find a European medieval monastery does, and why the individual levels of the Elven pyramid become smaller and smaller the further you ascend the pyramid. Each level can cover 36 by 36 individual rooms, but we never used all of that space, not even in the wilderness (trees and walls cover the edges).

Our idea was that each dungeon layout should be different, with respect to the location. Again, The Bard's Tale provided the motivation for this decision: we did not want use the same "one size fits all" style level design in the game.

The size of the game, with all the different dungeons and their many respective levels, came back to haunt us. We arguably succeeded at building a game world, but we struggled with making it interesting. This is why the puzzles and the game's overall campaign design (one single quest, no sub-quests and certainly no branches in the story) are not as ambitious as the technical design of the game world (this seems to be common problem even in contemporary computer game design; Assassin's Creed I and Watch Dogs come to my mind, for example).

The campaign design upon which the game was originally intended to be built did not provide enough content to fill the game world with. The world had simply become too large. Filling the vacuum proved to be very difficult, because we lacked the necessary experience and storytelling background. What ended up in the game therefore came from what surfaced when we stirred the pond, so to speak. The three-part key staff, for example, comes from Raiders of the Lost Ark (which probably borrowed it from a 1930s serial in the first place).
      

On combat:

We adapted the look and the basic mechanics from what we were most familiar with, this being The Bard's Tale. We tried to add some small incremental improvements to this model. Unlike in The Bard's Tale, our game shows you the placement of the enemy and your player character, and does not represent this information as numbers only.

As we discovered during development, the overall visual design of our game made how the combat played out on screen look rather bland and somewhat pointless. This was tactical combat at its most tactical: you gave instructions to your party, very much like a coach, and wait on the sidelines until this round had concluded. The text on the screen would give play-by-play commentary on what was going on.

Because we discovered these shortcomings late in development, our options to address them were very limited. We provided two variations to the basic formula. The first was the quick combat option: you do not need to read the play-by-play commentary scrolling across the screen, you just get to see the final results of the round. The second was to add minimal animations which identified who was attacking who, which type of character (fighter/magic user/animal) was involved, and also add sound effects (hit/miss/equipment damage). We affectionately called this the "Punch & Judy show" when we developed it (although it is arguably not quite as violent).

The distance between combatants does make a difference during the combat, but maybe not as much as it should. The closer you are to an enemy, the more likely you will succeed in hitting it (and the more likely you are to get hit). Missile weapons and spells should make a difference if the distance is larger.

On monster graphics:

As the game evolved, we added more and more distinct enemy types; we wanted to avoid recycling enemy portraits, as The Bard's Tale did. Unfortunately, this decision increased the workload for creating the portraits, which is why instead of one single artist, three artists eventually worked on the monster portraits (Matthias Kästner, Rainer Michael and Frank Knust). Some of the portraits were adapted from existing illustrations, sometimes by scanning, retracing and coloring what we found in the AD&D manuals and magazines.

The portraits throughout the game are extremely well-done.

The dragon featured prominently in the game's title screen, and which also happens to be the monster you meet in the end game, originally comes from the cover of an AD&D monster manual, and was redrawn by Matthias (this is Matthias' original drawing, in which the priest in the foreground wears a blue tunic).

On the language system:

We added it so that you could get out of encounters without fighting. It turned out that regular combat was somewhat uninteresting, and providing the player with options to retreat or parley instead would offer less boring alternatives.

Once we started down this road, the next logical steps were to offer bartering and recruiting as part of the language system. Recruiting is actually a variation of what happens in The Bard's Tale when you summon an elemental to fight for your party.

One reason why the language system is not as useful as it should be is that there are bugs in the implementation which I only recently discovered. In order for parley to succeed one member of your party needs to be able to speak the language of an enemy. Because of a bug (it is an off-by-one error) the parley can only work if enemy and party member *do not* speak the same language.

This is finally explained!

On "whimsy":

As development progressed and really started to drag, the tone of the game began to drift. What originally began as a serious story, built around a mystery (what happened to the Elves?), slowly started to pull in material to fill the void left by the game world being larger than the story designed to fill it.

The seriousness of the game's tone invited commentary, not necessarily in the form of parody or satire, but it was time and again necessary to lighten things up a bit. This is why there is a snarky comment about magical Elven plumbing, and an inflatable rubber dragon (which comes from a cartoon found in a D&D magazine), for example, and the end-game text featured in the final dungeon is bordering on being funny (at least in the original Klingon, but not so much in the English translation).

As we learned over time, being a D&D dungeon master does not require that you keep the game's tone strictly serious. Fun can come in all shapes and sizes, and not just in how well your character holds up in combat. Equipment can break during combat, attacks can fail. Your character may not face such events stoically, he might even curse (historical note from a foreigner: I understand that "cursing" actually used to mean the use of profanity; in the context of our game it is just the use of obscenity). This is what happens in Legend of Faerghail. When an attack fails, there is a very small random chance that the character will quietly say "sh*t!" (in the Amiga version). We did get called out for that little bit of whimsy, and strangely enough only by U.S. players. Incidentally, that is Veith Schörgenhummer's voice which we sampled for the sound-effect.

We could not resist adding easter eggs to the game. You already found the "Indiana Jones" reference--did you notice that there was a sound effect for that, too? [Alas, I did not. I was probably playing with the sound off for some reason.]

I still don't know what the "wands and sunshine" part means.

 On copy protection and the endgame:

We disliked shipping a game with copy-protected disks. For one thing, we had learned long ago that it did not take long for copy protection to be overcome (look at the contents of the many Amiga abandon-ware game web sites and judge for yourself--almost all of these games were once copy-protected), it also meant that we would have had to somehow adapt the game and its distribution media to support copy protection. We lacked both the expertise and the time to accomplish this.

Our solution to add a bit of copy protection was to put vital information required to succeed at the game into the manual. This is why there are numbered maps both in the manual and on the sleeve of the manual.

If I remember correctly, the end game requires that your party survives traveling through very hazardous terrain. Your party receives an amulet with a map on it early during the game, and that map is pictured on the reverse side of the manual. The map was designed so as to make photocopying it very, very hard. It is the key to traveling through the hazardous terrain in the end game. Now if only we had dropped more hints on what that map is good for, and if the numbering of the maps in the manual actually corresponded to the numbers, as used in the game text...

 *****

It's an interesting game, and I'm glad I had the opportunity make more of its backstory known to the world.