[You're It] Conflict/task resolution system

[Robert Bohl]

I'm thinking of designing a near-future fascist utopian game of juvenile delinquency called You're It!  I have some ideas worked out but I want to wait a bit before elaborating on them.

However, the one part I am very concerned about is a conflict or task resolution system.  I am guessing I'd like to go with d6s for the same reason everyone else does (less dorky, more available).  Anyway, are there any good resources here on how to design such a system, the effects it has on the kind of game you want, and so forth?  For the record, I'm interested in a very stunty, actiony game.

Also, what are the ethics on using someone' elses C/TRS?

[TonyLB]

Credit them?

I mean, apart from the legal situation (last I heard you cannot patent a rules system as a concept, only copyright the particular words you use to describe it), there's also the issue of reinventing the wheel vs. refining something for another purpose.  I generally think that the latter is good (where possible) and the former is bad (where unnecessary).

I believe the traditional way to contact someone and say "I'd like to do this with your permission, but I'm doing it either way," is to ask for their "blessing."  That might be a classy thing, depending.  I certainly don't imagine a lot of designers here would have a problem giving their blessing.

You may find however, as you playtest, that it becomes easier to drift the system to something subtly different than to keep the core identical and patch it with add-on rules.  At least that's my memory of patching mainstream systems.  Don't know if it applies here.

[Andrew Cooper]

Yes.  Credit them.

In my game I've taken bits and pieced from all over the place.  Sometimes, the exact part I've borrowed is hard to determine but it's obvious that a particular piece of the system has its roots in another game.  I even document the inspiration when this happens.  To me, it's just the right thing to do.

Without more concrete examples of your system, any more than this general advice will be difficult to give.

[Andrew Morris]

Rob, what kind of "resources" are you looking for to assist in designing your system? I mean, the Forge is a pretty good resource, right off the bat. Do you have specific concerns that you want to address, and you'd like examples of how others have handled them in the past? Or something else?

[Alan]

Hi Rob,

No one has put together a handbook. You'll have to gather the design techniques yourself.  However there are concentrated viens of knowledge.

To learn about Forge game design resources:

1) Read the sticky threads at the top of the Indie Game Design forum.

2) Read Ron's introduction to the Big Model in http://www.indie-rpgs.com/articles/27/

3) Spend some time absorbing this; search the Forge for key words that interest you

4) Read M. J. Young's Applied Theory article, http://www.indie-rpgs.com/articles/23/

[Eric Provost]

Have you checked the Resource Library link at the top of the page?  There's links to pleny of free games up there.

And I think that's your best bit of reference.  Other games.  Other designers' design threads.  Especially check out the old design threads for games that are selling and are popular now, and the threads by those designers that have been successful in selling their games in the past and are designing new games now.  Tony's design work on Capes and Misery Bubblegum come to mind immediately.

Finally, Vincent has some very good articles on his site that bring the big theory stuff down into language for the masses.  If you want to spend some time thinking about making rules that do the tricks you want them to do, I highly suggest reading his work.

-Eric

[Robert Bohl]

Okay, I'll reply in detail to some of the posts here, but Garek said:

Without more concrete examples of your system, any more than this general advice will be difficult to give.

How much should one reveal in this context?  I have a bunch of ideas that I was going to spit out in a written brainstorming.  Is that "giving away" too much?

--

Now to do some reading and intensive replying.

[Andrew Morris]

If you honestly think someone's going to steal your ideas (and that that's a bad thing), then don't talk about the specifics of your concept. Of course, don't expect to get any specific, useful advice, in that case.

On the other hand, if you think (as I do) that everyone here is either working on their own designs or that being inspired by your work enough to adapt it to their own project is a compliment, then go into as much detail as you need to get the help you're looking for.

[Robert Bohl]

Rob, what kind of "resources" are you looking for to assist in designing your system? I mean, the Forge is a pretty good resource, right off the bat. Do you have specific concerns that you want to address, and you'd like examples of how others have handled them in the past? Or something else?

