Printing and Stapling Booklets

After printing out the booklets a lot (that’s how I proofed the PDFs), I got to be an expert at duplexing a non-duplex printer. Here are some tips on how to print double-sided pages from a single sided printer, as well as how best to staple the booklet.

PRINTING DOUBLE-SIDED WITH A SINGLE-SIDED PRINTER
* Print out the PDF with “odd pages only” to your printer
* Flip the printouts face-up
* Turn the pages 180 degress so they are face-up but “upside down”
* Put the pages back into the paper tray
* Print the PDF with “even pages only”
* You may have to rearrange the page order

STAPLING THE BOOKLET THE CHEAP WAY
* Fold each page in half and assemble the pages in the proper order
* Find a stapler that allows itself to be “opened” and staple by pressing it
* put booklet face-down (i.e. cover pages on top) on carpet. The carpet keeps the staple from bending
* Bend the staples on the inside. BE CAREFUL.
* Staple in the center fold in two (or three) places

OTHER NOTES
* Going to a printer like Staples or Kinkos may do all of the printing (double-sided) and stapling for you for very little money
* You may be able to find a non-opening stapler to staple the center fold. This would be better than the “cheap way.”

User Interface Testing and A New Direction

Also posted on Dragonsfoot: http://www.dragonsfoot.org/forums/viewtopic.php?f=11&t=38180&p=778692#p778692

What I am really concerned about is rethinking the interface between the players (and GM) and the game. I am a notoriously prepared DM, but I find the traditional way modules are published to sometimes hinder my ability to comprehend and run a module. So I thought, why not use my experience in interface design, information theory, and philosophy to come up with something better?

This is not a dis of all the awesome stuff that is coming out. I am just doing some experimentation, and hopefully people can use the stuff that works and drop the stuff that doesn’t.

OK, so I made a whole module with the delve format, then ran it through several user interface tests, including running it a couple of times.

What I found was the following:

1) Having each room as a seperate GM and Player sheet got difficult to manage papers. First, it was hard to organize everything in loose leaf, but also just HOLDING and REFERRING to other things was difficult.

2) The players didn’t really look at the text on maps as much as I thought they would.

The first round of testing went really well when I did just one room, but the more rooms I did, the harder and harder it got.

So I did some soul searching (and delayed putting out my module!!!) to revamp the interface. What I needed was something that was easy to hold, easy to flip back-and-forth, and still gave the players information on the rooms.

So my NEW IMPROVED format is the following:
1) Each room is either its own page or two pages (if the text gets too long)
2) the module is presented in several formats:
—— a B&W handbook similar in form factor to the OD&D handbooks: 8 1/2 high, 11 wide (landscape) in a booklet form
—— a B&W handbook with sequential page numbers if you really don’t want to duplex your pages, or whatever
—— a B&W player section with “Battle Tiles” that you can cut out and use instead of drawing a room (better and than it sounds because they have all the furniture, doors, etc. on them). ALSO a B&W section of drawings by the awesome artist Steve Robertson
—— a color section similar to the above Player Section, with Steve’s color paintings, which are just really awesome and cool.

The testing showed this change was a huge improvement. I was able to run an encounter very easily and everything was organized so I never had to flip between pages for stats, etc. All of the relevant information in the room is in an easy-to-read and consistent format.

The upshot is that the player and GM sides are now two completely distinct things, making the job easier for the GM but making the experience richer and better for the players.

Hopefully I will be publishing the module on RPGNow in the next week or so, and I will also be putting it on MagCloud if you want to buy the really slick player handouts of the battle tiles and Steve’s AWESOME artwork.

SWOF Factor 1: Describing a Room to Players

Type of problem: Overload/Friction

I don’t know how many times in my gaming career that a DM has described a room and starts the action. Then one (or more) players start asking questions because aren’t sure how they relate to the action: where are they? What are they doing? Where are the bad guys? What is the environment like?

This situation is caused by several factors. First, there is a limited amount of “bandwidth” that the DM has to explain a situation. If they use only a very short description, then it leaves a lot of blanks to fill in to the players’ mental scheme of the encounter. If the DM goes on a long screed about every single bit of the room, then you have two problems. The first problem is the memory of the players (overload) and the second problem is their attention span. There is only so much information that a player can digest at any one point before it becomes too much.

Have you ever had an error on the computer that has about 500 words describing what is going on, with a “yes”/”no” dialog at the end? That’s the same problem. We ask the players to memorize this huge amount of data, form a cohesive mental map of the area, then act on it, all in a short amount of time.

To overcome spatial relationships, some contemporary games rely on there being a board with miniatures representing where the monsters and characters are located. I have done my share of gaming in this environment. This method solves a lot of the problems described above, but also has its downfalls:

