So I wanted to learn how to use Inkscape, and I thought that I might as well do something productive while learning it. I have been preparing to run B2 Keep on the borderlands for a while and the blurred washed out map in my PDF version really didn't do it for me. I had trouble even seeing the numbers in the rooms.
So I decided to reproduce the maps in vector format so it can be printed at any size and still be sharp and crisp. I also wanted to make a version of the wilderness maps based on hexes as i find them far easier to run at the table. Below I will explain the maps in more detail, but if you just want the maps they can be downloaded at the bottom of the page.
The Wilderness
I have discretized the map into hexes. I decided on a scale of 1 mile per hex as this scale could contain all the general features of the original map and sized the map to fit exactly with the scale. In the image below you can see how they fit on top of each other
I wanted to make it all fit inside a 6 mile hex so I expanded on it a little. You could also just decide that the hexes are 6 miles instead if you want a trip to the caves to take around a day. This would make the super hex 36 miles
The Caves of Chaos
For the Caves of Chaos I only wanted to change three things. First I wanted all the features to be clear and easily readable and able to be printed in large size. Second, I wanted to separate the above ground features and the below ground ones since they are not used at the same time and only clutters the map. Third, I wanted a handout version so new players could have a good starting point for their own mapping. It should also be noticed that only the DM version of the above ground map contains the caves that are hidden by foliage and the identifying letters for the caves (I didn't want them to feel there was any order they should explore them in). The PDF of the caves therefore comes in three pages:
Below ground
Above ground
Player handout
The Keep
I did not make a version of the map of the Keep, since the only problem i had with the original (the grid) has already been taken care of by Dyson in his version.
I recently became interested in learning JavaScript. I have done a lot of programming before but for some reason it only recently dawned on me how easy and powerful it is to use JavaScript on the web. Much to my delight I found out that Blogger fully supports it. This means that all the Excel functions, all the Random tables, all the house ruled home brewed calculation programs could be directly available and interactive right there on the blog posts themselves.
To introduce this to people that haven't tried JavaScript, or even tried programming I will show a small example of a function that rolls a random result from a table in 9 lines of code. The table used in this example are the first level encounter table from Basic D&D. It can be seen (and interacted with) below:
To allow blogger to interpret the markup and code you are about to add, there is only one thing you need to do. In the post editor, you need to enable the setting "Interpret typed HTML" as shown below in the picture. For this example it will also be advantageous to enable "Press "Enter" for line breaks" to make sure there are line breaks in your table. (that is how my function known where to separate the table)
The HTML markup
My function works by reading content directly from the blog post, manipulating it, and putting the result back into the blog post. Therefore, it needs to know where each element is located. To do this we use a thing called id in HTML. If you go to the HTML of your blog post (upper left corner) you will see what is called tags. The ones that start with < are opening tags and the ones that start with </ are closing tags. Everything in between those two are the tagged content. To tag a line of text as a paragraph for example we would do this:
<p>This is a paragraph</p>
If we then want to give the paragraph the id, this_is_an_id, we would write:
<p id="this_is_an_id">This is a paragraph</p>
The function I have written is hard coded to look for elements with the idsrandom_table and table_result so we need to use these ids for the function to work. The table is therefore tagged like so:
and the empty place where the result is wanted is tagged like so:
<div id="table_result">
</div>
The button
A button can be inserted using the HTML code below. Whatever is entered as the attribute onclick is the name that the button will be searching for when it is clicked, so we want to make sure there is a function named random_table_roll(). As you might have guessed from the example, the content of the button tags is the text shown on the button:
The JavaScript itself is shown below. To keep the colours and make it easily readable I just went and took a screenshot. If you want to view or copy the actual file it is located here. You can use any text editor to read or write these files as long as you give it the file extension ".js". I have explained each line in the code but in short, the function does the following: (1) read whatever is given the id random_table, (2) separate each line and clean up line breaks and (3) spit out one random line by inserting it into whatever is given the id table_result.
To attach the script to your blog post, there are two ways. First, the actual lines of the script could be pasted directly into the HTML. You only need to tag the whole script with the opening tag <script> and the closing tag </script>. What I would suggest however, is hosting it somewhere else. This is necessary if you want to reuse your script on other posts without copy/pasting it all, it also lets you update the script everywhere at once and it generally lets you avoid pasting huge chunks of code into your HTML. I have hosted this example function on my google drive using the directions found here.
To link an externally hosted script to your HTML you put the following line of code in and change the link to the direct link to your script instead. (without any line breaks in the src attribute)
Following Simon's latest post On the classic crushing trap i wondered why on earth the sliding block in the false entrance to the Tomb of Horrors was made so big. With a mass of 170 tonnes, it weighs 17 times as much as the biggest blocks used in the pyramids.
To keep characters locked inside until they starve to death, this certainly seem overkill (at least if you are forced to figure out how the hell this gigantic this moves seemingly on its own) But how how strong can we actually assume that characters in D&D are? Would they, given enough men, be able to push it?
The AD&D DMG explains that a character will be able to lift the equivalent of this own body weight over his head with a strength score of 18. For each percentage point of exceptional strength above 18, he will be able to lift more up until the limit of around 500 lbs (230 kg) if the character were to weigh 210 lbs. This is actually pretty spot compared to the real world as the current record according to Guinness is at 233 kg. (or 2,3 kN).
The AD&D DMG, however, produces no numbers that i can find of how much weight a character might push. So what kind of pushing force can a human being actually produce? We can start by looking at real world weight lifting records to get an impression of how much force the muscles in a human body is capable of. If we assume ideal conditions we should start by looking at bench press records for arm pushing strength and leg press records for leg pushing strength. These are 488 kg (1075 lbs) and 1118 kg (2465 lbs) respectively, giving a 1606 kg total. or 15,7 kN. This number would certainly be an extreme upper limit of the human muscles considering that no reducing factors are considered and the muscles are seen at their individual limits.
In engineering we often use the terms of upper and lower bound solution meaning that the real solution must be in between these two, so looking at the before mentioned records of actual weight lifting where the contestant also has to balance whatever he or she is lifting we are looking at only 15% of the extreme solution. It can therefore be concluded that the actual maximum pushing force of the human body lies between 2,3 kN and 15,7 kN.
The factors that determine where the actual maximum lies would be balance, footing, inclination and the strength of human bones. First, even though pushing an object is not the same as lifting something over your head, there is still some sort of balance that must be kept. Second, the limit is also strictly subject to the footing since you would slip or slide when the limit of the friction force between the floor and the soles were met by the pushing force. This factor can be mitigated by pushing something vertically over your head, but then balance becomes more of an issue. Third, unless you are pushing something directly over your head, not all of the force you create will be translated horizontally. The force will also have a vertical component. Last, The maximum forces found above was found by simply adding the maximum force of the muscles in the legs and arms together. I have seen videos of men breaking their own bones from the force of their arms alone, so it seems very plausible that the combined force of two muscle groups could break bones before reaching their extreme.
So in the end, there are too many factors to make a more precise presumption than a feeling that going over 50% of the upper bound solution would seem too unrealistic as there are many factors that will always apply. So even though this can only serve as a figure of magnitude of the maximum pushing strength of the human body, A force of 8 kN shouldn't be too unrealistic.
Simon has got a really interesting thing going on his blog lately. In a series of posts he examines traps mechanically to gain a better understanding of how they might function exactly. For a while, I have thought that the best way to run traps is an organic and exploration based approach (If you happen to be at a loss as to how a trap might be run like this, I suggest reading the examples in Matt Finch's A Quick Primer for Old School Gaming).
Having myself only started role playing games as late as during 4E D&D, this approach was kind of an eye opener to me. I learned that traps should look like this.
I learned that a trap consists of a trigger, an attack, a perception DC for spotting it and a thievery DC for disabling it. And then a whole lot of superfluous information. There is no harm in creating a uniform stat block so a DM always knows where to look for the needed information, but when the stat block you have created demands that the first four lines of the block all convey the exact same information in varying levels of detail, maybe something should be reconsidered (?).
Aside from encouraging the players to just press their "skill buttons" instead of making decisions, these traps (and this one in particular, since it is included in the 4E DMG) teaches new DMs by example that they should prepare all the characters' options and make them part of the trap. The DM should consider the chance of spotting it, the chance of disabling it and all the different actions that possibly can be taken including this trap.
The big problem occurs when a player tries to do something that is not covered in the stat block. Now the DM fumbles around looking for any information that might be used and probably ends up just assigning some arbitrary DC and making the player roll some dice, because the DM only knows that when a character steps in the designated square, an attack will be made with the character as a target. The DM does not know how the trap functions.
If the DM instead had a picture in his or her head of the mechanisms of this trap and how they interact, they would know the answer to every question and every action on the player's side intuitively. To be able to run traps organically and even without any dice rolls. I think the first step is to know the trap inside and out. Whatever the player tries to do, the DM should know how it logically should affect the trap.
I encourage you to follow along with the posts on traps on Simons blog. I might also write up some of my own examinations of traps for my own game here, as I certainly won't be using a trap without knowing exactly how it functions from this time forward.
