Wednesday, 4 March 2015

FEATURE: But how was it made? Dungeon Master

FEATURE: I’m continuing to look back at the games that I played when I was younger. Inspired by the ‘#FourGames’ hashtag, I began wondering how these games, that I sank hours into, were made and what was the development process like? You can find all posts in this feature here.

Last week I looked back at Bubble Bobble and revealed the mechanics behind the seemingly random number generator and the game’s development. This week I’m taking a look at Dungeon Master, which has undeniably got a lot more going on.


Dungeon Master is an action-role-playing dungeon crawler made by FTL Games and released in December 1987 for the Atari ST. It was later ported to a variety of home computers such as the Apple II GS and Amiga, as well as consoles such as the SNES. It is the best-selling Atari ST game of all time. 

The game popularised the use of improving character skills by using the skill rather than the Dungeons and Dragons approach of experience points and levelling. Along with the Ultima series, dungeon master popularised the first person grid based gameplay style. 


There are several mechanics at work in Dungeon Master. Initially, and rather meta, the player takes the role of Theron, a non-corporeal entity who chooses and guides four heroes in the games. The heroes are chosen from the “Hall of Champions” where the player can choose to keep a hero’s skills, items and attributes, or rename the hero and build them from scratch. Doing this, rather than keeping the original skills allows the player to customise the hero and gives them enhanced attributes going forward. 

The Heroes come in four different classes: fighter, wizard, ninja and priest. They move through the dungeon in a 2 by 2 formation which dictates the effectiveness of any given party. For example, having four fighters would be redundant because the two fighters in the back row would not be able to attack enemies. Ideally a Wizard with ranged magic, and a priest would form the back row of a party. Additionally, only the front row will take damage from enemies attacking from the front with the back row taking damage if an enemy attacks from behind. The game allows for the heroes to swap positions in the formation. This mechanic allows for the player to move heroes in the front row, near death, to be moved out of harm’s way. 

The item management mechanic means the player starting the game with whatever items and weapons their heroes have on them. More are procured throughout the dungeon from shops and chests, or littered around the dungeon itself. Each hero has their own inventory with 14 equipable slots and 16 item slots. On top of this, each hero also has a ‘load’ or carrying limit. 

The most memorable and arguably greatest mechanic of the game is the spell casting system. On the right side of the screen are rune symbols. The game’s manual describes each symbols purpose. The player has to understand the semantics (or sentence structure), and each symbols meaning to cast a spell. This structure is “Power, Elemental Influence, Form, and Alignment”. Not all of these were necessary. For example, PAL VI is a strong healing potion, using a lot of mana, but LO VI is weaker healing potion (see image, above, for symbols). In the middle of combat the player is expected to remember the spells and click the symbols required for the desired spell in the correct order, which proves difficult and impenetrable to newer players. 

Food and water also form an important mechanic throughout the game. Food is treated the same as any other item, except it can be eaten and water is stored in characters water skins. Over time characters will get hungry and thirsty. Managing food and water rations adds extra intensity as sometimes both resources can be few and far between. 

The game also features dynamic lighting. One character must hold a torch or cast a light spell which slowly run down and causes visibility to decrease and darkness to set in. 

Although grid based, the game moves in real time. This means that heroes will get hungry, torches will run out and monsters will attack even if the characters are standing still. 


Since there are so many things going on in Dungeon Master, I thought I’d break down some of the more interesting and more complex. 

One of the more interesting things in Dungeon Master is the creation of enemies. The main game file contains a complete description of the game’s dungeon including doors, walls, items, and enemies, and it includes variables regarding them (How many creatures are allowed to be on the map at one time, the difficulty, decorative items on walls etc). The spawn of each enemy is tied to an actuator within the main game file, and the enemy’s statistics are generated randomly using the following formula:

SpawnActuatorHealthMultiplier * EnemyBaseHealth + Random Number between 0 and (BaseHealth / 4 + 1)

If the spawn actuator’s health multiplier is 0 then the level experience multiplier of the floor the player is on is used instead. This ranges from *1 on floor 1 to * 6 on floor 10 and below. This also means that a stab attack that gained 6 experience on floor 1 of the dungeon will gain 36 experience on floor 11. This nullifies the exponential increases in required experience to level up a skill.

