News:

Forum changes: Editing of posts has been turned off until further notice.

Main Menu

First Person or Third Person writing

Started by ADGBoss, October 15, 2003, 11:50:13 AM

Previous topic - Next topic

ADGBoss

I was working on a few re-writes of my games (Seraphim and EODL) and was working on an introduction for EODL in particular.  Actually its an itroduction to one of the chapters and I was speaking of design choices.  Now in the introduction to the entire game I think its very appropriate to say "I" as I am the writer/designer.  If my editor or editors write an intro then they too can use "I".  However, in game, it is offering me a conundrum.

Do I

1. Use 1st person in the game design because its not really a group effort (other then Ron's favorable review and Simon's very helpful commentary plus play testers).  It seems more personal, reaching out and teaching the player how to play.

2. Use 3rd Person, more impersonal but certianly professional.

3. Try to avoid mentioning "the designer" or such issues in the text.


Sean
AzDPBoss
www.azuredragon.com

LordSmerf

My suggestion would be to avoid discussing design if you can.  Alternatively, use off-set color-coded text boxes to discuss design.  Most people just want to know how to play the game, look at an instruction manual for any other game for a good guide...

Thomas
Current projects: Caper, Trust and Betrayal, The Suburban Crucible

Mike Holmes

Like Smerf says, offset these things. But even then, I feel it's bad form personally to refer to the author at all. I mean, if the work has that informal style anyhow, then no big deal. But I think it's better to keep it formal otherwise.

So, in this case, let's say what I want to communicate, is "I put in Hit Locations because they give a more interesting output to the combat system." Well, it doesn't matter what you want, just what the design is about. So, rather put in, "The Hit Locations roll exists to give a more interesting output to the combat system."

You can always avoid refering to yourself.

Another thing to do is to include these notes in a chapter all by themselves at the end. In that case, changing to the informal would be less jarring. Some chapters like this are like a letter to the reader. In any case, you can have notes like "(for the design rationale behind this, see page 122). Even better, have a symbol in the margin with the page number in it, and maybe a section number, that indicates that there's a design note about the rule in the back. A lot of layouts are doing this sort of thing, and it's pretty cool.

Mike
Member of Indie Netgaming
-Get your indie game fix online.

ADGBoss

I do like the idea of off-setting or color coding the designer notes.  Maybe even setting them off in a box.  I am not sure I agree with you though that most people do not care about the design bits.  The background can often be a good point of learning for the new player and veterans alike.

I do appreciate that not everyone agrees with that but the game seems too impersonal that way.


Thanks

Sean
AzDPBoss
www.azuredragon.com

ADGBoss

Quote from: Mike Holmes

So, in this case, let's say what I want to communicate, is "I put in Hit Locations because they give a more interesting output to the combat system." Well, it doesn't matter what you want, just what the design is about. So, rather put in, "The Hit Locations roll exists to give a more interesting output to the combat system."

I believe thats probably the way I will go with it.

Quote

Another thing to do is to include these notes in a chapter all by themselves at the end. In that case, changing to the informal would be less jarring. Some chapters like this are like a letter to the reader. In any case, you can have notes like "(for the design rationale behind this, see page 122). Even better, have a symbol in the margin with the page number in it, and maybe a section number, that indicates that there's a design note about the rule in the back. A lot of layouts are doing this sort of thing, and it's pretty cool.

Mike

I can see some logic in that approach.


thanks

Sean
AzDPBoss
www.azuredragon.com

LordSmerf

I like Mike's suggestion of a seperate chapter.  Especially if you annotate the appropriate material.  Personally i love to read design notes, to see what was tried and what didn't work and why a given solution was used...  However, it tends to bog down the actual rules explainations.  Present the rules first, explain why they are the way they are later...

Thomas
Current projects: Caper, Trust and Betrayal, The Suburban Crucible

ethan_greer

Something also to consider is that the style and flavor of the text itself should contribute to and emphasize the author's prefferred style of play.

For example, compare the texts the of D&D3 core books to that of kill puppies for satan.  Both writing styles serve the respective games they present.

Just something you may want to keep in mind as you decide how you're going to write.

Good luck!

RobMuadib

Quote from: ADGBossI was working on a few re-writes of my games (Seraphim and EODL) and was working on an introduction for EODL in particular.  Actually its an itroduction to one of the chapters and I was speaking of design choices.  Now in the introduction to the entire game I think its very appropriate to say "I" as I am the writer/designer.  If my editor or editors write an intro then they too can use "I".  However, in game, it is offering me a conundrum.

Do I

