Archive for フィル
-
-
My girlfriend is a keen fan of The Bold & The Beautiful, and I am a keen fan of the episodes in which Ridge's sexy daughter takes her clothes off in the name of some contrived plot development and / or fanservice. The upshot of all this is that I reckon it would be a lot of fun to play an over-the-top soap opera RPG.
Join me in my brain as I go through the steps of turning this whim into the core of a game, 24 Hour RPG style. I'll start by taking the Pineapple Salad approach of reducing B&B to its main tropes. To me, these are:
Character names that are either wilderness things or saintly virtues
Typically these are something animal ('Hawk'), vegetable ('Thorn'), or mineral ('Ridge') found in the great outdoors. Occasionally you get a non-wilderness name embodying one of the seven heavenly virtues ('Hope', 'Faith', etc).
Meaningful stares
These ham-fistedly convey an emotion that sums up the characters' feelings about the something. Hmmm, she looks confused by the unexpected results of the DNA test. These stares tend to go on a bit too long with a lot of cutting back and forth between the actors, with the net result being unintended comedy.
Constant affairs with anyone who isn't the character's biological mother or father
Stepfathers, adopted sisters, nuns, etc are fair game.
A chain of ludicrous happenstance leads to a ridiculous betrayal
You can't make this stuff up.
Cylic plot with no final resolution
Hundreds of episodes pass as every possible permutation of affair and betrayal is played out.
Slow moving plot with repetitive expository dialogue
Characters continually paraphrase and rehash statements from the past 3-5 episodes, in case the viewer missed a few.
Men are wealthy magnates, women are celebrities
The women here are models, actresses, singers, tennis players etc. This makes fashion, jewellery, magazines, the music industry and so forth good things to be a magnate of.
Community service messages
TV networks can be excused from broadcasting a community announcement if they put the equivalent message into one of their soaps. Perhaps Ridge starts smoking crack and has to choose between keeping his luxury yacht or selling it to buy more rocks.
"This crack won't smoke itself."
Where to from here? Having identified the themes, next I'll have a stab at turning them into game mechanisms. If that's done as exhaustively and realistically as possible, you end up with a simulation rather than a game (which may be appropriate for a wargame, but doesn't float my boat as an RPG). So there's a balance to be struck between evoking theme and making things too crunchy.
Uwe Rosenberg says that he likes to bring the enjoyable activities in a game to the fore. Those are the things that would be fun to do even if you weren't playing a game. So for Bohnanza, that's haggling and swapping, and for Agricola, that's making a little toy farm with wooden animals. So, what are the play activities inherent in the list of tropes above, and how much fun are they? From most to least fun, I reckon they are:
1. Meaningful stares
The potential for eyebrow acting, scenery chewing, and giggling here is excellent. Try it with a friend! This activity is fun enough that I reckon it should ritually end each scene of the posited RPG. (Perhaps an egg timer should be involved...)
2. Chains of ludicrous happenstance leading to betrayal
This is not a million miles from the core fun in Fiasco. We know where the characters are now, we know we want them to end up in a certain dumb situation, and we are authorised to join the dots by making up whatever stories we like.
3. Constant arbitrary affairs
This sounds to me like the mechanism by which 1. and 2. are accomplished, with any intrinsic fun value lying in the reveal of the affair du jour. In a soap opera there's generally one spotlight affair happening with a true love type scenario for contrast. The relevant characters could rotate from scene to scene, or be predetermined at the start of the game.
4. Incorporating community service messages into regular conversation
Entertaining in moderation. We can't have every character doing this or else it would dominate the game. Perhaps one message per character per game.
5. No resolution
And therefore no conflict resolution mechanism... every scene is a cliffhanger!
6. Repetitive expository dialogue
It would be fun to have every scene begin with a clunky expository rehash.
7. Men are wealthy magnates, women are celebrities
Should be a fun wrinkle for character creation. Choose your business or describe your fame.
8. Funny character names
These are mildly amusing, but you only want to invent them once per game. Too many of these can be annoying, as anyone who's read a published Paranoia module can attest.
OK, so now I shall invent some point-form rules that broadly implement the above findings.
1. It's a 4-player game, because there are four types of name
2. It's GM-less game because passive consumption of a soap opera plot is too simulationist for my tastes
3. Each PC has one type of name (animal, vegetable, mineral, virtuous)
4. Two male PC business magnates, two female PC celebrities
5. Character creation consists of choosing a name type + name, a gender, a magnate or celebrity type, an a community service message
6. Each PC will frame four scenes (in any order): a colour scene of their happy relationship, an affair with another PC, a contrived betrayal of another PC, and a community service message relating to another PC
7. A scene begins with the active player naming the scene type and casting the scene. The target PC for that scene type must be included (e.g. the PC receiving the message in a community service message scene), but the other two players may be cast any combination of PCs, NPCs, or props (trees, cars, etc).
8. The scene proper starts with a clunky expository rehash of the situation leading up to the scene. The scene then continues until there's a conflict related to the scene type. The conflict does not get resolved.
9. The scene ends when the PC and the target PC start staring at each other meaningfully because the conflict isn't resolved. Other characters or props may join in the staring.
Polaris has a clever idea for handling the relationship map that point 4 implies: seating arrangement. Using seating arrangement in a four player game, you can have a two-way equivalent relationship with the player opposite, and a pair of one-way relationships with the players to your left and right. These neatly map to the three scene types: an affair with the PC opposite, a betrayal of the PC to one's left (mnemonic: betrayal is sinister), and a community service message about the PC to one's right (mnemonic: you are right about whatever it is). Having an affair with the person opposite implies an offensively heteronormative boy-girl-girl-boy seating order, meaning that you begin the game in a relationship with the adjacent PC of the opposite gender. You could be married, engaged, dating, whatever makes sense. Here's an example of a relationship map:
And a character sheet looks something like:
Name Type: Animal / Vegetable / Mineral / Virtue
Name: Hedge
Gender: Masculine
Internationally Famous As A Wealthy: Gold Bullion Magnate
Relationship: Married to Crystal
Having An Affair With: Chastity
Will Betray: Crystal
Has A Community Service Message For: Bobcat
And That Message Is About The Evils Of: C02 emissions from container ships causing global warming
Scenes Left:
- Happy Relationship
- Scandalous Affair
- Ludicrous Betrayal
- Annoying Community Service Message
Keen to hear your two cents.
Fri Nov 25, 2011 12:26 am
-
-
RPGgeek now supports the ePub format for uploading files, so this is a good time to talk about what ePub is and why you might like to use it for your RPG or gamebook.
An ePub file is basically a zip archive containing a bunch of HTML files, some metadata files (like a table of contents), and any images referenced by the HTML. The component files are all human-readable, so you if you're really keen you can create them in a text editor like Notepad, zip them up into an archive, and change the extension to .epub to produce an ebook manually.
The purpose of ePub -- as opposed to something like PDF -- is reading on a screen or an eInk display. (It's no good for documents that need printing out, like pretty player aids.) Screens come in all shapes and sizes, from big widescreen LCDs, to portrait format ebook readers, to tiny mobile phone screens. ePub works on these different devices by doing away with defined pages and reflowing the document text to fit the size of the screen, just like a well-designed web page. A chapter of a novel might be four pages on the giant LCD but thirty pages on the tiny mobile phone. Compare to a PDF where the number of pages never changes, and the text size just grows or shrinks (which is tough on those mobile phone users).
As an HTML-based format, ePub supports internal links. These are typically used for things like a table of contents, but they can also be used to create Choose Your Own Adventure style gamebooks. Most ePub readers support annotation, so the reader can keep track of hit points and equipment right inside the gamebook.
For an RPG I think best practice is to provide the buyer with both a PDF for printing and an ePub for reading. I'm starting to see a few RPG books coming out in this dual format already; the new edition of Nobilis is one example.
If you want to make your own ePub without dealing with archives full of weird XML metadata, you can create a simple HTML document instead and covert that to ePub, leaving your conversion software to handle all the technical stuff. For non-programmers, a good HTML editor to try is BlueGriffon. It's free and it runs on Windows, Linux, and Mac.
Don't start with MS Word, whatever you do. If your RPG is already written in Word, then you'll have to cut and paste the text into an HTML editor and continue from there. Word can save to HTML, but the HTML it produces is not clean enough to convert to ePub reliably. Same goes for PDF or any desktop publishing format -- copy and paste the text into a basic text editor or HTML editor before you continue. If you've copied from Word you may also have to replace its weird hyphens, apostrophes, and quotation marks with plain text versions.
ePub files are intended to be read on a variety of devices, so you have to keep the formatting very simple. Treat it like a Penguin Classics paperback book: paragraphs, headings, italics, but no fancy diagrams or layout. Someone is going to be reading it on a phone so think carefully how you're going to format tables and charts. If you must include images, try to use black and white line art or greyscale photos so as to make things easy on monochrome eInk readers, and try to make the images small enough to view on a phone.
When you're done composing your masterpiece, you just put your HTML file through a converter and a pretty good ePub should pop out the other end. If you're not sure how good your HTML is you can run it though HTML Tidy to clean it up.
OK, so let's say you've produced a nice simple HTML page in the editor of your choice. Now to convert it you will need some software. The best choice for this is Calibre. Calibre is a free, open source ebook manager than runs on Windows, Mac, and Linux. As well as doing excellent ePub conversions it also does comic books, Kindle files and a bunch of other stuff. If you own an ebook reader, Calibre is also a superior replacement for whatever terrible ebook management software shipped with it. (My Sony ebook reader would be useless without Calibre.)
Calibre has a bunch of ePub conversion tutorials, or you can just click Add Book to import your HTML, select your HTML file once it's imported, click Edit Metadata to give it an author and title, click OK, then click Convert. Easy.
An alternative to the Calibre HTML conversion approach is to use the Sigil WYSIWYG editor. Sigil is a cross platform open source ePub editor, and in fact it's the only program that can open, edit, and save ePub files (everything else just converts to ePub and can't open an existing file). This sounds like just the ticket, but at the time of writing Sigil is only at version 0.4. It's quite new and buggy and not really ready for prime time yet. I had a stab a making an ePub version of Year of Meteors (six pages of plain text) in Sigil and even that simple document caused it some trouble. At present, most people use Sigil to tweak existing ePub files rather than to create them from scratch.
Here's an example of an ePub I created just using Notepad, HTML Tidy, and Calibre. It works pretty well on a phone, on an e-ink reader, and on a PC: Mist-Robed Gate ePub
Thu Nov 10, 2011 10:53 pm
-
-
Last week I emailed out some blind playtest kits for a wargame design that Jesse, Murray and I have been sporadically tinkering with. The game is at the point now where we have to make a decision about a problematic area of the board in an unbiased fashion, so a bit of playtesting will hopefully help. Here's the tale of my latest experience creating a playtest kit...
A playtest kit has two elements: components and playtest instructions. The components are relatively simple, as they are just a bunch of files with boards and cards and rules. The instructions are more difficult but arise naturally from the goal of the playtest and the idiosyncrasies of the components. You can't really write the playtest instructions until you've looked at the components as objectively as possible. Let's look at the components first.
The kit had to include a rulebook, but I knew I was bound to forget something in the version that I sent. So prior to sending out the kits I gave it a thorough review to try and eliminate references to old rules and to clear up the language. The rulebook is currently a wiki so that the three of us can work on it collaboratively and track changes. After much debating with myself I sent a link to the wiki rather than a PDF, so I that I could make the inevitable last minute changes after I hit the send button. And there were many. But this approach meant that the rulebook could potentially change during the playtest period or differ from playtester to playtester. To make sure everyone involved knew which version of the rules we were talking about, the playtest kit had to include an instruction to print the rulebook and also to record the date on which the rulebook was printed.
The cards (it's a card driven wargame) were just a PDF file printable on A4 or letter. They were in pretty good shape with no errata for the card text. But how would a first time playtester go from a PDF to useful cards? I had to assume that the testers had never built a prototype, so that meant that the playtest instructions had to include that information. Print out the cards on thin paper, cut them up, put them in card sleeves, slip a playing card behind each to get enough stiffness to shuffle.
The cards in the playtest kit also differed from the illustrations in the rulebook, so that had to be explained. Murray designed the cards in the rulebook to be beautiful and functional, with iconography, colour etc that is player-friendly. They look like this:
I had the version of the cards with the latest rules text that needed testing. They had the same UI elements, but unfortunately they looked like this (note the different card effect):
So now the playtest instructions also had to list the differences between the two card formats. The rulebook says that the card is blue, but the one I've given you is white. The rulebook shows icons on the lower right of the card, but the one I've given you has MS Wingdings under the card title instead. And so on.
The board was a similar story. The file I had has one extra location not found in the rulebook. So the playtesters have to print out the board and cross out that area. The file also had some icons that are no longer used, and have to be removed. Finally, the file had older terminology than the rules -- different names for the same locations. More instructions, more scribbling. As with the cards, the rapid changes to rules have outpaced the artwork, because there's no point investing a lot of art time in something until the changes settle down. The board was optimised for A2, but the testers were international, so I also had to include some instructions for Americanising the file.
It's a block game, so there were block labels to email out. Naturally, the labels I had for them were not as pretty as the labels in the rulebook. It's hard to email wooden blocks, so I had to tell the playtesters how many of those they need to source. Sadly, I forgot to tell them where they could obtain blocks (teacher supply shops and wargame publishers).
The dice were easy... everyone's got some d6 handy, right? A small vindication of using cheap off the shelf components.
OK, so at this juncture I had sorted out the components and a huge wad of component-related errata and assembly steps. Next were the actual playtest questions. These were things like: how long did the game take?, which rules questions could not be answered using the rulebook?, what would you change?, and so on. Like a radio interview, these were phrased to avoid yes / no answers. Finally I had to include some expectations. As it's a blind playtest I had to ask the testers to suffer through the rulebook as written rather than emailing me rules questions. The rules are still undergoing rapid prototyping, so I asked the testers to reply by the end of the year (even if just to say they didn't have time to test anything).
I don't expect much of blind playtesting. If you send out 100 kits you are lucky to get 5 useful reports back. This design has the additional limitation of testers needing to provide expensive wooden components, so it will be a miracle to get even one response. But making a playtest kit is free, and it's a good exercise to reveal unexpected design goals and hidden limitations of the rules and components as they stand. If you are going to take your prototype to a con or protospiel, this is exactly the sort of thing you need to do beforehand.
|
|