Another interesting feature is the games skill levelling system. Skill levels can theoretically range from 0 to as high as the integer being used to store the value in memory can go. This is due to the way the game deals with levelling. Instead of having a fixed number of experience which is needed to level up, the game uses a power of two algorithm. For example: if level 1 is reached at 500xp then level 2 requires 1000, level 3 requires 2000, 4 requires 4000, 5 requires 8000 and so on. Each skill level has a name associated with it, such as “Neophyte” for level 1, “Novice” for level 2, “Master” at level 9. The highest name is “Archmaster” at level 15. (In the scenario earlier this would be reached at 8192000 experience.) 

Like many Role-playing games, there are a lot of maths and algorithms behind the stats and limitations that aren’t necessarily presented to the player. Another example of this is the weight or load limit which restricts how much each hero can carry. Each item has a weight and if the total weight of a hero’s inventory exceeds this limit the hero is encumbered. The limit uses the following formula:

BaseMaximumLoad = (8 * HeroCurrentStrength + 100) / 10 Kg
If HeroCurrentStamina >= HeroMaxStamina/2 then MaxLoad = BaseMaximumLoad
If HeroCurrentStamina < HeroMaxStamina/2 then MaxLoad = BaseMaximumLoad /2 + (((BaseMaximumLoad /2) * Stamina) / (MaxStamina / 2))

The hero’s Maximum load can also be modified based on injured that he hero has sustained. 

The Heroes health, stamina and vitality stats increase when a skill increases. 


The idea for Dungeon Master began when lead designer and Developer, Doug Bell thought he “could write a better game than Ultima” whilst playing that and Wizardry on an Apple II with his university friend Andy Jaros. After forming a company and running out of money, the pair were picked up by Wayne Holder’s company FTL, who had previously released SunDog. 

The game was originally titled Crystal Dragon and was being written for the Apple II. During development Atari announced the Atari ST and although they wanted to port the project over they felt it more important to release a game at launch and Crystal Dragon wouldn't be ready in time. Because of this, development was halted and they worked on porting SunDog. 

After launch FTL went back to working on the game, which had now been renamed Dungeon Master. Bell, in an interview with RetroGamer said that the game was originally written in Pascal, but in the end the programming language they used was C.

“We wanted to see what the performance was, and it was okay, but we realized that we needed to switch from Pascal to C. I spent three weeks learning C and rewriting the dungeon crawl in C, and the performance was better than expected.”

The game was created with a team of five people. Holder did some programming and handled sound but mainly was the game’s producer, Jaros and David Simon did artwork, which was programmed in assembly, Mike Newton handed the development tools. Dennis Walker and Bell handled the majority of programming. 

The game was originally smaller in scope and planned to release in 1985, but the extra time given by the release of the Atari ST meant that the team could expand their ideas and make a “landmark game”.

The level of immersion and realism was important to the development team. So much so that a lot of time was spent on new compression algorithms to prevent the need for disk swaps or unnecessary loads that would break the immersion.  The end result was a game that when uncompressed was 1.6MB and when compressed would fit on a 360K floppy disk. They also employed compression on items stored in the Atari ST’s RAM, which meant less loading time and more information could be stored. 

Dungeon Master was a massive success in it’s day, and spawned many sequels and clones. Chaos Strikes Back was an expansion that used the same engine as the original, and was also a massive hit in 1989. The game had many clones in it’s era including the great Bloodwych and Captive but it has influenced many games of this era such as Legend of Grimrock, available on steam and Elder Scrolls.

FTL unfortunately ceased operations in 1996. 

Paul R. Stevens, a fan of the Dungeon Master series, spent 8 hours a day for 6 months and poured through all 120,000 lines of code to port Dungeon Master: Chaos Strikes Back to windows, which can be downloaded HERE.

You can find all posts in this feature at 

1 comment:

  1. Feature: But How Was It Made? Dungeon Master - Blogabaloza - A Blog By Robert A. Lane >>>>> Download Now

    >>>>> Download Full

    Feature: But How Was It Made? Dungeon Master - Blogabaloza - A Blog By Robert A. Lane >>>>> Download LINK

    >>>>> Download Now

    Feature: But How Was It Made? Dungeon Master - Blogabaloza - A Blog By Robert A. Lane >>>>> Download Full

    >>>>> Download LINK dP