1) Takes time to either do a quick map on the battle mat or to set up the geomorphs. Battle mats are quicker but with a lot less information. Geomorphs have more information but are relatively generic and are much longer to set up. (Friction)

2) The rules of the game start devolving into exact steps and minor movements. Five-foot steps, full actions, and attacks of opportunity. (Static)

3) The DM still has to explain what and where things are. Color text is not written down for players’ future reference. The only thing presented is a basic spatial relationship of “important” things like monsters and characters, but too often the physical environment in lost. When I watch an action movie, the scenery and environment are part of the excitement. Not too many action movies have heroes and villains duking it out in non-descript 10′ square rooms. And yet we accept this in our gaming materials. (Overload)

So in making a new interface for the players, I took into account the following goals:

1) All of the spatial relationships should be stated

2) The environment should be a critical part of the spatial relationships for two reasons
a) Players can more easily visualize the environment
b) The environment can become part of the action

3) The non-spatial aspects of the encounter should be clearly presented and easy to look up when the action starts

4) Non-spatial aspects of the encounter should add to the players’ imagination: what smells are there? How is the lighting? What Sounds are coming from the room? Putting more information at the players’ fingertips should help them vividly imagine the scene.

5) The player handout should be able to double as a battle mat so that it is easy to just place miniatures on it (or just some pencil marks) and start the encounter. The player handout should be faster than a battle mat but better than geomorphs.

OK, I’ll admit it. I also just LIKE player handouts. Barrier Peaks is one of my favorite modules….

So when I saw the “delve” format , I immediately saw that it was the grain of a great idea. While interesting, it didn’t address many of the problems above and didn’t solve a lot of the problems that DMs have. So by extending the ideas to player handouts (as well as the DM sheet), we can solve a lot of SWOF problems.

The players handouts can have all of the room layout and environment right there in front of them, for easy and immediate access. Instead of taking up the DM’s time, the players can explore and mentally map at their own pace. The general nature of the room should be in a short description at the top. The environment should have visual cues (i.e. pictures), but when necessary text should explain what is going on point out the feature. The room should be in 1″ squares so that the players can easily do calculations of distance.

This format will hopefully add a new dimension to our games.

Overcoming the Machine Model of Gaming

Chris Engle created an interesting model for RPGing at the Forge, posted almost 4 years ago (http://www.indie-rpgs.com/forum/index.php?topic=17125.0) and printed almost 20 years ago in Experimental Games Group.

His “machine model of gaming” sees running an RPG as a machinelike process that breaks down for four distinct reasons: static, overload, friction and waste (SWOF). By analyzing how our RPGs create these four problems, we can then try to overcome them.

I won’t go over the four in detail– I will let you read the original. SWOF, though, are constant problems in a game.

Some ways in which SWOF effects the game we can’t change or are very individual to the DM. Players talking over each other and rules issues, for example, are not something that we can really address within an adventure.

There are ways in which adventures can reduce SWOF, however.

Looking at an adventure as a machine, we see that there are several steps in making the adventure work. The DM becomes an interpreter like a computer interprets code. They are the middle ground between the adventure text and the players. The players are like users of a computer. They accept the output, analyze it, and then input their actions.

Using these ideas, running an adventure would look like:

1) adventure/program is read into the DM/interpreter’s memory
2) DM/interpreter makes judgments about the program
* preparation and notes
* what is important and how the program/adventure should be presented/run
3) DM/interpreter puts out output/description
4) Player/user takes this output, analyzes it, and then either:
* makes a decision
* asks for more output to better analyze the data
5) DM accepts input
6) GOTO step one and repeat

In pseudocode, this would mirror the classic computer-game code of:
while (game_running) {
gather_input();
update();
render();
}

It is the job of game and adventure designers to reduce SWOF in their products so that the DM and players can play the game to their maximum enjoyment instead of worrying about the factors that ruin their game.

Future posts will delve further into particular bits of SWOF that I think can be overcome with a new way of looking at the adventure interface.

Little Fires Free Sample Download

Little Fires

This sample download has the DM and player sections for a complete play experience. The DM’s copy has all of the information necessary to run the room. The Player is intended to print out and give to the players so they can explore the room visually instead of just through the DM’s description.

Guard Room Free Sample Download

The Guard Room

The Guard Room is a sample room for free download.  This room is a sample of the FiftyLatches layout and design.  Every room in our modules is laid out for ease of use and a great play experience.

Fifty Latches is Born!

Welcome to FiftyLatches.  We are a new company publishing old-school gaming material for games like OSRIC.  More information to come!

Old-skool gaming rethought