Well I was thinking along the lines of articles that address how to design the "dice part" of a game.  I put that in scare quotes because it doesn't necessarily involve dice.  In terms of how to do the "dice part", I'm pretty clueless.  I understand a lot of these mechanisms pretty well but I do not know where to begin to design such a thing.  I am very tempted to steal someone else's and tinker with it, which is why I included my last question.

1) Read the sticky threads at the top of the Indie Game Design forum.

2) Read Ron's introduction to the Big Model in http://www.indie-rpgs.com/articles/27/

3) Spend some time absorbing this; search the Forge for key words that interest you

4) Read M. J. Young's Applied Theory article, http://www.indie-rpgs.com/articles/23/

1) Regarding the "What's the best way. . . ." thread, Andy Kitkowski suggests one say what one's goal for publishing is.  My notion is to produce a PDF, playtest the hell out of it, and if I wind up with something good, perhaps sell the PDF.  If the PDF does well, perhaps sell a print version.  This is my first foray into this, however, so I'm a little nervous about making too grandiose of a plan.

2)  I have read the intro to the Big Model before, and I have to confess that while I understand parts of it, mostly I drown inside it.  GNS theory is not my strong suit, though I get the general principle, I think.

4)  The applied theory article is interesting and digestible.  I've printed it out and intend to give it some real close attention.

Finally, Vincent has some very good articles on his site that bring the big theory stuff down into language for the masses.  If you want to spend some time thinking about making rules that do the tricks you want them to do, I highly suggest reading his work.

I think Vincent is awesome and I'd love to pick his thoughts.  I assume you're referring to Roleplaying Hardcore?

If you honestly think someone's going to steal your ideas (and that that's a bad thing), then don't talk about the specifics of your concept. Of course, don't expect to get any specific, useful advice, in that case.

On the other hand, if you think (as I do) that everyone here is either working on their own designs or that being inspired by your work enough to adapt it to their own project is a compliment, then go into as much detail as you need to get the help you're looking for.

Oh, I'm not worried about anyone stealing my precious ideas, believe me .  It was more a question of if it's considered gauche to dump your entire brainstorming into the forum like this, or if they want more targeted stuff.

[Andrew Morris]

Okay, Rob, I think I get what you're looking for now. For some useful information on dice mechanics, I'd check out John Kim's website. The "dice part" you're talking about can be found as "resolution" (conflict, task, whatever) in old Forge threads. I hope that helps.

As to how much you should post, I think you'll find it's most valuable to post specific details related to a focused question. ("My system uses a fortune-based task-resolution mechanic to determine the effects of throwing a bannana at monkeys. Do you think that this will cause a problem in conjunction with my ice-cream rules?" [describe both elements])

[Robert Bohl]

Andrew: This looks like exactly the kind of thing I'm looking for.  Thank you.

[Andrew Cooper]

Rob,

What Andrew said.  Take discrete systems that you have problems/questions about and then give each one its own thread.  A huge braindump into 1 thread is generally too much for 1 topic but not giving any specific information doesn't allow us to actually help you or critique the game.  Take something like just the Task Resolution system and give us just the details for that and then ask your questions about it.  Or just describe the Reward Mechanic.

[Robert Bohl]

Gaerik:  What if I'm not that far yet?  Also there'd have to be at least somewhere describing the setting, themes and goals speaking generally right?  I guess that could come with my first substantive post on the topic.  So the post may be about how to do stunting properly, but if it's the first real post on the game, it'd have to be the one to bear the familiarizing load.

[Judd]

I think you have an idea for a game and no game yet, Rob.

I'd start a new thread when you've got some system ideas worked out to some degree and have definite questions you want answered before playtesting.

[Robert Bohl]

I think you have an idea for a game and no game yet, Rob.

I'd start a new thread when you've got some system ideas worked out to some degree and have definite questions you want answered before playtesting.

I think it'd be more accurate to say that I have a setting and some vague systemic ideas (e.g., "cool points" awarded for stunts, systemic discouragements to carnage, systemic encouragements to stunts and mayhem, a very-simplified "burner"-style character creation system, etc.).  As to whether that constitutes a game or not, I don't know, but if it is one it's definitely not very far along in gestation.