Verge (http://adam.legendary.org/old/library/verge.pdf) is my freshman entry into game design. I am a long-time Forge lurker, a terrible procrastinator, and a doomed perfectionist. That aside, the hyperlink above will connect you to a finished, ostensibly-playable, well-presented, almost-40-page, PDF role-playing game. Verge is worming its way into my dreams at night and I won't be able to sleep until it's done.
Description
Verge is a cyberpunk game but it could be easily adapted to other settings. In fact, there is little actual setting material in the book. The game's premise is What drives you and can you keep it under control?. Drive (an addiction-like need for power, reputation, drugs, family, knowledge, or something like that) makes a character do dangerous things to get ahead.
Characters have FATE-like traits: Strengths and Weaknesses, Friends and Enemies, Gear. Drive and Life are also traits. Traits can be "burned" for rerolls in the conflict resolution system, which takes the frequency of the most commonly occurring number in a dice pool as the number of successes (player rolls, GM rolls, compare).
In conflicts, players choose all the risk. The GM doesn't get dice to roll unless the players give them to him. The more risk a player takes, the better chance he'll earn Experience later. Drive serves as a source of dice in conflicts but also a drain on Experience, so the higher the Drive, the more risk a player must face to advance. Drive automatically increases over time. Failure when a character's Drive or Life is at stake can deplete Life and cause the end of the character (not necessarily the death).
Request for Help
I need help in a number of different ways.
I need opinions and criticism. I need people to read the game, tell me what they like and don't like, tell me what works and doesn't work. I need people to play the game and give me feedback. I have two groups who are independently playtesting for me this month, but I can always use more (especially people familiar with Nar games).
I need help with publication. Once I finish playtesting and rewriting, I will publish this game as a PDF on rpgnow and other places, priced fairly low. This isn't about the money, but I'd like to recoup costs if possible. This is my hobby, though, so I'm willing to "lose" money on it. I need to understand better how the RPGnow process works, what to watch out for, etc. I'm also interested in print on demand, so I'd like to talk to someone about that process. I'll search the web forum, too.
I need help with production, but not much! I have a pro game editor lined up (gratis). I have a pro graphic artist lined up for layout (gratis). (Note that neither of those people have seen the PDF that I edited myself and layed out in Word.) I am seeking logo art, cover art, and interior art. I haven't scoured these forums for how-to links about such, and I will do my homework this week.
I have a lot of reading to do, because I've largely ignored this forum -- and especially the Publishing and the Connections forums, since I wasn't there yet -- but I'll get caught up.
Any help people can provide is greatly appreciated, especially regarding critical review.
Well, this seems to be the place for criticism:
The game is about controling your drives? Well, I'm not seeing that mechanically. What part of the rules are supposed to deal with that?
Mike
Game text and presentation
Sequence of information
The information needs to be structured differently. First you go into great detail on character components, using a lot of game terminology you haven't explained. Then, you talk about how players should act - goals, handling disagreements etc. Then - at the end! - you tell us how the game is structured. After that, we're finally told how to roll the dice, and how conflicts are resolved.
This needs to be almost completely reversed. Start by telling us how the game is played, in general. Then, tell us about the dice and conflicts. Then we're ready to understand what character traits are all about.
Characters chapter
The Characters chapter should also be re-structured. In order to create a character, you have to read "Install" sections in 8 different places - which is a pain, reminiscent of 80's games where you had to consult three different books to understand one process.
I suggest you at least put all the Install bits together, all the Conflicts bits together, and all the Aftermath bits together. If you want to put crucial information in two different places just to make sure people don't miss it, you might want a trait rule summary sheet or two at the end of the book.
Flow of resources
When I finally started to understand the flow of Experience through the game, I thought: "Why didn't he talk about that earlier?" Then I realized you had, many times - I just missed it in all the paragraphs using Terminology I Hadn't Understood Yet.
I suggest you make a graphical presentation of how Experience flows - little boxes for different situations (action scenes, development scenes), arrows showing how you spend and earn Experience (buying traits etc).
Talking about design goals
Let us know what you're thinking! You know why you included this and this mechanic, what it's supposed to accomplish in the game, what style of play it supports. Let the players know. There's little point in not telling - that means we spend the first session or two figuring things out, and then half of us go 'oh, we should have done things differently way back at character generation'.
In some places, you have comments like "Your choice of Weaknesses tells the GM what kind of challenges you want to face". More!
Example of play?
Yes. Give us a scene with some conflict resolution.
Game mechanics
I haven't playtested this, and it's obvious that you need to play it to get the feel of it. However, it has several things I like - it uses conflict resolution, for starters. It has rules for letting GM or player narrate outcome (separating right to narrate from success is probably inspired by PTA, I'd guess?). It allows you to make harsh decisions - burn my friend again? or risk my life? It lets players set risk levels (Volume) for Action scenes - the more you risk, the more experience you can get in a Development scene.
Terminology
I found some of the terms a bit annoying - why should players have to learn to say "Reboot" instead of "between sessions", for example? Others - like the consistent use of Signal, Noise, Frequency and Amplitude - are actually quite cool. Well, this is going to be a matter of taste, mostly.
Friends
You get 8 boxes of friends. This is enough to buy four casual acquaintances, or one intimate friend (with perhaps a casual thrown in). Why so few? If your character has any family at all (like the one I tried to generate), he can at most afford to have two of them as occasional friends, and one as a casual acq.
Vote it out
Voting about what's appropriate use of a trait sounds OK. However, this seems out of place to me: "A player may check one or more boxes of Boosts to earn the same number of additional Votes in a single matter". What's the reason for this rule? It's a strange connection between different levels of play/communication.
Scenarios
Do players make lists of elements and hooks at the start of a session, and the GM makes a story from that? Or do they make their notes at the end of a session, allowing some prep time for the GM?
- - -
OK, that's what I've got. I'd need to playtest to provide more rules comments; it looks like a fun game, so I'd love to play it, but that's most probably not going to happen this year.
Thanks for your comments, matthijs. I really appreciate it.
I originally had the rules structured by task. I should have left it that way. My thinking though was that players might want to know how things were used. Have a question about Life? It's in the Life section. I totally agree with your assessment, however; in practice, it's better to arrange them by task. I struggled myself trying to find rules while writing up a half dozen examples of play today in my LiveJournal (http://adamdray.livejournal.com).
I also came to the same conclusion this morning that I probably needed to tell people how to play the game then tell them how to make up characters. All the rules and terminology are explained in the Play section. So, we're totally in agreement there.
I'll try to create the visual Experience flow you suggest. That's a good idea.
Regarding design goals, I do want to talk about them more but I ran out of time. I have to write a 60-character LARP by the end of May and that forced me to shelf Verge till June. I can talk about it and tweak here and there, but I had to finish the first major revision last weekend and leave it alone for a while. I wanted to get it written down so I didn't forget too much and so that a couple friends could playtest it for me this month. All that aside, I agree with you. I'll make sure to talk about why things are in the next major revision (June).
As I mentioned above, I wrote some examples of play today: Sample Character (http://www.livejournal.com/users/adamdray/115028.html#cutid1), Scene 1 (http://www.livejournal.com/users/adamdray/115363.html#cutid1), Scene 2 (http://www.livejournal.com/users/adamdray/115497.html#cutid1), Scene 3 (http://www.livejournal.com/users/adamdray/115825.html#cutid1), Scene 4 (http://www.livejournal.com/users/adamdray/116223.html#cutid1), Scene 5 (http://www.livejournal.com/users/adamdray/116333.html#cutid1), Reboot (http://www.livejournal.com/users/adamdray/116667.html#cutid1).
I've drawn inspiration from a number of games, notably PTA and FATE. Regarding the terminology, I tried to reuse terms when they existed (Scenario, Scene, Conflict, etc.) except when I thought they added appropriate color. You liked Signal, Noise, Frequency, and Amplitude but disliked Reboot. I happen to love Reboot but I'm lukewarm on Frequency and Amplitude. Some terms might get flushed if they're not useful in the rules text. Reboot is actually pretty useful (and intuitive, I think). So is Burn. Aftermath is a bit confusing, I think. I thought Feedback would be a useful term but "reroll" is clearer.
I may need to retool the charts that explain levels of Friends, etc. Really, the boxes represent the ability of that Friend to help you, not how much you care about them. You might only have a 1-box relationship to your mother, but a 5-box relationship to your bodyguard. Maybe Mom isn't helpful in a crisis.
Regarding Vote It Out, I wanted a metagame mechanic there to give a player additional oomph in a vote when it was important to him. If he wants to spend a Boost on it, he can. It'll generally come into play only when the votes are close or tied. And another player can spend a Boost to cancel the extra vote with his own extra vote.
I'll tidy up the description of Reboot and how it ties into a Session. I think it'd be nice to give the GM some prep time during Reboot. That was the intent. But I don't think it's strictly necessary for a GM who is good on his feet. After all, the player is giving the GM a full-blown Hook, ready for play. The GM just has to make up some particulars, and that doesn't require any statting at all, since no GM-controlled characters ever have stats.
Thank you so much for this feedback. It reinforces a lot of what I already suspected and motivates me to take on the task of restructuring it all. I'll also try to get an Experience flow chart in there. Maybe a scenario flow chart, too. Visuals help.
QuoteThe game is about controling your drives? Well, I'm not seeing that mechanically. What part of the rules are supposed to deal with that?
Mike,
You're right, sorta. I rewrote the Premise a bit when I posted. That's not very well supported in the rules.
I realized that as I wrote my examples of play (see the above message for links). Scene 3 (http://www.livejournal.com/users/adamdray/115825.html#cutid1) shows what I have in mind.
The GM can force a character to test against his Drive at any time. If the character fails, he loses Life (motivational energy). In the example, Flatline refuses to investigate a juicy rumor and the GM decides this should test his Drive for Knowledge. It becomes a Conflict with Life at stake.
When Life or Drive are at stake, if the Volume isn't at least as large as the player's dice pool, he loses Life automatically. In a Drive test, if the player loses the Contest, the character loses Life based on the margin of failure.
Assuming I clarify this in the rules, does this fix the problems you've exposed?
I liked the terminology used, especially in regards to the conflict resolution system. "Signal", "Frequency", "Amplitude", "Feedback".... wonderfully descriptive of the aspects they represent.
The resolution system was great, too, allowing narration and winning the stakes to be separate entities. I like the idea of the bitter loser narrating how her opponent bested her, but describing that he somehow falls into danger. Great story engine.
If you want the Drive to constantly be tested, it seems it should be a dominant aspect of the entire text. Personally, I think the idea of the GM having to test the characters seems loose. Perhaps some kind of engine-like mechanic would help (like how you propel story events by dividing success and narration). But I'm crazy at times, and that may be dissimilar to most opinions (the mechanic idea, not the crazy).
Overall, it sounded great as a system, but I'd almost want more setting to be encouraged to playtest it. [See: crazy.]
Thanks for your comments, Anthony.
I do want to find a better mechanism for forcing Drive to the forefront. I might just work it into the Reboot mechanism and require each player to include an opposing force (Drive pulling at their lives) in their Elements and Hook. That's a bit loose but I think it'd work. Thoughts?
I don't think Drive has to be pulling at the character in every scene to make a good game though. In fact, I think that would be tedious. But once per scenario seems reasonable. It has that episodal quality to it. The protagonist goes off to do cool stuff but at the cost of something else.
That's where the game began, more or less. It started out as a simple Reputation mechanic, but I always had Family in mind as an additional driving force. I abstracted them to Drive. Then I added the other drives to flesh it out.
Like was suggested for my destiny-based game, perhaps some kind of "bonus" from the Drive would be a good idea. As this notion was presented, a bonus keeps players constantly thinking about the trait (How can I act to get the bonus?) without it always being involved. Plus, the fact that the players choose when to enact the Drive and utilize the bonus would simulate the nature of those addictions and powermongering and such. Maybe a "penalty" results from too much use of the Drive?
That way, the pressure isn't on the GM to drive the story along, as the players are presenting those "losing" narratives, and the Drive mechanic is an internal facet of the system as opposed to superfluous and "tacked on".
You know what I mean?
Well, the theme seems to be losing control because of drives. To me I see two ways of doing this:
The sorta simmy way is to have a sort of conflict that can occur where the player has to roll against his drive, or have the character take some action that the player doesn't want him to take. Drive for Knowlege? Failing to beat the drive means, perhaps, that the character breaks into some place to get some bit of info, having heard that it's secured there.
The more narrativism based way is to allow the GM to tempt the player via the character's drive. The character learns that there's some info in a place, and if he goes for it and gets it, the character's drive goes up by one or something. As the character gets more powerful, the GM can put in more and more horrible dilemmas (will the character kill for info?). This way the player always has control of the character, but is incentivized to do things that represent the character being controled by his drive.
As it stands, the fact that the character risks his drive when the GM thinks he should, doesn't say anything to me about losing control to your drives. Sounds like a simmy, "Can you protect your drives" premise there.
Mike
I thought of a solution on the drive to work today.
Character creation will require half (by number and points) of a player's Strengths, Weaknesses, Friends, and Enemies to be related directly to his Drive. And I'm doubling the number and points of boxes per category (now 16 boxes over 8 traits for each trait category).
For example, if your Drive is Family, then you'll have 4 family-related Strengths with 8 boxes, 4 family-related Weaknesses with 8 boxes, etc.
This means that you'll be "driving" (powering) your character from Drive-related Strengths and Friends, and the GM will be tossing the downside of your Drive (Weaknesses and Enemies) at you as conflicts.
I think this solves the Drive problem.
Mike,
I admit to a lot of "Timid Virgin" narrativism in my design. I've played only one Nar game (My Life with Master), loved it, and it confirmed my long suspicion that I wanted Nar in my games. Problem is, most of my experiences and "tools" are Sim, so I fall into that rut in design.
I agree that I probably need a mechanism for the GM to bribe the player to take a risk with his character. I like your suggestion and will consider how I can work it into the game neatly.
I'm considering adding a stat like Control, which relates to how much the character controls his Drive. Control can be as low as 0 (no control over Drive) and as high as Drive (total control over Drive). I think the Nar mechanism might be a combination carrot and stick. If you take this mission and succeed, you get +1 Control or +1 Drive. If you don't, you get -1 Control. Drive minus Control becomes the new Experience drain. I haven't worked through the problems in this. Just brainstorming here.
The first problem is to answer what Control would be for. If it actually is to allow the character to control himself - meaning that there's a chance to lose control of one's character, then you don't really have a choice for the player. He wants high control and high drive.
What you want, I think is some trade off between Control and Drive. A typical thing to do is have them be inverses of some sort. Like they always have to add up to 6 or something. So when your drive is high, your control is low. And you can allow the player to adjust them on the fly - so you as player can have the character lose control and go with their drive whenever they want to be really successful. But then there might be repercussions or something as the result of the low control. Building control back up might be really difficult.
Get what I'm saying? For the premise to work the player (not the character) has to have some incentive to go with their character's drive. Note that this doesn't really require another stat, IMO. If you just say that the character only gets their drive bonus when they're doing something related to it, I think it works out fine. The player has an incentive to do whatever goes with the drive. Then all the GM has to do is to put the character in situations where they have to make a statement about what's important to them by either going with or against the drive. Again, will they wreck their relationships for their drives? Will they commit crimes for their drives? Will they give up comfort and safety for their drives?
Am I getting the concept across? What you want to do is to set up the mechanisms so that when certain choices come up, certain of them have mechanical repercussions in one way, and others have other repercussions. Then when the player makes the decision based on what they think would be interesting, the mechanics make the statement important.
Mike
Yeah, you're crystal clear, Mike. The thing is, I know this stuff at an intellectual level but I'm reverting to Sim thought when I design by instinct. It's frustrating.
And I think you're right that I don't need a Control trait.
I have a lot to think about now. <=)
matthijs suggested I restructure the rules. I've created an outline (http://www.livejournal.com/users/adamdray/116803.html#cutid1) in my blog.
Wow. New outline looks much better! Who's going to be doing your layout, btw?
My layout will be done by a graphic artist I work with at my day job (information technology).
My editing will be done by Paul Tucker, a friend of mine who used to work for Mongoose.
I don't mean to "bump" this thread. I just wanted to follow up on some comments posted before.
I have posted an updated PDF (http://verge.legendary.org/download/verge.pdf) that weighs in at around 55 pages. It incorporates many of the changes that matthijs recommended: the restructuring of sequence of information , some more talk about design goals (still needs more, I'm sure), an example of play that is already out of date (but does show off some of the play structure), a complete glossary to help with terminology. At Mike's suggestion, I also rewrote the Life/Drive/Experience/Volume rules that make the game go (and haven't updated the example of play to match).
I'm swamped with another project for the next two weeks (60-character LARP due for a con over Memorial Day weekend). After con, I'll do more work on Verge.
I do get to playtest Verge at the con with a group of 6 players for 4 hours. I'm excited about that. I also have two friends on the net with RL play groups who will be doing some independent playtesting (one of them is coming to the con playtest, the other is not). I'm also holding a house-gamin-con over July 4th weekend (Baltimore-DC-area; PM me if you're interested) and will be playtesting more then.
Do post how the playtest goes. I think that'll give a lot of things to talk about.
Mike
Yep! I do promise an Actual Play post.
AP posts are a new thing for me. I can handle the writing part of it but the during-game note-taking is the challenge. I don't remember the details after the game when I try to reconstruct. I did take good notes for the "My Life with Mr. President" I played in, but haven't written that up yet. The challenge with the Verge playtest will be handling a new system (even though I wrote it, it's still "new" to me), fixing rules as I play, and taking notes at the same time.
Does writing notes down after play work for you? That's what I'd suggest. You don't want to stilt play by taking notes during it, IMO. What you do with a playtest, optimally, is to take fifteen minutes to half an hour after the game is done, and talk with the players about what they thought worked, and what didn't, and why. General impressions. Get whatever feedback you can. Then give them your impressions (wait until then), and get their feedback on your impressions.
Take notes of all of this. This is where you get your best data from which to work on bettering a game, IMO. Basically you want to get your game to the point where people, when done, feel good about playing to the extent that they recommitt right then to come back and play the next installment. So getting feedback, just post play, is the perfect place to guage.
Mike
If I wait till post-play -- even immediately post-play -- I lose a lot of details that are useful.
I think Verge games will partially self-record though. I just realized that. The reward mechanism requires players to record their dice and Volumes after every action scene. I can ask players to record some additional information for their development scenes and then collect it all post-game.
Or I can do it. I think there's not much to record about the mechanics. I can add the larger-scale issues to that post-play as I interview the players.