1. Use 1st person in the game design because its not really a group effort (other then Ron's favorable review and Simon's very helpful commentary plus play testers).  It seems more personal, reaching out and teaching the player how to play.

2. Use 3rd Person, more impersonal but certianly professional.

3. Try to avoid mentioning "the designer" or such issues in the text.

Sean

I'd say use the 3rd person, and avoid talking about yourself except for a foreword or designers notes. If you've ever read any Palladium stuff, there are several sections in the rules where, I assume it is kevin, says something to the effect of "I think this is the coolest way to do hit location" or similar. I found that ungodly infuriating. I suspect a fair number of other people would too, in that they want to learn how to play the game, not listen to your pet peeves in the middle of the hit location rules. Luckily for kevin Simebieda his core audience mostly just looks at the pictures or something. (OK, I admit putting "I think" or "I like" statements in rules texts is a major pet peeve of mine. Of course it's what you like or thought was best, your the designer, duh.)

best
Rob Muadib --  Kwisatz Haderach Of Wild Muse Games
kwisatzhaderach@wildmusegames.com --   
"But How Can This Be? For He Is the Kwisatz Haderach!" --Alyia - Dune (The Movie - 1980)

Daniel Solis

Quote from: RobMuadibOf course it's what you like or thought was best, your the designer, duh.)

Actually, most traditional designers will tell you that what you "like" has little bearing on the solution to a problem and should never be mentioned when presenting the solution to a client. If it was all about the personal preferences and biases of the creator, it would merely be fine art, not actual design.

To me, game design has all the same essential elements as graphic design, industrial design or interactive design. A professional would not go into a meeting spouting a long list of "we liked this" or "we think this is really cool." Rather, they would come into the meeting having already thought long and hard about the problem presented to them, done a healthy amount of research into finding innovative, effective solutions to the problem, and present those solutions to the client in an objective manner.

The text in the rules section of an rpg, and, to an extent, the text throughout the document, is analagous to talking to a client who is unconvinced, or at least neutral, to whatever solutions you and your team have devised. The best suggestion I've seen on the thread so far has been to annotate the rules. This way, the system is explained succinctly, without mention of personal bias and without mention of anything that pads that section of the text to be lengthier than it need be for maximum immediate understanding and re-reading.

Then, if the reader cares at all, she can check the appendix in the back of the book for the bits of research, other aborted system ideas, explanations of probabilities and what playstyles those probabilities are meant to enforce.

In essence, this is what I would do if hired to redesign, say, the branding identity of a client's service or product. I'd present the problem they gave me when I was hired, present my solution succinctly and objectively, then back up the solution with actual facts ("Your problem indicates a misdirected target audience. You want to target young punk rockers, not middle-aged professionals. A survey has shown this audience to prefer this sort of imagery and, more importantly, to spend more money on products showing this sort of imagery....").

But there is always the consideration of audience. Just as I wouldn't make a sterile, lifeless visual identity for a punk-rockin' music label, I wouldn't meet that client while wearing an Armani suit, speaking hoity-toity college-boy English or bearing any of the insignia of the Man. I'd speak as an equal, in a casual and likely snarky tone of voice.

There you see the aforementioned differences between the text in D&D and Kill Puppies for Satan. Two problems, two solutions, two methods of presentation of the solutions, both equally valid.
¡El Luchacabra Vive!
-----------------------
Meatbot Massacre
Giant robot combat. No carbs.

M. J. Young

I guess this simmered in the back of my mind over the weekend, and suddenly I realized why I couldn't figure out the answer.

Don't tell the reader what you did or why you did it.

Tell the reader what the game does and why the game does it.

"By doing this, the mechanics support...."

"This enables the system to...."

You don't have to mention yourself at all; when you're explaining why you made the choices you did, you can personify the game itself as doing things for the reasons you had for having it do that.

Make sense?

I think this is what we did in Multiverser in most places where we explained mechanics choices.

--M. J. Young

Daniel Solis

That's a way to go about it, which I've done on occasion, but it's tricky making sure that it doesn't become too obvious that the writer is replacing "I" with "the game."

On a similar note, what place is there for second person writing? It's such a headache in game-text having to specify when certain things pertain to character or player, but not both. Often, it would seem to be common sense, but one can never be too sure. So what is the solution there? Is simply referring to the reader as "you" suitable for both player and character references or should the author always be very explicit. "When you wish to perform an action, roll dice." vs. "When your character wishes to perform an action, you roll dice." There's still a further level of author/audience detachment, I suppose: "When the character wishes to perform an action, the player rolls dice."

So which gets the point across most effectively without becoming a tedious read?
¡El Luchacabra Vive!
-----------------------
Meatbot Massacre
Giant robot combat. No carbs.

ADGBoss

All...

As usual your well thought out replies have helped me immensely and I do thank you.  I actually have learned something which is a pleasant surprise.  :)

Gobi, in answer to your question...

When describing Mechanics of System I tend (or intend if my previous writing has not shown this to be 100%) to use "Player" or a term that infers the person rolling the dice, not their character.  I think it sounds more polished then saying "you" but not having any rules right in front of me I cannot for sure say I would never refer to the player as "you." Hmmm more food for thought...


Sean
AzDPBoss
www.azuredragon.com

David "Czar Fnord" Artman

From my own style guide:

Rules - Written in third person (ideally, "no person"). Formal. Minimal, tech writing format.
Examples - Third person. Informal (author's voice noticed). Rules in parentheses, often abbreviated.
Flavor Copy - Appropriate person (1st, 2nd, 3rd). Narrative. No rules.
Designer's Notes - First person plural ("we"). Narrative. Rules as needed for examples.
If you liked this post, you'll love... GLASS: Generic Live Action Simulation System - System Test Document v1.1(beta)

lumpley

Hey.  Write with passion.  Whatever that means to you and yours, but seriously.  If you set out to rob your game text of life, I promise you you'll succeed.

I could rant loud and long about the unnecessarily bad writing in game books, but I'll spare you.  Just: it's bad, it's wicked bad, and there's no reason for it.

Especially, rpgs aren't technical manuals.  An rpg has to sell itself.  Technical manuals, there's some preexisting product that does all the selling.  Every single word and sentence of your rpg should show me how much fun playing it is gonna be.

If I never read another no-person passive-voice rpg text as long as I live, I'll be happy.  Polished, schmolished.

Say "I" when you mean you the author, "we" when you mean you and your cohorts, "the game" when you mean the game.  Say "you" when you mean the reader, "you, the player" when you mean the reader as the player, "you, the GM" when you mean the reader as the GM.  Say "the player" or "the GM" if you think the reader won't be the player or the GM.  The best writing for rpgs is simple and direct.

Don't say "dice are rolled."  Say "roll the dice."  You! Yes, you! Stop looking like you wonder who I'm talking to and roll the frickin' dice!

If you need to explain why you did something some particular way, feel free, but only if it'll show (not tell) how much fun playing the game is gonna be.  Don't try to hide behind "we" or "the game," just out with it and move on.

Your audience is gamers like yourself.  Dude I'm your audience, not some faceless suit.  He might be making mental checkmarks against you for showing your personality, but I'm sure as hell not.

-Vincent

David "Czar Fnord" Artman

Well, lumpley, everyone has their opinions. I set up my list of guidelines for very specific reasons--common to publishing in general--prior to applying opinion:

"Rules - Written in third person (ideally, "no person"). Formal. Minimal, tech writing format."
After the first read of a game book, rules become referential material. Referential material must be easy to scan (find in book) and quick to review for critical points (uncluttered with extraneous information).

"Examples - Third person. Informal (author's voice noticed). Rules in parentheses, often abbreviated."
Examples demonstrate applications of rules and, as such, should be put into the context of playing the game: writing up a power, testing against common targets, resolving success or failure, etc. The author's voice is permitted for the very reason you alluded to in your post: to inject a sense of excitement or flair into the use of the dry, formal rules (and that's why rules in examples are parenthetical and abbreviated).

"Flavor Copy - Appropriate person (1st, 2nd, 3rd). Narrative. No rules."
Again, for much the same as your reasoning, flavor text tries to excite the players and engage their imaginations. It differs from examples in that it is not trying to stimulate the reader with the system, but rather with the setting.

"Designer's Notes - First person plural ("we"). Narrative. Rules as needed for examples."
The most informal of writing, exposing the author as an active voice, designed to help the curious understand basic design decisions. This can also contribute to excitement about the product, if only by letting the reader see how much consideration went into it.

So before damning the "technical writing style" of core rules, consider how they will be used by the players day-to-day, and consider them in conjunction with examples, flavor text, and notes. Many things will "sell" a game to players--not the least, the evocativeness of the writing--but just as many things will "sour" players--I hazard the opinion that referential material made harder to read by "loose" writing is #1.

My opinion, as a technical writer for five years and a gamer for twenty-five years.
If you liked this post, you'll love... GLASS: Generic Live Action Simulation System - System Test Document v1.1(beta)